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: 22+ 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-05-14 6:01 ` Kandpal, Suraj
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-05-14 4:22 ` Kandpal, Suraj
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-05-14 4:26 ` Kandpal, Suraj
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-05-14 4:30 ` Kandpal, Suraj
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:34 ` ✓ i915.CI.BAT: " Patchwork
2026-04-15 6:54 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-15 7:40 ` ✓ Xe.CI.FULL: " Patchwork
2026-04-15 8:50 ` ✗ i915.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.