From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/display: Take into account AS SDP in intel_dp_sdp_min_guardband
Date: Wed, 22 Oct 2025 16:08:42 +0000 [thread overview]
Message-ID: <de1cdae9a3695ac130bcd913ebe6c1e78d49f96d.camel@intel.com> (raw)
In-Reply-To: <aPj6LCMluIBg5J1W@intel.com>
On Wed, 2025-10-22 at 18:37 +0300, Ville Syrjälä wrote:
> On Wed, Oct 22, 2025 at 03:25:52PM +0300, Jouni Högander wrote:
> > We started seeing "[drm] *ERROR* Timed out waiting PSR idle state"
> > after
> > taking optimized guardband into use. These are seen because VSC
> > SDPs are
> > sent on same line as AS SDPs when AS SDP is enabled. AS SDP is sent
> > on line
> > configured in EMP_AS_SDP_TL register. We are configuring
> > crtc_state->vrr.vsync_start into that register.
> >
> > Fix this by ensuring AS SDP is sent on line which is within
> > guardband. From the bspec:
> >
> > EMP_AS_SDP_TL < SCL + Guardband
> >
> > Bspec: 71197
> >
> > Fixes: 52ecd48b8d3f ("drm/i915/dp: Add helper to get min sdp
> > guardband")
> > Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index b0aeb6c2de86c..54b5e060be82a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -7026,7 +7026,7 @@ int intel_dp_compute_config_late(struct
> > intel_encoder *encoder,
> > }
> >
> > static
> > -int intel_dp_get_lines_for_sdp(u32 type)
> > +int intel_dp_get_lines_for_sdp(const struct intel_crtc_state
> > *crtc_state, u32 type)
> > {
> > switch (type) {
> > case DP_SDP_VSC_EXT_VESA:
> > @@ -7036,6 +7036,8 @@ int intel_dp_get_lines_for_sdp(u32 type)
> > return 8;
> > case DP_SDP_PPS:
> > return 7;
> > + case DP_SDP_ADAPTIVE_SYNC:
> > + return crtc_state->vrr.vsync_start + 1;
>
> Is the +1 actually needed? I get the impression the bspec page isn't
> being very accurate with the '<' usage.
>
> Hmm, there is an extra note in the EMP_AS_SDP_TL register:
> "For DP/eDP, if there is a set context latency (SCL) window, then it
> cannot be the first line of SCL
> For DP/eDP, if there is no SCL window, then it cannot be the first
> line
> of the Delayed V. Blank"
> So I guess there might be a real reason for that extra line.
I actually tested without that +1 and I still saw those timeouts. So
that also supports the idea we need that.
>
> Though I'm pretty sure no one has even confirmed that we don't have
> any
> off by one errors in EMP_AS_SDP_TL/etc. Should do that at some
> point...
>
> > default:
> > break;
> > }
> > @@ -7052,11 +7054,18 @@ int intel_dp_sdp_min_guardband(const struct
> > intel_crtc_state *crtc_state,
> > crtc_state->infoframes.enable &
> >
> > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA))
> > sdp_guardband = max(sdp_guardband,
> > -
> > intel_dp_get_lines_for_sdp(HDMI_PACKET_TYPE_GAMUT_METADATA));
> > +
> > intel_dp_get_lines_for_sdp(crtc_state,
> > +
> > HDMI_PACKET_TYPE_GAMUT_METADATA));
> >
> > if (assume_all_enabled ||
> > crtc_state->dsc.compression_enable)
> > - sdp_guardband = max(sdp_guardband,
> > intel_dp_get_lines_for_sdp(DP_SDP_PPS));
> > + sdp_guardband = max(sdp_guardband,
> > +
> > intel_dp_get_lines_for_sdp(crtc_state, DP_SDP_PPS));
> > +
> > + if (assume_all_enabled ||
>
> assume_all_enable && HAS_AS_SDP() ?
Ok, I will change this.
BR,
Jouni Högander
>
> > + crtc_state->infoframes.enable &
> > intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC))
> > + sdp_guardband = max(sdp_guardband,
> > +
> > intel_dp_get_lines_for_sdp(crtc_state, DP_SDP_ADAPTIVE_SYNC));
> >
> > return sdp_guardband;
> > }
> > --
> > 2.43.0
>
next prev parent reply other threads:[~2025-10-22 16:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 12:25 [PATCH] drm/i915/display: Take into account AS SDP in intel_dp_sdp_min_guardband Jouni Högander
2025-10-22 15:37 ` Ville Syrjälä
2025-10-22 16:08 ` Hogander, Jouni [this message]
2025-10-23 6:05 ` Hogander, Jouni
2025-10-22 20:31 ` ✓ CI.KUnit: success for " Patchwork
2025-10-22 21:36 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-23 1:36 ` ✗ Xe.CI.Full: failure " Patchwork
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=de1cdae9a3695ac130bcd913ebe6c1e78d49f96d.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.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