> Subject: Re: [PATCH] drm/i915/backlight: allow hybrid pin-enable + AUX > brightness panels > > > Hi John this fix has been already floated, reviewed and merged some > > days ago to drm-intel-next. > > > > https://patchwork.freedesktop.org/series/170522/ > > Thanks, glad it's fixed, and happy to see the same conclusion; please > disregard > my patch. > > For the record: independently root-caused and tested the same change on a > Google Pixel Slate (nocturne, Tianma Y156ZAN02.0: advertises > BRIGHTNESS_AUX_SET_CAP without AUX_ENABLE_CAP, ignores PWM for > brightness, and resets the AUX brightness register on every panel power cycle, > so it resumes from suspend to a permanently black screen without this fix). > With the equivalent change on 7.1.4 the panel's AUX brightness register is > restored across suspend/resume and full-range brightness control works, so > feel free to count that as a >
Hi Thanks for the patch, yes I had a lot of gitlab from panels that don’t have a PWM fallback which led to this same fix. > Tested-by: John Foushee <[email protected]> > > for commit 7d594b24 on real affected hardware. > > One question: the regression (ed8be780bdbc upstream / 102d44b3a8fa in > mainline) is present in the shipping 7.1.x stable series, but 7d594b24 doesn't > carry Cc: stable. Will the Fixes: tag be enough for it to be picked up for > 7.1.x/7.2.x, or should it be nominated to stable explicitly? > Affected devices are unusable after any suspend without it, so a backport > would matter to users on current stable kernels. Yes I just Cc'ed them so that it gets picked up. Added you in it too. Regards, Suraj Kandpal > > Diagnosis details, DPCD dumps and EDID, if useful: > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16679 > > Thanks, > John > > > On Wed, Jul 22, 2026 at 9:22 AM Kandpal, Suraj <[email protected]> > wrote: > > > > > > > Subject: [PATCH] drm/i915/backlight: allow hybrid pin-enable + AUX > > > brightness panels > > > > > > Commit 102d44b3a8fa ("drm/i915/backlight: Fix VESA backlight > > > possible check > > > condition") restricted the VESA backlight path to fully AUX-based > > > panels (enable and adjustment both via AUX), on the grounds that the > > > hybrid configurations are not currently supported. > > > > > > The hybrid pin-enable + AUX-adjustment configuration is however > > > already > > > handled: intel_dp_aux_vesa_enable_backlight() falls back to the PWM > > > funcs for enable when info.aux_enable is unset, and > > > drm_edp_backlight_init() supports aux_set without aux_enable. > > > > > > At least one panel requires this configuration to work at all: the > > > Tianma > > > Y156ZAN02.0 in the Google Pixel Slate (nocturne) advertises > > > DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP but not > > > DP_EDP_BACKLIGHT_AUX_ENABLE_CAP (DP_EDP_GENERAL_CAP_1 = 0xfb, > > > DP_EDP_BACKLIGHT_ADJUSTMENT_CAP = 0xff). The panel ignores the > PWM > > > pin for brightness adjustment, and resets its AUX brightness > > > register > > > (DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB) to 0 whenever panel power > is > > > cycled. With the PWM backlight funcs selected, the panel comes back > > > black after every suspend/resume or DPMS off/on cycle while all > > > driver-visible state (link training, PPS, PWM duty) looks healthy. > > > Firmware rewrites the register at boot, which masks the problem > > > until the first runtime panel power cycle. > > > > > > Allow the hybrid configuration by requiring only AUX brightness > > > adjustment capability; backlight enable keeps using the pin/PWM path > > > via the existing fallback. > > > > > > Tested on the Google Pixel Slate (KBL-Y) on 7.1.4: i915 now selects > > > the VESA AUX backlight interface, the panel's AUX brightness > > > register is restored across suspend/resume, and brightness control > > > works over the full range where it previously had no effect. > > > > > > Fixes: 102d44b3a8fa ("drm/i915/backlight: Fix VESA backlight > > > possible check > > > condition") > > > Closes: > > > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16679 > > > Cc: [email protected] > > > Cc: Suraj Kandpal <[email protected]> > > > Signed-off-by: John Foushee <[email protected]> > > > > Hi John this fix has been already floated, reviewed and merged some days > ago to drm-intel-next. > > > > https://patchwork.freedesktop.org/series/170522/ > > > > Regards, > > Suraj Kandpal > > > > > --- > > > .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 12 ++++++++---- > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > > > index 7a6c07f..a5c03c3 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > > > @@ -616,11 +616,15 @@ check_if_vesa_backlight_possible(struct > > > intel_dp > > > *intel_dp) > > > u8 bit_min, bit_max; > > > > > > /* > > > - * Since we only support Fully AUX Based VESA Backlight interface > > > make > > > sure > > > - * backlight enable is possible via AUX along with backlight > > > adjustment > > > + * Brightness adjustment must be possible via AUX. Backlight > > > *enable* > > > + * may come either via AUX (DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) > > > or via the > > > + * BL_ENABLE pin, which the VESA backlight code already supports by > > > + * falling back to the PWM funcs for enable when aux_enable is not > > > set. > > > + * Some panels (e.g. Tianma Y156ZAN02.0 in the Google Pixel Slate) > > > + * support only that hybrid configuration and ignore the PWM pin for > > > + * brightness adjustment. > > > */ > > > - if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP > > > && > > > - intel_dp->edp_dpcd[2] & > > > DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) > > > + if (!(intel_dp->edp_dpcd[2] & > > > +DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) > > > return false; > > > > > > ret = drm_dp_dpcd_read_byte(&intel_dp->aux, > > > DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &bit_min); > > > -- > > > 2.47.3 > > > > > -- > > @foush
