[PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Jake Steinman]

Since commit 38a7e9bf69bd ("drm/i915/dp: Set relevant Downspread Ctrl
DPCD bits for PR + Auxless ALPM") link training sets
DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (DPCD 0x107 bit 6) whenever eDP
Panel Replay runs with the Adaptive-Sync SDP enabled. That tells the
sink that fixed-vtotal AS SDPs keep coming while PR is active.

When the sink supports asynchronous video timing in PR (DPCD 0xb1
ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR clear),
disable_as_sdp_when_pr_active is set and PR_ALPM_CTL[AS SDP
Transmission in Active Disable] is programmed, so the source stops
sending the AS SDP for as long as PR is active. The sink is promised
AS SDPs that never arrive.

This is not a VRR-only case: intel_vrr_compute_config() always
computes fixed refresh timings with vrr.flipline set, so the AS SDP is
enabled on every eDP sink that supports it (from code reading; the
measurements below used an EDID override).

The commit that added the bit notes that it applies even if AS SDPs
are briefly suspended. With the PR_ALPM_CTL bit set they are not
briefly suspended, they are off for the whole of PR Active.

Commit 186113b419a2 ("drm/i915/dp: Compute and include coasting vtotal
for AS SDP") notes that the hardware reflects the PR_ALPM_CTL bit in
the AS SDP payload. Even so, with 0x107 bit 6 set this sink stutters,
and with it clear it does not (below).

Seen on a Dell XPS 16 DA16260 (Panther Lake, LG eDP panel, sink OUI
00:22:b9, 3200x2000@120 with DSC) with the Panel Replay quirk removed
locally: PR_ALPM_CTL = 0x11, DPCD 0x107 = 0xc0 (bit 7 because this
setup uses an EDID override that adds a 20-120 Hz range with unchanged
timings; the stock EDID has none). The desktop visibly stutters under
Panel Replay while the source flips at a steady 8.33 ms (1434 of 1437
commit intervals over 12 s).

Both ways of making source and sink agree were tested with a local
debug switch selecting each behaviour, PR entered by a full modeset
each time:

  AS SDP kept on in PR Active   PR_ALPM_CTL 0x01, 0x107 0xc0
  (this patch) AS SDP off       PR_ALPM_CTL 0x11, 0x107 0x80

Both are smooth on the desktop right after PR entry. With this patch,
some stutter comes back after several minutes on this panel; that is
left for a separate change. On a static VT (no compositor, one update
per second, 30 s each) the first gets 0 DC5 entries and this patch
gets 550 (DMC DC3->DC5 count; on the KDE desktop neither mode reached
DC5 because the compositor keeps vblank interrupts enabled). So keep
the AS SDP off and stop promising it.

Only set the bit when the source keeps sending the AS SDP in PR
Active: disable_as_sdp_when_pr_active is clear, or AS SDP skip frames
is in use, which clears the PR_ALPM_CTL bit and keeps a periodic AS
SDP going.

Also fix the comment in intel_dp_compute_as_sdp(), added by the
coasting vtotal commit above, which says the PR_ALPM_CTL bit is never
programmed. It was already being programmed when that comment was
added.

Fixes: 38a7e9bf69bd ("drm/i915/dp: Set relevant Downspread Ctrl DPCD bits for PR + Auxless ALPM")
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
---
Notes:

- Based on drm-tip of 2026-09-22, also applies to next-20260922.
  The measurements used an equivalent local debug switch on 7.3-rc4
  (its second setting programs the same PR_ALPM_CTL 0x11 / 0x107 0x80
  as this patch does there). The rc4 version of this change (without
  the skip-frames term, which rc4 lacks) builds but has not been run
  on its own yet. The drm-tip version builds cleanly with W=1 (i915
  and xe) but has not been run.

- Ankit, does this match your reading of the spec for 0x107 bit 6?
  The public material I could find does not settle it; the argument
  here is consistency with PR_ALPM_CTL plus the measurements above.

- With skip frames, a seamless VRR toggle reprograms PR_ALPM_CTL but
  0x107 is only written at link training, so bit 6 can go stale on
  display version 35+ in either direction (also if
  enable_periodic_assdp is toggled without a modeset). Before this
  patch only the bit-set direction could happen. It cannot happen on
  PTL.

- Not fixed here: on this panel, with no AS SDP at all in PR Active,
  a fresh PR enable (e.g. DPMS on after the screen blanked) can leave
  the sink locked to a bad phase, and a 1 s AS SDP burst cleared it. PTL
  appears not to implement the skip-frames field. That and the
  question of how Intel wants it handled are in the bug thread:
  https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
  The DA16260 Panel Replay quirk stays until that is settled.

 drivers/gpu/drm/i915/display/intel_dp.c               | 11 ++++++-----
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11 +++++++++++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ffddf4b33728..f7d32ed98745 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3156,11 +3156,12 @@ static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
 
 	/*
 	 * For Panel Replay with Async Video Timing support, the source can
-	 * disable sending the AS SDP during PR Active state. In that case,
-	 * the sink needs the coasting vtotal value to maintain the refresh
-	 * rate. The HW only samples this on PR_ALPM_CTL[AS SDP Transmission
-	 * in Active Disable], which we never program, so providing the value
-	 * unconditionally when the sink advertises the capability is safe.
+	 * stop sending the AS SDP during PR Active (PR_ALPM_CTL[AS SDP
+	 * Transmission in Active Disable], see intel_alpm_configure_pr_as_sdp())
+	 * and the sink then keeps the refresh rate using the coasting vtotal of
+	 * the last AS SDP it received. The coasting vtotal bytes are fully
+	 * under driver control, so fill them in whenever the sink advertises
+	 * the capability.
 	 *
 	 * #TODO:
 	 * If we ever advertise support for coasting at other refresh targets,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index b6e8b13ee4db..6fe4c1e47eff 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -29,6 +29,7 @@
 #include <drm/display/drm_dp_helper.h>
 #include <drm/drm_print.h>
 
+#include "intel_alpm.h"
 #include "intel_display.h"
 #include "intel_display_core.h"
 #include "intel_display_jiffies.h"
@@ -1124,7 +1125,17 @@ static bool
 intel_dp_pr_with_as_sdp_enabled(struct intel_dp *intel_dp,
 				const struct intel_crtc_state *crtc_state)
 {
+	/*
+	 * DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE tells the sink that the AS SDP
+	 * keeps coming during PR Active. With disable_as_sdp_when_pr_active,
+	 * intel_alpm_configure_pr_as_sdp() sets PR_ALPM_CTL[AS SDP Transmission
+	 * in Active Disable] and the source stops sending it for as long as PR
+	 * is active, unless AS SDP skip frames is used. The sink then keeps
+	 * the refresh rate using the coasting vtotal of the last AS SDP.
+	 */
 	return intel_psr_needs_alpm_aux_less(intel_dp, crtc_state) &&
+		(!crtc_state->disable_as_sdp_when_pr_active ||
+		 intel_alpm_pr_as_sdp_skip_frames_enabled(intel_dp, crtc_state)) &&
 		(crtc_state->infoframes.enable &
 		 intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC));
 }

Re: [PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] drm/i915: build failure due to undefined intel_alpm_pr_as_sdp_skip_frames_enabled()
--

commit b6467ba689abbe92a2f289d4eb766436f8714a78
Author: Jake Steinman <j@metarealtyinc.ca>

drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

This commit conditionally disables DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE
during link training if AS SDP skip frames are not in use. It also attempts
to clarify documentation about when PR_ALPM_CTL[AS SDP Transmission in
Active Disable] is programmed.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119

> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0cd5e6b5034cf..217795e155607 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3154,11 +3154,12 @@ static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
>  
>  	/*
>  	 * For Panel Replay with Async Video Timing support, the source can
> -	 * disable sending the AS SDP during PR Active state. In that case,
> -	 * the sink needs the coasting vtotal value to maintain the refresh
> -	 * rate. The HW only samples this on PR_ALPM_CTL[AS SDP Transmission
> -	 * in Active Disable], which we never program, so providing the value
> -	 * unconditionally when the sink advertises the capability is safe.
> +	 * stop sending the AS SDP during PR Active (PR_ALPM_CTL[AS SDP
> +	 * Transmission in Active Disable], see intel_alpm_configure_pr_as_sdp())

[Severity: Low]
Does the referenced intel_alpm_configure_pr_as_sdp() function exist in the
codebase? A tree-wide search doesn't show it being defined here or in any
subsequent patches. Was this perhaps renamed to lnl_alpm_configure(), or
is there a missing patch dependency?

> +	 * and the sink then keeps the refresh rate using the coasting vtotal of
> +	 * the last AS SDP it received. The coasting vtotal bytes are fully
> +	 * under driver control, so fill them in whenever the sink advertises
> +	 * the capability.
>  	 *
>  	 * #TODO:
>  	 * If we ever advertise support for coasting at other refresh targets,

[ ... ]

> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index cb92cff906146..5729ecaba1499 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1122,7 +1123,17 @@ static bool
>  intel_dp_pr_with_as_sdp_enabled(struct intel_dp *intel_dp,
>  				const struct intel_crtc_state *crtc_state)
>  {
> +	/*
> +	 * DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE tells the sink that the AS SDP
> +	 * keeps coming during PR Active. With disable_as_sdp_when_pr_active,
> +	 * intel_alpm_configure_pr_as_sdp() sets PR_ALPM_CTL[AS SDP Transmission
> +	 * in Active Disable] and the source stops sending it for as long as PR
> +	 * is active, unless AS SDP skip frames is used. The sink then keeps
> +	 * the refresh rate using the coasting vtotal of the last AS SDP.
> +	 */
>  	return intel_psr_needs_alpm_aux_less(intel_dp, crtc_state) &&
> +		(!crtc_state->disable_as_sdp_when_pr_active ||
> +		 intel_alpm_pr_as_sdp_skip_frames_enabled(intel_dp, crtc_state)) &&

[Severity: Low]
Is intel_alpm_pr_as_sdp_skip_frames_enabled() defined anywhere in this tree?
This causes a build failure due to an implicit declaration and undefined
reference.

Additionally, the commit message states that when AS SDP skip frames are in
use, it clears the PR_ALPM_CTL bit and keeps a periodic AS SDP going.
However, looking at lnl_alpm_configure() in intel_alpm.c, the bit seems to
be programmed without a skip frames check:

	if (crtc_state->disable_as_sdp_when_pr_active)
		pr_alpm_ctl |= PR_ALPM_CTL_AS_SDP_TRANSMISSION_IN_ACTIVE_DISABLE;

Are we missing the patch that introduces both these missing functions and the
updated PR_ALPM_CTL programming logic?

>  		(crtc_state->infoframes.enable &
>  		 intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC));
>  }

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

Re: [PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Jake Steinman]

On Wed, 23 Sep 2026 sashiko-bot wrote:
> Is intel_alpm_pr_as_sdp_skip_frames_enabled() defined anywhere in this tree?

The patch is based on drm-intel-next / drm-tip, which have the AS SDP
skip frames series (8dbe5c47ca42, dc0fd724e13a, eddf77ff1a23,
9ed39b7d74b4). intel_alpm_configure_pr_as_sdp() and
intel_alpm_pr_as_sdp_skip_frames_enabled() come from that series, and
the patch builds there with W=1 for both i915 and xe. The tree used for
the review predates it. I'll add a base-commit line next time.

Jake

✗ LGCI.VerificationFailed: failure for drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled
URL   : https://patchwork.freedesktop.org/series/174810/
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://gfx-ci.igk.intel.com:8080/job/CI_PW_kernel/188382/ (on built-in)

Re: [PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Jake Steinman]

Hi Jouni, all,

Gentle ping, with an update on the stutter left open in the notes.

AS SDP bursts turned out not to be reliable on this panel, but leaving
the AS SDP on in PR Active is always smooth, also with 0x107 bit 6
clear. What works here now: clear PR_ALPM_CTL[AS SDP Transmission in
Active Disable] while vblank interrupts are enabled and set it again
when they are disabled. PR already holds DC_OFF while vblank is on
(intel_psr_notify_vblank_enable_disable()), so this costs no DC5/DC6
residency. Smooth here so far; I switched to it this morning.

Would that be acceptable upstream for sinks with async video timing in
PR? Happy to send it as an RFC on top of this patch.

Thanks,
Jake

[RFC PATCH] drm/i915/psr: Send the AS SDP in PR Active while vblank is enabled

[Jake Steinman]

Sinks that support async video timing in PR get the AS SDP suspended in
PR Active (disable_as_sdp_when_pr_active). The LG panel in the Dell XPS
16 DA16260 (sink OUI 00:22:b9, "Balsa2") then judders while frames are
updating, with the source flipping at a steady 8.33 ms. Leaving the AS
SDP on fixes it but blocks DC5/DC6.

Clear PR_ALPM_CTL[AS SDP Transmission in Active Disable] while vblank
interrupts are enabled and set it again when they are disabled. Panel
Replay already holds DC_OFF while vblank is enabled, so no DC5/DC6
residency is lost. Not done when AS SDP skip frames is in use.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8930
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
---
Jouni, this is the fix for the stutter in the thread below. The 0x107
bit 6 patch there is still correct but is not enough on its own.
https://lore.kernel.org/r/20260923041342.2146450-1-j@metarealtyinc.ca

- Run as an equivalent change on 7.3-rc4 and rc5 (PTL, xe) since 28 Sep:
  smooth, DC5 still reached when idle. This drm-tip version is build
  tested only (W=1, i915 and xe).
- A seamless VRR toggle rewrites PR_ALPM_CTL through
  intel_alpm_configure_pr_as_sdp() and sets the bit again until the
  next vblank enable. Not handled here.
- A second machine shows the same thing: XPS 13 (1028:0e53, same sink
  OUI), fixed downstream by exiting PR on every flush (issue 8930).
- Separate from this: the panel judders for a few seconds after panel
  power-on. Locally I hold PR inactive after power-on; 3 s was not
  quite enough, 8 s is clean. Not part of this patch.
- CI has never run on my patches (address not on the allowlist, asked
  twice). Could someone trigger it for this one and for series 174810?
 .../drm/i915/display/intel_display_types.h    |  3 ++
 drivers/gpu/drm/i915/display/intel_psr.c      | 36 ++++++++++++++++++-
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0e3083e85..75113ed10 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1816,6 +1816,9 @@ struct intel_psr {
 	bool dc3co_allowed;
 	/* DC3CO disable work */
 	struct delayed_work dc3co_work;
+	/* AS SDP in PR Active follows vblank enable */
+	bool pr_as_sdp_follow_vblank;
+	bool vblank_enabled;
 	u16 su_w_granularity;
 	u16 su_y_granularity;
 	bool source_panel_replay_support;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
index 00d0146b2..0f0b1fc94 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2166,6 +2166,29 @@ static bool psr_interrupt_error_check(struct intel_dp *intel_dp)
 	return true;
 }
 
+/*
+ * Sinks that support async video timing in PR get the AS SDP suspended in PR
+ * Active. Some then drift out of phase with the source and judder while
+ * frames are being updated. Send the AS SDP in PR Active while vblank
+ * interrupts are enabled: Panel Replay holds DC_OFF then anyway, so this
+ * costs no DC5/DC6 residency. Suspend it again when vblank interrupts are
+ * disabled, before DC_OFF is dropped.
+ */
+static void intel_psr_pr_as_sdp_update(struct intel_dp *intel_dp)
+{
+	struct intel_display *display = to_intel_display(intel_dp);
+
+	lockdep_assert_held(&intel_dp->psr.lock);
+
+	if (!intel_dp->psr.enabled || !intel_dp->psr.pr_as_sdp_follow_vblank)
+		return;
+
+	intel_de_rmw(display, PR_ALPM_CTL(display, intel_dp->psr.transcoder),
+		     PR_ALPM_CTL_AS_SDP_TRANSMISSION_IN_ACTIVE_DISABLE,
+		     intel_dp->psr.vblank_enabled ? 0 :
+		     PR_ALPM_CTL_AS_SDP_TRANSMISSION_IN_ACTIVE_DISABLE);
+}
+
 static void intel_psr_enable_locked(struct intel_dp *intel_dp,
 				    const struct intel_crtc_state *crtc_state)
 {
@@ -2225,6 +2248,12 @@ static void intel_psr_enable_locked(struct intel_dp *intel_dp,
 	intel_dp->psr.enabled = true;
 	intel_dp->psr.pause_counter = 0;
 
+	intel_dp->psr.pr_as_sdp_follow_vblank = crtc_state->has_panel_replay &&
+		crtc_state->disable_as_sdp_when_pr_active &&
+		intel_dp->as_sdp_supported && intel_dp_is_edp(intel_dp) &&
+		!intel_alpm_pr_as_sdp_skip_frames_enabled(intel_dp, crtc_state);
+	intel_psr_pr_as_sdp_update(intel_dp);
+
 	/*
 	 * Link_ok is sticky and set here on PSR enable. We can assume link
 	 * training is complete as we never continue to PSR enable with
@@ -2400,6 +2429,7 @@ static void intel_psr_disable_locked(struct intel_dp *intel_dp)
 	intel_dp->psr.pkg_c_latency_used = 0;
 	cancel_delayed_work(&intel_dp->psr.dc3co_work);
 	intel_dp->psr.dc3co_allowed = false;
+	intel_dp->psr.pr_as_sdp_follow_vblank = false;
 }
 
 /**
@@ -4163,7 +4193,11 @@ void intel_psr_notify_vblank_enable_disable(struct intel_display *display,
 				intel_dp->psr.vblank_wakeref =
 					intel_display_power_get(display,
 								POWER_DOMAIN_DC_OFF);
-			else
+
+			intel_dp->psr.vblank_enabled = enable;
+			intel_psr_pr_as_sdp_update(intel_dp);
+
+			if (!enable)
 				intel_display_power_put(display, POWER_DOMAIN_DC_OFF,
 							intel_dp->psr.vblank_wakeref);
 		}

base-commit: daeb062fc40f727fafefed080c6d12a5ad1d0d12
-- 
2.56.0

Re: [RFC PATCH] drm/i915/psr: Send the AS SDP in PR Active while vblank is enabled

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/i915/psr: wakeref leak and double-put in intel_psr_notify_vblank_enable_disable()
- [Low] drm/i915: Use of undeclared function intel_alpm_pr_as_sdp_skip_frames_enabled
--

commit 83416e4f5b6b0591037f900cd3b6bc4bc168af5c
Author: Jake Steinman <j@metarealtyinc.ca>

drm/i915/psr: Send the AS SDP in PR Active while vblank is enabled

Sinks that support async video timing in PR get the AS SDP suspended in
PR Active (disable_as_sdp_when_pr_active). The LG panel in the Dell XPS
16 DA16260 (sink OUI 00:22:b9, "Balsa2") then judders while frames are
updating, with the source flipping at a steady 8.33 ms. Leaving the AS
SDP on fixes it but blocks DC5/DC6.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8930

> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
> index f490beb66629e..f69df2147c9d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
[ ... ]
> @@ -2221,6 +2244,12 @@ static void intel_psr_enable_locked(struct intel_dp *intel_dp,
>  	intel_dp->psr.enabled = true;
>  	intel_dp->psr.pause_counter = 0;
>  
> +	intel_dp->psr.pr_as_sdp_follow_vblank = crtc_state->has_panel_replay &&
> +		crtc_state->disable_as_sdp_when_pr_active &&
> +		intel_dp->as_sdp_supported && intel_dp_is_edp(intel_dp) &&
> +		!intel_alpm_pr_as_sdp_skip_frames_enabled(intel_dp, crtc_state);

[Severity: Low]
Is this function call missing a declaration? The function
intel_alpm_pr_as_sdp_skip_frames_enabled() is neither defined nor declared
in the tree at this commit.

It appears to depend on an out-of-tree series, which causes a compilation
failure due to an implicit declaration.

> +	intel_psr_pr_as_sdp_update(intel_dp);
> +
>  	/*
>  	 * Link_ok is sticky and set here on PSR enable. We can assume link
>  	 * training is complete as we never continue to PSR enable with
[ ... ]
> @@ -4144,7 +4174,11 @@ void intel_psr_notify_vblank_enable_disable(struct intel_display *display,
>  				intel_dp->psr.vblank_wakeref =
>  					intel_display_power_get(display,
>  								POWER_DOMAIN_DC_OFF);
> -			else
> +
> +			intel_dp->psr.vblank_enabled = enable;
> +			intel_psr_pr_as_sdp_update(intel_dp);
> +
> +			if (!enable)
>  				intel_display_power_put(display, POWER_DOMAIN_DC_OFF,
>  							intel_dp->psr.vblank_wakeref);
>  		}

[Severity: High]
Does this loop cause unbalanced power tracking and a wakeref leak?

for_each_intel_encoder_with_psr() iterates over both the primary DP encoder
and its MST stream encoders, executing multiple times for the same
intel_dp pointer.

When enable is true, intel_dp->psr.vblank_wakeref is assigned repeatedly,
leaking all but the last tracker and leaking POWER_DOMAIN_DC_OFF references.

When enable is false, the single saved wakeref is freed multiple times,
causing a double-free or an underflow of the power domain use count.

Additionally, CAN_PANEL_REPLAY() evaluates sink capabilities which can change
dynamically across hotplugs. If the capability changes between the true and
false calls, does this break the symmetry of the wakeref lifecycle?

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

Re: [PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Hogander, Jouni]

On Wed, 2026-09-23 at 00:13 -0400, Jake Steinman wrote:
> Since commit 38a7e9bf69bd ("drm/i915/dp: Set relevant Downspread Ctrl
> DPCD bits for PR + Auxless ALPM") link training sets
> DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (DPCD 0x107 bit 6) whenever
> eDP
> Panel Replay runs with the Adaptive-Sync SDP enabled. That tells the
> sink that fixed-vtotal AS SDPs keep coming while PR is active.
> 
> When the sink supports asynchronous video timing in PR (DPCD 0xb1
> ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR clear),
> disable_as_sdp_when_pr_active is set and PR_ALPM_CTL[AS SDP
> Transmission in Active Disable] is programmed, so the source stops
> sending the AS SDP for as long as PR is active. The sink is promised
> AS SDPs that never arrive.
> 
> This is not a VRR-only case: intel_vrr_compute_config() always
> computes fixed refresh timings with vrr.flipline set, so the AS SDP
> is
> enabled on every eDP sink that supports it (from code reading; the
> measurements below used an EDID override).
> 
> The commit that added the bit notes that it applies even if AS SDPs
> are briefly suspended. With the PR_ALPM_CTL bit set they are not
> briefly suspended, they are off for the whole of PR Active.
> 
> Commit 186113b419a2 ("drm/i915/dp: Compute and include coasting
> vtotal
> for AS SDP") notes that the hardware reflects the PR_ALPM_CTL bit in
> the AS SDP payload. Even so, with 0x107 bit 6 set this sink stutters,
> and with it clear it does not (below).
> 
> Seen on a Dell XPS 16 DA16260 (Panther Lake, LG eDP panel, sink OUI
> 00:22:b9, 3200x2000@120 with DSC) with the Panel Replay quirk removed
> locally: PR_ALPM_CTL = 0x11, DPCD 0x107 = 0xc0 (bit 7 because this
> setup uses an EDID override that adds a 20-120 Hz range with
> unchanged
> timings; the stock EDID has none). The desktop visibly stutters under
> Panel Replay while the source flips at a steady 8.33 ms (1434 of 1437
> commit intervals over 12 s).
> 
> Both ways of making source and sink agree were tested with a local
> debug switch selecting each behaviour, PR entered by a full modeset
> each time:
> 
>   AS SDP kept on in PR Active   PR_ALPM_CTL 0x01, 0x107 0xc0
>   (this patch) AS SDP off       PR_ALPM_CTL 0x11, 0x107 0x80
> 
> Both are smooth on the desktop right after PR entry. With this patch,
> some stutter comes back after several minutes on this panel; that is
> left for a separate change. On a static VT (no compositor, one update
> per second, 30 s each) the first gets 0 DC5 entries and this patch
> gets 550 (DMC DC3->DC5 count; on the KDE desktop neither mode reached
> DC5 because the compositor keeps vblank interrupts enabled). So keep
> the AS SDP off and stop promising it.
> 
> Only set the bit when the source keeps sending the AS SDP in PR
> Active: disable_as_sdp_when_pr_active is clear, or AS SDP skip frames
> is in use, which clears the PR_ALPM_CTL bit and keeps a periodic AS
> SDP going.
> 
> Also fix the comment in intel_dp_compute_as_sdp(), added by the
> coasting vtotal commit above, which says the PR_ALPM_CTL bit is never
> programmed. It was already being programmed when that comment was
> added.
> 
> Fixes: 38a7e9bf69bd ("drm/i915/dp: Set relevant Downspread Ctrl DPCD
> bits for PR + Auxless ALPM")
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Cc: Animesh Manna <animesh.manna@intel.com>
> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Cc: Uma Shankar <uma.shankar@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
> ---
> Notes:
> 
> - Based on drm-tip of 2026-09-22, also applies to next-20260922.
>   The measurements used an equivalent local debug switch on 7.3-rc4
>   (its second setting programs the same PR_ALPM_CTL 0x11 / 0x107 0x80
>   as this patch does there). The rc4 version of this change (without
>   the skip-frames term, which rc4 lacks) builds but has not been run
>   on its own yet. The drm-tip version builds cleanly with W=1 (i915
>   and xe) but has not been run.
> 
> - Ankit, does this match your reading of the spec for 0x107 bit 6?
>   The public material I could find does not settle it; the argument
>   here is consistency with PR_ALPM_CTL plus the measurements above.
> 
> - With skip frames, a seamless VRR toggle reprograms PR_ALPM_CTL but
>   0x107 is only written at link training, so bit 6 can go stale on
>   display version 35+ in either direction (also if
>   enable_periodic_assdp is toggled without a modeset). Before this
>   patch only the bit-set direction could happen. It cannot happen on
>   PTL.
> 
> - Not fixed here: on this panel, with no AS SDP at all in PR Active,
>   a fresh PR enable (e.g. DPMS on after the screen blanked) can leave
>   the sink locked to a bad phase, and a 1 s AS SDP burst cleared it.
> PTL
>   appears not to implement the skip-frames field. That and the
>   question of how Intel wants it handled are in the bug thread:
>  
> https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
>   The DA16260 Panel Replay quirk stays until that is settled.
> 
>  drivers/gpu/drm/i915/display/intel_dp.c               | 11 ++++++---
> --
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11
> +++++++++++
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ffddf4b33728..f7d32ed98745 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3156,11 +3156,12 @@ static void intel_dp_compute_as_sdp(struct
> intel_dp *intel_dp,
>  
>  	/*
>  	 * For Panel Replay with Async Video Timing support, the
> source can
> -	 * disable sending the AS SDP during PR Active state. In
> that case,
> -	 * the sink needs the coasting vtotal value to maintain the
> refresh
> -	 * rate. The HW only samples this on PR_ALPM_CTL[AS SDP
> Transmission
> -	 * in Active Disable], which we never program, so providing
> the value
> -	 * unconditionally when the sink advertises the capability
> is safe.
> +	 * stop sending the AS SDP during PR Active (PR_ALPM_CTL[AS
> SDP
> +	 * Transmission in Active Disable], see
> intel_alpm_configure_pr_as_sdp())
> +	 * and the sink then keeps the refresh rate using the
> coasting vtotal of
> +	 * the last AS SDP it received. The coasting vtotal bytes
> are fully
> +	 * under driver control, so fill them in whenever the sink
> advertises
> +	 * the capability.
>  	 *
>  	 * #TODO:
>  	 * If we ever advertise support for coasting at other
> refresh targets,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index b6e8b13ee4db..6fe4c1e47eff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -29,6 +29,7 @@
>  #include <drm/display/drm_dp_helper.h>
>  #include <drm/drm_print.h>
>  
> +#include "intel_alpm.h"
>  #include "intel_display.h"
>  #include "intel_display_core.h"
>  #include "intel_display_jiffies.h"
> @@ -1124,7 +1125,17 @@ static bool
>  intel_dp_pr_with_as_sdp_enabled(struct intel_dp *intel_dp,
>  				const struct intel_crtc_state
> *crtc_state)
>  {
> +	/*
> +	 * DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE tells the sink
> that the AS SDP
> +	 * keeps coming during PR Active. With
> disable_as_sdp_when_pr_active,
> +	 * intel_alpm_configure_pr_as_sdp() sets PR_ALPM_CTL[AS SDP
> Transmission
> +	 * in Active Disable] and the source stops sending it for as
> long as PR
> +	 * is active, unless AS SDP skip frames is used. The sink
> then keeps
> +	 * the refresh rate using the coasting vtotal of the last AS
> SDP.
> +	 */
>  	return intel_psr_needs_alpm_aux_less(intel_dp, crtc_state)
> &&
> +		(!crtc_state->disable_as_sdp_when_pr_active ||
> +		 intel_alpm_pr_as_sdp_skip_frames_enabled(intel_dp,
> crtc_state)) &&
>  		(crtc_state->infoframes.enable &
>  		 intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC));
>  }

How about if you just keep AS_SDP enabled when PR is active? I.e:

static inline bool compute_disable_as_sdp_when_pr_active(struct
intel_connector *connector)
{
	return false;
}
 
Is that solving all problems with the panel?

BR,
Jouni Högander

Re: [PATCH] drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled

[Jake Steinman]

Hi Jouni,

Thanks, that makes sense. Glad the AS SDP turned out to be the cause,
and the eDP 1.5 text explains why the driver got there. Your patch is
the right fix for the default.

AS SDP always on in PR Active is smooth here every time (tested as
PR_ALPM_CTL 0x01 with 0x107 0xc0, not with your exact patch). It does
cost DC5 on a static screen: 0 DC5 entries in 30 s on a static VT
against 550 with the AS SDP off in PR Active.

I have not measured the power yet. As an estimate: DC5/DC6 with the
screen on is what lets the package reach its deep idle states, so on
a static screen this could be worth roughly 5-15% of battery life in
mixed use. I can measure it against your patch if that helps.

This panel does run without the AS SDP. The RFC I sent keeps it on
while vblank is enabled and suspends it when idle; that has been
smooth here for over a week with DC5/DC6 intact.
https://lore.kernel.org/r/20261006220500.3417572-1-j@metarealtyinc.ca

Could that stay available on top of your patch for panels that handle
it, off by default? I can't prove it, but I would be surprised if Dell
and LG shipped this panel with that capability and Windows did not use
it for battery life. I can rebase the RFC onto your patch.

Separate issue, not solved by either: a few seconds of judder after
panel power-on. Locally I hold PR inactive for 8 s after power-on.

Thanks,
Jake

✗ LGCI.VerificationFailed: failure for drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Don't promise AS SDPs in PR Active when they are disabled (rev2)
URL   : https://patchwork.freedesktop.org/series/174810/
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://gfx-ci.igk.intel.com:8080/job/CI_PW_kernel/189751/ (on built-in)