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: Thu, 23 Oct 2025 06:05:36 +0000 [thread overview]
Message-ID: <1b8c6c6de1e5fe0db83e6ae942dfee7e6f950767.camel@intel.com> (raw)
In-Reply-To: <de1cdae9a3695ac130bcd913ebe6c1e78d49f96d.camel@intel.com>
On Wed, 2025-10-22 at 19:08 +0300, Hogander, Jouni wrote:
> 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.
a New version sent. Please check.
BR,
Jouni Högander
>
> 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-23 6:05 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
2025-10-23 6:05 ` Hogander, Jouni [this message]
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=1b8c6c6de1e5fe0db83e6ae942dfee7e6f950767.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