Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake
@ 2026-09-02 16:25 Jake Steinman
  2026-09-03  4:11 ` Hogander, Jouni
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Jake Steinman @ 2026-09-02 16:25 UTC (permalink / raw)
  To: intel-gfx, intel-xe
  Cc: Jouni Högander, Animesh Manna, Ville Syrjälä,
	Jani Nikula

On display version 20+ the extended fast wake time is programmed in
ALPM_CTL and the IO buffer wake in PSR2_CTL. intel_alpm_compute_params()
derives both from precharge + preamble + PHY wake + tFW exit latency
(42 us here); the IO buffer wake only differs when io_buffer_wake_time
is larger than the precharge, which is not the case on this panel. So
both end up on the same number of scanlines, 11 on this mode.

On the Dell XPS 16 DA16260 (Panther Lake, LG panel with sink OUI
00:22:b9, 3200x2000@120, 4 x 2.7 Gbps, DSC) equal values make every ALPM
link wake fail: the sink sets the Link CRC error bit in
DP_PSR_ERROR_STATUS within ~25 ms of it being cleared, on every wake, for
as long as PSR2 is active. Changing the two fields at runtime shows that
the relation between them matters, not the absolute time:

  fast wake 11 / IO wake 11  -> CRC error on every wake
  fast wake 12 / IO wake 11  -> clean
  fast wake 40 / IO wake 40  -> CRC error on every wake
  fast wake 40 / IO wake 20  -> clean
  fast wake 11 / IO wake 20  -> CRC error on every wake

The fast wake sequence has to start strictly before the IO buffer wake.
With the current values PSR2 on this panel only looked usable because
the constant wake failures kept forcing the sink to resync.

Make fast_wake_lines strictly greater than io_wake_lines on display 20+,
or, when already at the maximum, put the IO buffer wake one line below
it. Use the larger of the two in the vblank and guardband checks, which
so far only looked at the IO buffer wake on display 20+.

This is one of the two machines behind the eDP Panel Replay quirk in
intel_quirks.c (Dell XPS 14 DA14260 / XPS 16 DA16260). The change does
not make Panel Replay or PSR2 selective updates work there on its own:
with the wake fixed the panel still never receives a selective update
(sink 0x200a stays at PSR_STATE only) while the PSR2 engine sits in
SU_STANDBY and consumes the TRANS_PUSH frame change events. That is
reported separately on intel-gfx.

Link: https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7682
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
---
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
index f138376..c244273 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.c
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -238,8 +238,29 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp,
 		io_wake_lines = fast_wake_lines = max_wake_lines;
 
 	/* According to Bspec lower limit should be set as 7 lines. */
-	crtc_state->alpm_state.io_wake_lines = max(io_wake_lines, 7);
-	crtc_state->alpm_state.fast_wake_lines = max(fast_wake_lines, 7);
+	io_wake_lines = max(io_wake_lines, 7);
+	fast_wake_lines = max(fast_wake_lines, 7);
+
+	/*
+	 * On display 20+ the extended fast wake sequence programmed in
+	 * ALPM_CTL has to start strictly before the IO buffer wake programmed
+	 * in PSR2_CTL. Both are derived from the same precharge, preamble,
+	 * PHY wake and tFW exit latency above, so they normally end up on the
+	 * same number of lines. With equal values the
+	 * LG panel (sink OUI 00:22:b9) in the Dell XPS 14/16 DA14260/DA16260
+	 * reports a Link CRC error on every link wake. One extra fast wake
+	 * line is enough to fix it; when we are already at the maximum keep
+	 * the IO buffer wake one line below the fast wake instead.
+	 */
+	if (DISPLAY_VER(display) >= 20 && fast_wake_lines <= io_wake_lines) {
+		if (io_wake_lines < max_wake_lines)
+			fast_wake_lines = io_wake_lines + 1;
+		else
+			io_wake_lines = fast_wake_lines - 1;
+	}
+
+	crtc_state->alpm_state.io_wake_lines = io_wake_lines;
+	crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;
 
 	return true;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
index c0933dd..ec80a2e 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1443,7 +1443,8 @@ static bool wake_lines_fit_into_vblank(struct intel_dp *intel_dp,
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 					       crtc_state->alpm_state.fast_wake_lines) :
-			crtc_state->alpm_state.io_wake_lines;
+			max(crtc_state->alpm_state.io_wake_lines,
+			    crtc_state->alpm_state.fast_wake_lines);
 
 	/*
 	 * Guardband has not been computed yet, so we conservatively check if the
@@ -4556,7 +4557,8 @@ void intel_psr_compute_config_late(struct intel_dp *intel_dp,
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			     psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 						    crtc_state->alpm_state.fast_wake_lines) :
-			     crtc_state->alpm_state.io_wake_lines;
+			     max(crtc_state->alpm_state.io_wake_lines,
+				 crtc_state->alpm_state.fast_wake_lines);
 	else
 		wake_lines = 0;
 
@@ -4612,7 +4614,8 @@ int intel_psr_min_guardband(struct intel_crtc_state *crtc_state)
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			     psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 						    crtc_state->alpm_state.fast_wake_lines) :
-			     crtc_state->alpm_state.io_wake_lines;
+			     max(crtc_state->alpm_state.io_wake_lines,
+				 crtc_state->alpm_state.fast_wake_lines);
 	else
 		return 0;
 

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake
  2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
@ 2026-09-03  4:11 ` Hogander, Jouni
  2026-09-03 13:14 ` Jake Steinman
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 8+ messages in thread
From: Hogander, Jouni @ 2026-09-03  4:11 UTC (permalink / raw)
  To: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	j@metarealtyinc.ca
  Cc: ville.syrjala@linux.intel.com, Nikula,  Jani, Manna, Animesh

On Wed, 2026-09-02 at 12:25 -0400, Jake Steinman wrote:
> On display version 20+ the extended fast wake time is programmed in
> ALPM_CTL and the IO buffer wake in PSR2_CTL.
> intel_alpm_compute_params()
> derives both from precharge + preamble + PHY wake + tFW exit latency
> (42 us here); the IO buffer wake only differs when
> io_buffer_wake_time
> is larger than the precharge, which is not the case on this panel. So
> both end up on the same number of scanlines, 11 on this mode.
> 
> On the Dell XPS 16 DA16260 (Panther Lake, LG panel with sink OUI
> 00:22:b9, 3200x2000@120, 4 x 2.7 Gbps, DSC) equal values make every
> ALPM
> link wake fail: the sink sets the Link CRC error bit in
> DP_PSR_ERROR_STATUS within ~25 ms of it being cleared, on every wake,
> for
> as long as PSR2 is active. Changing the two fields at runtime shows
> that
> the relation between them matters, not the absolute time:
> 
>   fast wake 11 / IO wake 11  -> CRC error on every wake
>   fast wake 12 / IO wake 11  -> clean
>   fast wake 40 / IO wake 40  -> CRC error on every wake
>   fast wake 40 / IO wake 20  -> clean
>   fast wake 11 / IO wake 20  -> CRC error on every wake
> 
> The fast wake sequence has to start strictly before the IO buffer
> wake.
> With the current values PSR2 on this panel only looked usable because
> the constant wake failures kept forcing the sink to resync.
> 
> Make fast_wake_lines strictly greater than io_wake_lines on display
> 20+,
> or, when already at the maximum, put the IO buffer wake one line
> below
> it. Use the larger of the two in the vblank and guardband checks,
> which
> so far only looked at the IO buffer wake on display 20+.

Thank you for the patch. Have you tried increasing vblank/guardband
alone? Addition to vblank and guardband your change is also affecting
how PSR2/ALPM is configured.

> 
> This is one of the two machines behind the eDP Panel Replay quirk in
> intel_quirks.c (Dell XPS 14 DA14260 / XPS 16 DA16260). The change
> does
> not make Panel Replay or PSR2 selective updates work there on its
> own:
> with the wake fixed the panel still never receives a selective update
> (sink 0x200a stays at PSR_STATE only) while the PSR2 engine sits in
> SU_STANDBY and consumes the TRANS_PUSH frame change events. That is
> reported separately on intel-gfx.

Your change is conflicting with the spec. It might be a trace to the
actual problem. Please note that io wake time can be >= fast_wake_time
and these formulas are directly taken from our hw spec.

	io_wake_time = max(precharge, io_buffer_wake_time(crtc_state))
+ preamble + phy_wake + tfw_exit_latency;
	fast_wake_time = precharge + preamble + phy_wake +
tfw_exit_latency;

Have you tried fiddling with the fast wake sync pulse count? See
driver/gpu/drm/i915/display/intel_dp_auc.c:intel_dp_aux_fw_sync_len.

We could consider using something like in this patch as a quirk if it
solves your problem.

BR,
Jouni Högander

> 
> Link:
> https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7682
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Cc: Animesh Manna <animesh.manna@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: intel-xe@lists.freedesktop.org
> Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
> ---
> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c
> b/drivers/gpu/drm/i915/display/intel_alpm.c
> index f138376..c244273 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -238,8 +238,29 @@ bool intel_alpm_compute_params(struct intel_dp
> *intel_dp,
>  		io_wake_lines = fast_wake_lines = max_wake_lines;
>  
>  	/* According to Bspec lower limit should be set as 7 lines.
> */
> -	crtc_state->alpm_state.io_wake_lines = max(io_wake_lines,
> 7);
> -	crtc_state->alpm_state.fast_wake_lines =
> max(fast_wake_lines, 7);
> +	io_wake_lines = max(io_wake_lines, 7);
> +	fast_wake_lines = max(fast_wake_lines, 7);
> +
> +	/*
> +	 * On display 20+ the extended fast wake sequence programmed
> in
> +	 * ALPM_CTL has to start strictly before the IO buffer wake
> programmed
> +	 * in PSR2_CTL. Both are derived from the same precharge,
> preamble,
> +	 * PHY wake and tFW exit latency above, so they normally end
> up on the
> +	 * same number of lines. With equal values the
> +	 * LG panel (sink OUI 00:22:b9) in the Dell XPS 14/16
> DA14260/DA16260
> +	 * reports a Link CRC error on every link wake. One extra
> fast wake
> +	 * line is enough to fix it; when we are already at the
> maximum keep
> +	 * the IO buffer wake one line below the fast wake instead.
> +	 */
> +	if (DISPLAY_VER(display) >= 20 && fast_wake_lines <=
> io_wake_lines) {
> +		if (io_wake_lines < max_wake_lines)
> +			fast_wake_lines = io_wake_lines + 1;
> +		else
> +			io_wake_lines = fast_wake_lines - 1;
> +	}
> +
> +	crtc_state->alpm_state.io_wake_lines = io_wake_lines;
> +	crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;
>  
>  	return true;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index c0933dd..ec80a2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1443,7 +1443,8 @@ static bool wake_lines_fit_into_vblank(struct
> intel_dp *intel_dp,
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  					       crtc_state-
> >alpm_state.fast_wake_lines) :
> -			crtc_state->alpm_state.io_wake_lines;
> +			max(crtc_state->alpm_state.io_wake_lines,
> +			    crtc_state->alpm_state.fast_wake_lines);
>  
>  	/*
>  	 * Guardband has not been computed yet, so we conservatively
> check if the
> @@ -4556,7 +4557,8 @@ void intel_psr_compute_config_late(struct
> intel_dp *intel_dp,
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			     psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  						    crtc_state-
> >alpm_state.fast_wake_lines) :
> -			     crtc_state->alpm_state.io_wake_lines;
> +			     max(crtc_state-
> >alpm_state.io_wake_lines,
> +				 crtc_state-
> >alpm_state.fast_wake_lines);
>  	else
>  		wake_lines = 0;
>  
> @@ -4612,7 +4614,8 @@ int intel_psr_min_guardband(struct
> intel_crtc_state *crtc_state)
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			     psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  						    crtc_state-
> >alpm_state.fast_wake_lines) :
> -			     crtc_state->alpm_state.io_wake_lines;
> +			     max(crtc_state-
> >alpm_state.io_wake_lines,
> +				 crtc_state-
> >alpm_state.fast_wake_lines);
>  	else
>  		return 0;
>  


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake
  2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
  2026-09-03  4:11 ` Hogander, Jouni
@ 2026-09-03 13:14 ` Jake Steinman
  2026-09-03 13:17 ` [PATCH v2] drm/i915/alpm: Add a quirk to keep the " Jake Steinman
  2026-09-03 16:09 ` ✗ LGCI.VerificationFailed: failure for drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2) Patchwork
  3 siblings, 0 replies; 8+ messages in thread
From: Jake Steinman @ 2026-09-03 13:14 UTC (permalink / raw)
  To: intel-gfx, intel-xe
  Cc: Jouni Högander, Animesh Manna, Ville Syrjälä,
	Jani Nikula, Rodrigo Vivi

On Wed, 2026-09-03 Jouni Högander wrote:
> Thank you for the patch. Have you tried increasing vblank/guardband
> alone?
> ...
> Have you tried fiddling with the fast wake sync pulse count? See
> driver/gpu/drm/i915/display/intel_dp_auc.c:intel_dp_aux_fw_sync_len.

Tried both today. Each run is 15 s of PSR2 with DP_PSR_ERROR_STATUS
polled every 200 ms and cleared after every read, so the number is how
many polls found the Link CRC error bit set again:

  io/fast 11/11, guardband 60 (stock)          70 of 71
  io/fast 11/11, guardband 127 (full vblank)   70 of 70
  fw sync len 20 -> io/fast 12/12              68 of 69
  fw sync len 24 -> io/fast 13/13              69 of 70
  io/fast 11/12 (this patch)                    0 of 71

Guardband and sync pulse length make no difference, and moving both
wake times up together doesn't either. Only fast > io does.

> Your change is conflicting with the spec. It might be a trace to the
> actual problem.

Understood. I'll respin it as a quirk for this panel (LG, sink OUI
00:22:b9, the DA14260/DA16260 pair) unless you prefer a different key.
DPCD OUI quirk or the device id table next to the Panel Replay entry,
whichever you want.

For what it's worth, with the stock 11/11 the screen keeps updating
under PSR2 only because every wake fails and the sink resyncs (0x2008
reads 3 the whole time). With the wake clean, the SU problem from the
other thread is what you get.

Jake

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] drm/i915/alpm: Add a quirk to keep the fast wake ahead of the IO buffer wake
  2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
  2026-09-03  4:11 ` Hogander, Jouni
  2026-09-03 13:14 ` Jake Steinman
@ 2026-09-03 13:17 ` Jake Steinman
  2026-09-03 16:14   ` sashiko-bot
       [not found]   ` <20260904004308.185788-1-j@metarealtyinc.ca>
  2026-09-03 16:09 ` ✗ LGCI.VerificationFailed: failure for drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2) Patchwork
  3 siblings, 2 replies; 8+ messages in thread
From: Jake Steinman @ 2026-09-03 13:17 UTC (permalink / raw)
  To: intel-gfx, intel-xe
  Cc: Jouni Högander, Animesh Manna, Ville Syrjälä,
	Jani Nikula

The LG panel (sink OUI 00:22:b9) in the Dell XPS 14 DA14260 and XPS 16
DA16260 (Panther Lake) fails every ALPM link wake when the extended fast
wake and the IO buffer wake are programmed to the same number of
scanlines, which the spec formulas produce for it (11/11 lines on
3200x2000@120, 4 x 2.7 Gbps, DSC). The sink sets the Link CRC error bit
in DP_PSR_ERROR_STATUS within ~25 ms of it being cleared, on every wake,
for as long as PSR2 is active.

Measured with DP_PSR_ERROR_STATUS polled every 200 ms and cleared after
each read, 15 s of PSR2 per configuration, number of polls that found
the bit set again:

  io/fast 11/11, guardband 60 (stock)          70 of 71
  io/fast 11/11, guardband 127 (full vblank)   70 of 70
  fast wake sync length 20 -> io/fast 12/12    68 of 69
  fast wake sync length 24 -> io/fast 13/13    69 of 70
  io/fast 11/12                                 0 of 71

A larger guardband or a longer fast wake sync pulse does not help, and
moving both wake times up together does not either. The fast wake has
to start strictly before the IO buffer wake on this panel.

Since the spec allows the IO buffer wake to be equal to or longer than
the fast wake, keep the formulas as they are and apply the relation as
a DPCD quirk for this panel on these two machines: one extra fast wake
line, or the IO buffer wake one line below the fast wake when already
at the maximum. Account for the larger of the two wake times in the
vblank and guardband checks, which only looked at the IO buffer wake on
display 20+.

This does not by itself make PSR2 selective updates or Panel Replay
usable on these machines; with the wake clean the panel still never
receives a selective update. That is tracked separately.

v2: quirk for the affected panel instead of a generic change (Jouni)

Link: https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
---
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
index f138376..79cce5b 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.c
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -15,6 +15,7 @@
 #include "intel_dp.h"
 #include "intel_dp_aux.h"
 #include "intel_psr.h"
+#include "intel_quirks.h"
 #include "intel_psr_regs.h"
 #include "intel_vrr.h"
 
@@ -238,8 +239,29 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp,
 		io_wake_lines = fast_wake_lines = max_wake_lines;
 
 	/* According to Bspec lower limit should be set as 7 lines. */
-	crtc_state->alpm_state.io_wake_lines = max(io_wake_lines, 7);
-	crtc_state->alpm_state.fast_wake_lines = max(fast_wake_lines, 7);
+	io_wake_lines = max(io_wake_lines, 7);
+	fast_wake_lines = max(fast_wake_lines, 7);
+
+	/*
+	 * The LG panel (sink OUI 00:22:b9) in the Dell XPS 14/16
+	 * DA14260/DA16260 reports a Link CRC error on every link wake when
+	 * the extended fast wake and the IO buffer wake are programmed to
+	 * the same number of lines, which the formulas above produce for it.
+	 * Neither a larger guardband nor a longer fast wake sync pulse
+	 * changes that; the fast wake has to start strictly before the IO
+	 * buffer wake. Apply that as a quirk for this panel only.
+	 */
+	if (DISPLAY_VER(display) >= 20 &&
+	    intel_has_dpcd_quirk(intel_dp, QUIRK_ALPM_FAST_WAKE_AHEAD) &&
+	    fast_wake_lines <= io_wake_lines) {
+		if (io_wake_lines < max_wake_lines)
+			fast_wake_lines = io_wake_lines + 1;
+		else
+			io_wake_lines = fast_wake_lines - 1;
+	}
+
+	crtc_state->alpm_state.io_wake_lines = io_wake_lines;
+	crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;
 
 	return true;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
index c0933dd..ec80a2e 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1443,7 +1443,8 @@ static bool wake_lines_fit_into_vblank(struct intel_dp *intel_dp,
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 					       crtc_state->alpm_state.fast_wake_lines) :
-			crtc_state->alpm_state.io_wake_lines;
+			max(crtc_state->alpm_state.io_wake_lines,
+			    crtc_state->alpm_state.fast_wake_lines);
 
 	/*
 	 * Guardband has not been computed yet, so we conservatively check if the
@@ -4556,7 +4557,8 @@ void intel_psr_compute_config_late(struct intel_dp *intel_dp,
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			     psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 						    crtc_state->alpm_state.fast_wake_lines) :
-			     crtc_state->alpm_state.io_wake_lines;
+			     max(crtc_state->alpm_state.io_wake_lines,
+				 crtc_state->alpm_state.fast_wake_lines);
 	else
 		wake_lines = 0;
 
@@ -4612,7 +4614,8 @@ int intel_psr_min_guardband(struct intel_crtc_state *crtc_state)
 		wake_lines = DISPLAY_VER(display) < 20 ?
 			     psr2_block_count_lines(crtc_state->alpm_state.io_wake_lines,
 						    crtc_state->alpm_state.fast_wake_lines) :
-			     crtc_state->alpm_state.io_wake_lines;
+			     max(crtc_state->alpm_state.io_wake_lines,
+				 crtc_state->alpm_state.fast_wake_lines);
 	else
 		return 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
index 33245f4..a5d01ba 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -86,6 +86,14 @@ static void quirk_edp_limit_rate_hbr2(struct intel_display *display)
 	drm_info(display->drm, "Applying eDP Limit rate to HBR2 quirk\n");
 }
 
+static void quirk_alpm_fast_wake_ahead(struct intel_dp *intel_dp)
+{
+	struct intel_display *display = to_intel_display(intel_dp);
+
+	intel_set_dpcd_quirk(intel_dp, QUIRK_ALPM_FAST_WAKE_AHEAD);
+	drm_info(display->drm, "Applying ALPM fast wake ahead of IO buffer wake quirk\n");
+}
+
 static void quirk_disable_edp_panel_replay(struct intel_dp *intel_dp)
 {
 	struct intel_display *display = to_intel_display(intel_dp);
@@ -286,6 +294,21 @@ static const struct intel_dpcd_quirk intel_dpcd_quirks[] = {
 		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
 		.hook = quirk_disable_edp_panel_replay,
 	},
+	/* Dell XPS 14 DA14260 and XPS 16 DA16260, LG panel: ALPM link wake */
+	{
+		.device = DEVICE_ID_ANY,
+		.subsystem_vendor = 0x1028,
+		.subsystem_device = 0x0db9,
+		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
+		.hook = quirk_alpm_fast_wake_ahead,
+	},
+	{
+		.device = DEVICE_ID_ANY,
+		.subsystem_vendor = 0x1028,
+		.subsystem_device = 0x0dba,
+		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
+		.hook = quirk_alpm_fast_wake_ahead,
+	},
 };
 
 void intel_init_quirks(struct intel_display *display)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h b/drivers/gpu/drm/i915/display/intel_quirks.h
index 970a4fe..8bbc2eb 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.h
+++ b/drivers/gpu/drm/i915/display/intel_quirks.h
@@ -23,6 +23,7 @@ enum intel_quirk_id {
 	QUIRK_EDP_LIMIT_RATE_HBR2,
 	QUIRK_DISABLE_EDP_PANEL_REPLAY,
 	QUIRK_DISABLE_PSR2,
+	QUIRK_ALPM_FAST_WAKE_AHEAD,
 };
 
 void intel_init_quirks(struct intel_display *display);

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* ✗ LGCI.VerificationFailed: failure for drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2)
  2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
                   ` (2 preceding siblings ...)
  2026-09-03 13:17 ` [PATCH v2] drm/i915/alpm: Add a quirk to keep the " Jake Steinman
@ 2026-09-03 16:09 ` Patchwork
  3 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2026-09-03 16:09 UTC (permalink / raw)
  To: Jake Steinman; +Cc: intel-xe

== Series Details ==

Series: drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2)
URL   : https://patchwork.freedesktop.org/series/173325/
State : failure

== Summary ==

Series author address 'j@metarealtyinc.ca' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://intel-gfx-ci-public.igk.intel.com:8080/job/xe_pw_trigger/1269428/ (on master)



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] drm/i915/alpm: Add a quirk to keep the fast wake ahead of the IO buffer wake
  2026-09-03 13:17 ` [PATCH v2] drm/i915/alpm: Add a quirk to keep the " Jake Steinman
@ 2026-09-03 16:14   ` sashiko-bot
       [not found]   ` <20260904004308.185788-1-j@metarealtyinc.ca>
  1 sibling, 0 replies; 8+ messages in thread
From: sashiko-bot @ 2026-09-03 16:14 UTC (permalink / raw)
  To: Jake Steinman; +Cc: intel-gfx, intel-xe

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] LOBF guardband and vblank checks do not account for fast_wake_lines, contrary to commit claims.
--

commit 7252754a9cb3de5dc35455a120dc90a19c62a9a4
Author: Jake Steinman <j@metarealtyinc.ca>
Subject: drm/i915/alpm: Add a quirk to keep the fast wake ahead of the IO buffer wake

This commit introduces a DPCD quirk for the LG panel on Dell XPS 14/16
(Panther Lake) to ensure the ALPM fast wake starts strictly before the IO
buffer wake. It modifies the wake time formulas and updates PSR vblank
and guardband checks to account for the larger of the two wake times.

Link: https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521

> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
> index f1383764b7028..79cce5b1fe9f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
[ ... ]
> @@ -238,8 +239,29 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp,
[ ... ]
> +	if (DISPLAY_VER(display) >= 20 &&
> +	    intel_has_dpcd_quirk(intel_dp, QUIRK_ALPM_FAST_WAKE_AHEAD) &&
> +	    fast_wake_lines <= io_wake_lines) {
> +		if (io_wake_lines < max_wake_lines)
> +			fast_wake_lines = io_wake_lines + 1;
> +		else
> +			io_wake_lines = fast_wake_lines - 1;
> +	}
> +
> +	crtc_state->alpm_state.io_wake_lines = io_wake_lines;
> +	crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;

[Severity: Medium]
Do the LOBF checks in intel_alpm.c also need to be updated to account for
fast_wake_lines when it exceeds io_wake_lines due to this quirk?

The commit message states we account for the larger of the two wake times
in the vblank and guardband checks, and the PSR checks in intel_psr.c
were successfully updated.

However, looking at intel_alpm_lobf_min_guardband() in intel_alpm.c:

    waketime_in_lines = max(crtc_state->alpm_state.io_wake_lines,
                            crtc_state->alpm_state.aux_less_wake_lines);

And similarly in intel_alpm_lobf_compute_config_late():

    if (intel_alpm_aux_less_wake_supported(intel_dp))
        waketime_in_lines = crtc_state->alpm_state.io_wake_lines;
    else
        waketime_in_lines = crtc_state->alpm_state.aux_less_wake_lines;

Could this underestimate the ALPM wake time requirements by 1 scanline for
LOBF on the quirked hardware, potentially allowing LOBF to be enabled when
the guardband or vblank duration is insufficient?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903131724.49496-1-j@metarealtyinc.ca?part=1

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] drm/i915/alpm: Add a quirk to keep the fast wake ahead of the IO buffer wake
       [not found]   ` <20260904004308.185788-1-j@metarealtyinc.ca>
@ 2026-09-04  4:47     ` Hogander, Jouni
       [not found]     ` <20260904114835.483057-1-j@metarealtyinc.ca>
  1 sibling, 0 replies; 8+ messages in thread
From: Hogander, Jouni @ 2026-09-04  4:47 UTC (permalink / raw)
  To: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	j@metarealtyinc.ca
  Cc: ville.syrjala@linux.intel.com, Nikula,  Jani, Manna, Animesh

On Thu, 2026-09-03 at 20:43 -0400, Jake Steinman wrote:
> The LG panel (sink OUI 00:22:b9) in the Dell XPS 14 DA14260 and XPS
> 16
> DA16260 (Panther Lake) fails every ALPM link wake when the extended
> fast
> wake and the IO buffer wake are programmed to the same number of
> scanlines, which the spec formulas produce for it (11/11 lines on
> 3200x2000@120, 4 x 2.7 Gbps, DSC). The sink sets the Link CRC error
> bit
> in DP_PSR_ERROR_STATUS within ~25 ms of it being cleared, on every
> wake,
> for as long as PSR2 is active.
> 
> Measured with DP_PSR_ERROR_STATUS polled every 200 ms and cleared
> after
> each read, 15 s of PSR2 per configuration, number of polls that found
> the bit set again:
> 
>   io/fast 11/11, guardband 60 (stock)          70 of 71
>   io/fast 11/11, guardband 127 (full vblank)   70 of 70
>   fast wake sync length 20 -> io/fast 12/12    68 of 69
>   fast wake sync length 24 -> io/fast 13/13    69 of 70
>   io/fast 11/12                                 0 of 71
> 
> A larger guardband or a longer fast wake sync pulse does not help,
> and
> moving both wake times up together does not either. The fast wake has
> to start strictly before the IO buffer wake on this panel.
> 
> Since the spec allows the IO buffer wake to be equal to or longer
> than
> the fast wake, keep the formulas as they are and apply the relation
> as
> a DPCD quirk for this panel on these two machines: one extra fast
> wake
> line, or the IO buffer wake one line below the fast wake when already
> at the maximum. Account for the larger of the two wake times in the
> vblank and guardband checks, PSR and LOBF, which only looked at the
> IO
> buffer wake on display 20+.
> 
> This does not by itself make PSR2 selective updates or Panel Replay
> usable on these machines; with the wake clean the panel still never
> receives a selective update. That is tracked separately.

This patch doesn't help much ATM because we wont get rid of the quirk
disabling selective fetch anyways.

BR,
Jouni Högander

> 
> v3: also account for the fast wake in the LOBF guardband and vblank
>     checks (Sashiko review)
> v2: quirk for the affected panel instead of a generic change (Jouni)
> 
> Link:
> https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Cc: Animesh Manna <animesh.manna@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: intel-xe@lists.freedesktop.org
> Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
> ---
> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c
> b/drivers/gpu/drm/i915/display/intel_alpm.c
> index f138376..04f61fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -15,6 +15,7 @@
>  #include "intel_dp.h"
>  #include "intel_dp_aux.h"
>  #include "intel_psr.h"
> +#include "intel_quirks.h"
>  #include "intel_psr_regs.h"
>  #include "intel_vrr.h"
>  
> @@ -238,8 +239,29 @@ bool intel_alpm_compute_params(struct intel_dp
> *intel_dp,
>  		io_wake_lines = fast_wake_lines = max_wake_lines;
>  
>  	/* According to Bspec lower limit should be set as 7 lines.
> */
> -	crtc_state->alpm_state.io_wake_lines = max(io_wake_lines,
> 7);
> -	crtc_state->alpm_state.fast_wake_lines =
> max(fast_wake_lines, 7);
> +	io_wake_lines = max(io_wake_lines, 7);
> +	fast_wake_lines = max(fast_wake_lines, 7);
> +
> +	/*
> +	 * The LG panel (sink OUI 00:22:b9) in the Dell XPS 14/16
> +	 * DA14260/DA16260 reports a Link CRC error on every link
> wake when
> +	 * the extended fast wake and the IO buffer wake are
> programmed to
> +	 * the same number of lines, which the formulas above
> produce for it.
> +	 * Neither a larger guardband nor a longer fast wake sync
> pulse
> +	 * changes that; the fast wake has to start strictly before
> the IO
> +	 * buffer wake. Apply that as a quirk for this panel only.
> +	 */
> +	if (DISPLAY_VER(display) >= 20 &&
> +	    intel_has_dpcd_quirk(intel_dp,
> QUIRK_ALPM_FAST_WAKE_AHEAD) &&
> +	    fast_wake_lines <= io_wake_lines) {
> +		if (io_wake_lines < max_wake_lines)
> +			fast_wake_lines = io_wake_lines + 1;
> +		else
> +			io_wake_lines = fast_wake_lines - 1;
> +	}
> +
> +	crtc_state->alpm_state.io_wake_lines = io_wake_lines;
> +	crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;
>  
>  	return true;
>  }
> @@ -256,8 +278,9 @@ int intel_alpm_lobf_min_guardband(struct
> intel_crtc_state *crtc_state)
>  	 * is applicable. Currently this information is not readily
>  	 * available in crtc_state, so max will suffice for now.
>  	 */
> -	waketime_in_lines = max(crtc_state-
> >alpm_state.io_wake_lines,
> -				crtc_state-
> >alpm_state.aux_less_wake_lines);
> +	waketime_in_lines = max3(crtc_state-
> >alpm_state.io_wake_lines,
> +				 crtc_state-
> >alpm_state.fast_wake_lines,
> +				 crtc_state-
> >alpm_state.aux_less_wake_lines);
>  
>  	if (!crtc_state->has_lobf)
>  		return 0;
> @@ -314,7 +337,8 @@ void intel_alpm_lobf_compute_config_late(struct
> intel_dp *intel_dp,
>  	 */
>  	first_sdp_position = adjusted_mode->crtc_vtotal -
> adjusted_mode->crtc_vsync_start;
>  	if (intel_alpm_aux_less_wake_supported(intel_dp))
> -		waketime_in_lines = crtc_state-
> >alpm_state.io_wake_lines;
> +		waketime_in_lines = max(crtc_state-
> >alpm_state.io_wake_lines,
> +					crtc_state-
> >alpm_state.fast_wake_lines);
>  	else
>  		waketime_in_lines = crtc_state-
> >alpm_state.aux_less_wake_lines;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index c0933dd..ec80a2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1443,7 +1443,8 @@ static bool wake_lines_fit_into_vblank(struct
> intel_dp *intel_dp,
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  					       crtc_state-
> >alpm_state.fast_wake_lines) :
> -			crtc_state->alpm_state.io_wake_lines;
> +			max(crtc_state->alpm_state.io_wake_lines,
> +			    crtc_state->alpm_state.fast_wake_lines);
>  
>  	/*
>  	 * Guardband has not been computed yet, so we conservatively
> check if the
> @@ -4556,7 +4557,8 @@ void intel_psr_compute_config_late(struct
> intel_dp *intel_dp,
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			     psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  						    crtc_state-
> >alpm_state.fast_wake_lines) :
> -			     crtc_state->alpm_state.io_wake_lines;
> +			     max(crtc_state-
> >alpm_state.io_wake_lines,
> +				 crtc_state-
> >alpm_state.fast_wake_lines);
>  	else
>  		wake_lines = 0;
>  
> @@ -4612,7 +4614,8 @@ int intel_psr_min_guardband(struct
> intel_crtc_state *crtc_state)
>  		wake_lines = DISPLAY_VER(display) < 20 ?
>  			     psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
>  						    crtc_state-
> >alpm_state.fast_wake_lines) :
> -			     crtc_state->alpm_state.io_wake_lines;
> +			     max(crtc_state-
> >alpm_state.io_wake_lines,
> +				 crtc_state-
> >alpm_state.fast_wake_lines);
>  	else
>  		return 0;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 33245f4..a5d01ba 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -86,6 +86,14 @@ static void quirk_edp_limit_rate_hbr2(struct
> intel_display *display)
>  	drm_info(display->drm, "Applying eDP Limit rate to HBR2
> quirk\n");
>  }
>  
> +static void quirk_alpm_fast_wake_ahead(struct intel_dp *intel_dp)
> +{
> +	struct intel_display *display = to_intel_display(intel_dp);
> +
> +	intel_set_dpcd_quirk(intel_dp, QUIRK_ALPM_FAST_WAKE_AHEAD);
> +	drm_info(display->drm, "Applying ALPM fast wake ahead of IO
> buffer wake quirk\n");
> +}
> +
>  static void quirk_disable_edp_panel_replay(struct intel_dp
> *intel_dp)
>  {
>  	struct intel_display *display = to_intel_display(intel_dp);
> @@ -286,6 +294,21 @@ static const struct intel_dpcd_quirk
> intel_dpcd_quirks[] = {
>  		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
>  		.hook = quirk_disable_edp_panel_replay,
>  	},
> +	/* Dell XPS 14 DA14260 and XPS 16 DA16260, LG panel: ALPM
> link wake */
> +	{
> +		.device = DEVICE_ID_ANY,
> +		.subsystem_vendor = 0x1028,
> +		.subsystem_device = 0x0db9,
> +		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
> +		.hook = quirk_alpm_fast_wake_ahead,
> +	},
> +	{
> +		.device = DEVICE_ID_ANY,
> +		.subsystem_vendor = 0x1028,
> +		.subsystem_device = 0x0dba,
> +		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
> +		.hook = quirk_alpm_fast_wake_ahead,
> +	},
>  };
>  
>  void intel_init_quirks(struct intel_display *display)
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h
> b/drivers/gpu/drm/i915/display/intel_quirks.h
> index 970a4fe..8bbc2eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.h
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.h
> @@ -23,6 +23,7 @@ enum intel_quirk_id {
>  	QUIRK_EDP_LIMIT_RATE_HBR2,
>  	QUIRK_DISABLE_EDP_PANEL_REPLAY,
>  	QUIRK_DISABLE_PSR2,
> +	QUIRK_ALPM_FAST_WAKE_AHEAD,
>  };
>  
>  void intel_init_quirks(struct intel_display *display);


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] drm/i915/alpm: Add a quirk to keep the fast wake ahead of the IO buffer wake
       [not found]     ` <20260904114835.483057-1-j@metarealtyinc.ca>
@ 2026-09-04 12:51       ` Hogander, Jouni
  0 siblings, 0 replies; 8+ messages in thread
From: Hogander, Jouni @ 2026-09-04 12:51 UTC (permalink / raw)
  To: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	j@metarealtyinc.ca
  Cc: ville.syrjala@linux.intel.com, Nikula,  Jani, Manna, Animesh

On Fri, 2026-09-04 at 07:48 -0400, Jake Steinman wrote:
> On Thu, 2026-09-04 Jouni Högander wrote:
> > This patch doesn't help much ATM because we wont get rid of the
> > quirk
> > disabling selective fetch anyways.
> 
> Understood. Which quirk is that? As of yesterday's drm-tip this
> machine
> only has the Panel Replay quirk; PSR2 with selective fetch is
> enabled,
> and that is where these CRC errors show up. If selective fetch is
> going
> to be quirked off for the DA16260 as well, then agreed, this can wait
> until the SU problem is understood.

Ok, I understood wrong.

I think PSR2 was working on that setup at the point when I introduced
that quirk

cb8d155b0806 drm/i915/psr: Disable Panel Replay on Dell XPS 16 DA16260
as a quirk

See https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7682

Maybe this is actually matter of bisection?

BR,
Jouni Högander

> 
> The SU problem is
> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119.
> I'd much rather see that fixed than another quirk on this machine,
> and
> I can test whatever you want on it, same day.
> 
> Jake


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-09-04 12:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
2026-09-03  4:11 ` Hogander, Jouni
2026-09-03 13:14 ` Jake Steinman
2026-09-03 13:17 ` [PATCH v2] drm/i915/alpm: Add a quirk to keep the " Jake Steinman
2026-09-03 16:14   ` sashiko-bot
     [not found]   ` <20260904004308.185788-1-j@metarealtyinc.ca>
2026-09-04  4:47     ` [PATCH v3] " Hogander, Jouni
     [not found]     ` <20260904114835.483057-1-j@metarealtyinc.ca>
2026-09-04 12:51       ` Hogander, Jouni
2026-09-03 16:09 ` ✗ LGCI.VerificationFailed: failure for drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2) Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox