From: Andrei Rusu de Castro <arc@empyreal.works>
To: amd-gfx@lists.freedesktop.org
Cc: harry.wentland@amd.com, sunpeng.li@amd.com, siqueira@igalia.com,
alexander.deucher@amd.com, christian.koenig@amd.com,
airlied@gmail.com, simona@ffwll.ch, alex.hung@amd.com,
roman.li@amd.com, mario.limonciello@amd.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
chen-yu.chen@amd.com, ray.wu@amd.com
Subject: [PATCH v2 0/4] drm/amd/display: fix brightness ownership through power module
Date: Wed, 02 Sep 2026 22:31:03 +0000 [thread overview]
Message-ID: <cover.1788388049.git.arc@empyreal.works> (raw)
In-Reply-To: <20260902-brightness-cover-abf809f2@empyreal.works>
Linux passes PWM eDP brightness through two owners. The display manager
maps the request into the firmware range and applies the ATIF custom
curve. The power module then derives a percentage from that hardware
value and applies the same curve and range again. A non-zero firmware
minimum consequently prevents zero from reaching the panel minimum.
The split also leaves the custom-curve disable policy and final source
brightness mask attached to the wrong owner.
Patch 1 keeps pre-power-module custom-curve output in the userspace
domain, which also fixes affected stable kernels. Patch 2 covers that
conversion with a non-zero firmware minimum. Patch 3 passes zero-anchored
millipercent into the power module and keeps AUX millinits unmasked until
the final AMD AUX or effective PWM handoff. Patch 4 covers ordinary PWM,
forced PWM, AMD-AUX fallback, true AUX, live and replay callbacks,
multiple panels, endpoints, interior values, clamping, and invalid
ranges.
GPT-5.6 Sol Fast assisted with issue investigation, source and history
analysis, patch and test development, review-response analysis,
submission preparation, and consolidation of the working context. A
separate tool-enabled Claude Opus 5 review audited the complete final
diff with direct access to the source tree, build environment, KUnit
harness, logs, and relevant hardware records. Objective verification
included strict checkpatch, a clean UML KUnit build and execution of the
configured DRM test set, an exhaustive C reproduction of every EDID
luminance-byte combination, and source tracing through the DRM commit
worker and hardware callbacks.
The human contributor reviewed the final behavior and evidence, directly
performed and observed the physical hardware QA, and explicitly approved
the exact tested series for submission. The quirked OLED path, VESA AUX
panel, pre-DCN3.1 hardware, and hardware mode-change replay on a quirked
panel remain untested physically because no matching panel is available.
Changes in v2:
- rebase onto current Linux master 89a312991dc6;
- retain mathematical AUX millinits until the hardware handoff;
- apply the panel mask immediately before live and replay AMD AUX writes,
or after PWM derivation when the effective handoff is PWM;
- add a composition regression whose input distinguishes intermediate
masking from final-only masking;
- capture and verify the live AMD AUX, VESA AUX, and mode-change callback
values;
- credit the Sashiko finding and add the documented LLM assistance
trailer.
Sashiko also reported two pre-existing potential issues. Both were
checked without changing this series. The DRM nonblocking commit tail
runs from system_dfl_wq in sleepable process context, so taking dc_lock
there is valid. The EDID parser and AMD fallback were exhausted across
all 65,536 max_fall/min_cll byte combinations: consumed AUX ranges were
always min 1 and max 50 through 12544, with no equal or inverted range.
The final candidate passed all 2,036 configured UML KUnit tests,
including 88 AMD backlight cases. Each patch passes strict checkpatch
with zero errors, warnings, or checks, excluding only commit lookup
diagnostics caused by the shallow source checkout. The production AMD
display objects also compile with KUnit disabled and W=1.
The v2 physical PWM sweep on a Strix Halo panel captured both hardware
endpoints and restoration:
requested 655 -> actual 0
requested 65535 -> actual 65535
restored requested 20119 -> actual 11597
The operator reported normal panel behavior through the sweep. No kernel
fault followed. This panel has brightness_mask == 0, so it validates the
shared path but not the quirked OLED hardware path. The existing
LUT-unaware hardware readback inverse remains unchanged.
Andrei Rusu de Castro (4):
drm/amd/display: keep custom brightness curve in userspace domain
drm/amd/display: test custom brightness with non-zero minimum
drm/amd/display: pass userspace brightness to power module
drm/amd/display: test power module brightness input domain
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
.../display/amdgpu_dm/amdgpu_dm_backlight.c | 57 +-
.../display/amdgpu_dm/amdgpu_dm_backlight.h | 5 +-
.../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 3 +-
.../tests/amdgpu_dm_backlight_test.c | 622 +++++++++++++++++-
.../drm/amd/display/modules/inc/mod_power.h | 1 +
.../gpu/drm/amd/display/modules/power/power.c | 2 +
.../drm/amd/display/modules/power/power_abm.c | 55 +-
.../amd/display/modules/power/power_helpers.h | 14 +
10 files changed, 721 insertions(+), 46 deletions(-)
base-commit: 89a312991dc6e638a36adc43ccb91dbc25504c04
--
2.54.0
next prev parent reply other threads:[~2026-09-03 7:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 12:31 [PATCH 0/4] drm/amd/display: fix brightness ownership through power module Andrei Rusu de Castro
2026-09-02 12:31 ` [PATCH 1/4] drm/amd/display: keep custom brightness curve in userspace domain Andrei Rusu de Castro
2026-09-02 12:31 ` [PATCH 2/4] drm/amd/display: test custom brightness with non-zero minimum Andrei Rusu de Castro
2026-09-02 12:32 ` [PATCH 3/4] drm/amd/display: pass userspace brightness to power module Andrei Rusu de Castro
2026-09-02 12:57 ` sashiko-bot
2026-09-02 12:33 ` [PATCH 4/4] drm/amd/display: test power module brightness input domain Andrei Rusu de Castro
2026-09-02 22:31 ` Andrei Rusu de Castro [this message]
2026-09-02 22:31 ` [PATCH v2 1/4] drm/amd/display: keep custom brightness curve in userspace domain Andrei Rusu de Castro
2026-09-02 22:31 ` [PATCH v2 2/4] drm/amd/display: test custom brightness with non-zero minimum Andrei Rusu de Castro
2026-09-02 22:31 ` [PATCH v2 3/4] drm/amd/display: pass userspace brightness to power module Andrei Rusu de Castro
2026-09-03 7:50 ` sashiko-bot
2026-09-02 22:32 ` [PATCH v2 4/4] drm/amd/display: test power module brightness input domain Andrei Rusu de Castro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1788388049.git.arc@empyreal.works \
--to=arc@empyreal.works \
--cc=airlied@gmail.com \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=chen-yu.chen@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=ray.wu@amd.com \
--cc=roman.li@amd.com \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox