From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.manjaro.org (mail.manjaro.org [116.203.91.91]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 571882BDC10 for ; Mon, 25 Aug 2025 07:02:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.91.91 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756105368; cv=none; b=fmP0nOcy+A83TCFrNW2DUb0XMLr9ce6M5TsS0Ghyqacbz8BIQJNC3FF52R+eMhwitaOvt1RpBZvEzqxTOSelMNPuyS/aFnfTeLnjsdRRCAr1lfRj6GEhCfV73UBzFwZrdvCZOWhnaSZefM5aYyUpC8Tc4QwcJXZWuBZ3rWwGo4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756105368; c=relaxed/simple; bh=Ww1l4kU6XoG6+pq0FKhmMqbZI3C0dck0vI2yup0Q6Ys=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Xzug9e6ISk4n5uCjnodFj2xNx0cvHuqQDwh6BNpNmGJNzepNHla1JgPWExsa0+L4CsmlxImvlbe9ZclGACpncbX0nT5vT8kYMXFhFXhV7Jo+LeHrEfFcfDFJkJdNH5hSgPQpeo+NQuVdrnwaUncgcnHCJGal/ZZDmWEq3ojul2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=manjaro.org; spf=pass smtp.mailfrom=manjaro.org; dkim=pass (2048-bit key) header.d=manjaro.org header.i=@manjaro.org header.b=BfF2ZCNl; arc=none smtp.client-ip=116.203.91.91 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=manjaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=manjaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=manjaro.org header.i=@manjaro.org header.b="BfF2ZCNl" Message-ID: <88fec8864f2544df67113bf7282a1b2965a1eabd.camel@manjaro.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1756105357; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ww1l4kU6XoG6+pq0FKhmMqbZI3C0dck0vI2yup0Q6Ys=; b=BfF2ZCNlgiauBfEnpXCc3Mvuj0qOEvCEDy8EsJMvt6fCQMDuHPqMlB6uXl7vyLOC0IVykR vpBECokdqz0xm8dkS8r44Uq/24bw2dOqVAXLJvuYxAccZ+RDV8vVX12McBFOqotntKft+J xMyVG3JyVUQxpkjLiYfZ3mLa8yLdH4u7BcF8rxj+XZq1HuxKN44YRDXHMaWdT6qS56XNPj MJyhUlyAa2djoTKSfgrsbPhA+ZTYWzjJXjMscFOoMfO2alOJ24qjs3Ljls/uJJwaukE5Xb ZYj/HsTb9KlAQilavvZmdK3MLXbNAWlhXjYxGFUg8JnTusfXMvHFasjk7C8ynw== Subject: Re: [PATCH v1 2/2] drm/amd/display: Adjust AUX brightness to be a granularity of 100 From: Philip Mueller To: Antheas Kapenekakis , amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Alex Deucher , Christian =?ISO-8859-1?Q?K=F6nig?= , David Airlie , Simona Vetter , Harry Wentland , Rodrigo Siqueira , Mario Limonciello , Peyton Lee , Lang Yu Date: Mon, 25 Aug 2025 09:02:34 +0200 In-Reply-To: References: <20250824085351.454619-1-lkml@antheas.dev> <20250824085351.454619-2-lkml@antheas.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Authentication-Results: ORIGINATING; auth=pass smtp.auth=philm@manjaro.org smtp.mailfrom=philm@manjaro.org On Sun, 2025-08-24 at 21:33 +0200, Antheas Kapenekakis wrote: > Well Phil managed to fall into the value 332800, which has a 0 minor > bit. Unfortunate. In hindsight, every 256 hundreds there would be a > zero anyway. >=20 > Before I made this patch I made a partial refactor of panel-quirks > where a quirk like this could go to. But I would really prefer not to > do quirks. Ill send that too. >=20 > Antheas I was already looking into that OLED issue for several weeks. Changing granularity might hid the root cause and you might hit the issue less frequently. Currently checking [1] which changes the first byte to 3 since when DP_SOURCE_BACKLIGHT_LEVEL is written to with the first byte being 0x00 and sometimes 0x01, the panel forcibly turns off until the device sleeps again. In the end the panel vendor has to fix it in firmware. If not a quirk might be better specific for each panel vendor. I'm still not sure if that refactoring is needed, or a separate quirk function is more logical to be accepted upstream. [1] https://lore.kernel.org/lkml/20250824200202.1744335-5-lkml@antheas.dev/T/#u