From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 4/4] drm/i915/psr: Apply SDP on prior scanline workaround for NVL
Date: Thu, 7 May 2026 12:52:42 +0000 [thread overview]
Message-ID: <bf3c2da2e0c7a0b5aef9f91366ca07345af8cb76.camel@intel.com> (raw)
In-Reply-To: <DM3PPF208195D8D58A9DB70E8251EC20BA3E33F2@DM3PPF208195D8D.namprd11.prod.outlook.com>
On Wed, 2026-05-06 at 07:29 +0000, Kandpal, Suraj wrote:
> > Subject: [PATCH 4/4] drm/i915/psr: Apply SDP on prior scanline
> > workaround
> > for NVL
> >
> > In NVL there is an HW optimization done. When there is an SU
> > triggered in
> > Capture state, Link will be kept ON post Capture CRC SDP. Before
> > valid SU
> > pixels Intel source will transmit dummy pixels. Some TCONS are
> > improperly
> > considering these dummy pixels as a valid pixel data. Prior NVL
> > link was was
> > turned of even if there was SU triggered in Capture state and no
> > dummy pixels
>
> *off
> *capture
>
> > were transmitted. These dummy pixels are problem only if SDP on
> > prior
> > scanline is used and Early Transport is not in use. The workaround
> > is to start
> > SU area always at scanline 0.
> >
> > Bspec: 74741, 79482
> > Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 341186622ed4..28668fed8347 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -2910,6 +2910,11 @@ intel_psr_apply_su_area_workarounds(struct
> > intel_crtc_state *crtc_state)
> > crtc_state->splitter.enable)
> > crtc_state->psr2_su_area.y1 = 0;
> >
> > + /* Wa_16029024088 */
> > + if (DISPLAY_VER(display) >= 35 && crtc_state-
> > > req_psr2_sdp_prior_scanline &&
> > + !crtc_state->enable_psr2_su_region_et)
> > + crtc_state->psr2_su_area.y1 = 0;
>
> I am a little confused as to what the WA is asking from us
> According to Bspec
> "Selective Update Considerations
> When exiting the Capture frame, if there is an SU available, the PSR2
> function will keep the main link awake until the SU has been sent to
> the Panel. Some Panels may have a problem with this behavior which
> will require the Driver to do one of the following (in order of
> priority):
>
> Set 0x3F0 DPCD to 0x2 which means the TCON has no restriction of
> 100nsec between VSC SDP to SU start.
> If above cannot be supported plus the TCON vendor can support early
> transport, then enable early transport.
> If neither of #1 and #2 can be done from TCON, it will be a custom WA
> in driver to always start SU at scanline 0 (this will come as a power
> penalty).
> "
>
> Here it says its driver's responsibility to set 0x3F0 DPCD (I don't
> see that happeining anywhere) but then all we do is just read this
> DPCD and decide if crtc_state-
> > req_psr2_sdp_prior_scanline's value .Is that some sort of typo or
> > am I missing something here ?
Generally this INTEL_WA_REGISTER caps is a capabilities register and
supposed to be read only for driver. To my understanding we are not
supposed to write anything there. Anyways I will ask for clarification
in Bspec just to be sure and to get Bspec corrected on this.
BR,
Jouni Högander
>
> Regards,
> Suraj Kandpal
>
> > +
> > /* Wa 14019834836 */
> > if (DISPLAY_VER(display) == 30)
> > intel_psr_apply_pr_link_on_su_wa(crtc_state);
> > --
> > 2.43.0
>
next prev parent reply other threads:[~2026-05-07 12:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 5:39 [PATCH 0/4] PSR2 SDP on Prior Scanline workarounds Jouni Högander
2026-04-15 5:39 ` [PATCH 1/4] drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register Jouni Högander
2026-04-15 7:28 ` Jani Nikula
2026-04-15 5:39 ` [PATCH 2/4] drm/i915/psr: Read Intel DPCD workaround register Jouni Högander
2026-05-06 6:39 ` Kandpal, Suraj
2026-05-07 12:35 ` Hogander, Jouni
2026-04-15 5:39 ` [PATCH 3/4] drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used Jouni Högander
2026-05-06 7:24 ` Kandpal, Suraj
2026-05-07 12:42 ` Hogander, Jouni
2026-04-15 5:40 ` [PATCH 4/4] drm/i915/psr: Apply SDP on prior scanline workaround for NVL Jouni Högander
2026-05-06 7:29 ` Kandpal, Suraj
2026-05-07 12:52 ` Hogander, Jouni [this message]
2026-04-15 5:49 ` ✗ CI.checkpatch: warning for PSR2 SDP on Prior Scanline workarounds Patchwork
2026-04-15 5:50 ` ✓ CI.KUnit: success " Patchwork
2026-04-15 6:54 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-15 7:40 ` ✓ Xe.CI.FULL: " 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=bf3c2da2e0c7a0b5aef9f91366ca07345af8cb76.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=suraj.kandpal@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