On Thu, Oct 23, 2025 at 08:37:14PM +0530, Nautiyal, Ankit K wrote:
>
> On 10/23/2025 8:10 PM, Ville Syrjälä wrote:
> > On Thu, Oct 23, 2025 at 05:57:02PM +0530, Nautiyal, Ankit K wrote:
> >> On 10/23/2025 5:34 PM, Ville Syrjälä wrote:
> >>> On Thu, Oct 23, 2025 at 01:46:14PM +0530, Ankit Nautiyal wrote:
> >>>> Currently the EMP_AS_SDP_TL is set to vrr.vsync_start which is
> >>>> incorrect.
> >>>>
> >>>> As per Bspec:71197 the transmission line must be within the SCL +
> >>>> guardband region. Before guardband optimization, guradband was same as
> >>>> vblank length so EMP_AS_SDP_TL set with vrr.sync_start was falling in
> >>>> this region and it was not giving an issue.
> >>>>
> >>>> Now with optimized guardband, this is falling outside the SCL +
> >>>> guardband region and since the same transmission line is used by VSC SDP
> >>>> also, this results in PSR timeout issues.
> >>>>
> >>>> Further restrictions on the position of the transmission line:
> >>>> 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
> >>>>
> >>>> Fix the EMP_AS_SDP_TL to VTOTAL - (delayed vblank_start - SCL + 1)
> >>>> Internally the HW computes the value as VTOTAL - EMP_AS_SDP_TL.
> >>>>
> >>>> Fixes: e1123e617e51 ("drm/i915/vrr: Program EMP_AS_SDP_TL for DP AS SDP")
> >>>> Cc: Ankit Nautiyal <[email protected]>
> >>>> Cc: Jouni Högander <[email protected]>
> >>>> Signed-off-by: Ankit Nautiyal <[email protected]>
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++++++++---
> >>>> 1 file changed, 9 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> index 92fb72b56f16..dd81d2133aba 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> >>>> @@ -655,18 +655,24 @@ void
> >>>> intel_vrr_set_db_point_and_transmission_line(const struct
> >>>> intel_crtc_state
> >>>> {
> >>>> struct intel_display *display = to_intel_display(crtc_state);
> >>>> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >>>> + const struct drm_display_mode *adjusted_mode =
> >>>> &crtc_state->hw.adjusted_mode;
> >>>> + int transmission_line;
> >>>>
> >>>> /*
> >>>> * For BMG and LNL+ onwards the EMP_AS_SDP_TL is used for
> >>>> programming
> >>>> * double buffering point and transmission line for VRR packets
> >>>> for
> >>>> * HDMI2.1/DP/eDP/DP->HDMI2.1 PCON.
> >>>> * Since currently we support VRR only for DP/eDP, so this is
> >>>> programmed
> >>>> - * to for Adaptive Sync SDP to Vsync start.
> >>>> + * for Adaptive Sync SDP.
> >>>> */
> >>>> - if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >=
> >>>> 20)
> >>>> + if (DISPLAY_VERx100(display) == 1401 || DISPLAY_VER(display) >=
> >>>> 20) {
> >>>> + transmission_line = adjusted_mode->crtc_vtotal -
> >>>> (adjusted_mode->crtc_vblank_start -
> >>>> +
> >>>> crtc_state->set_context_latency +
> >>>> + 1);
> >>>> intel_de_write(display,
> >>>> EMP_AS_SDP_TL(display, cpu_transcoder),
> >>>> -
> >>>> EMP_AS_SDP_DB_TL(crtc_state->vrr.vsync_start));
> >>>> + EMP_AS_SDP_DB_TL(transmission_line));
> >>>> + }
> >>> Pretty sure we are expected to send it at vsync_start.
> >> Hmm.. then do we need to move vsync_start too similar to vblank_start
> >> for optimized guardband?
> > The vsync pulse location is dictated by the timings.
>
> Hmm... then with transmission line set as vsync_start, with a reduced
> guardband we might need to increase the SCL so that vsync_start is more
> or less inside the SCL + guardband.
>
> So, if the panel supports AS_SDP while optimizing the guardband we
> increase the SCL for this.
>From the vblank evasion pov the easiest thing would be to make
delayed vblank match vsync start exactly, and then bump SCL up one
line to deal with whatever PSR issue there is. But that wouldn't
allow us to use the max guardband, so I guess not really an option.
So at the very least we do need to allow guardband > vsync_start,
but that actually already has a vblank evasion issue because we
might be past the delayed vblank but not yet at vsync start when
we write the registers. Fixing that for the DSB should be pretty
easy, but for the MMIO path it'll take more thinking...
And the guardband < vsync_start case I guess could be made to work
as well. The MMIO vblank evasion would need to be updated to evade
the SCL window when the AS SDP needs reprogramming (or at least
evade starting from vsync_start). IIRC the DSB vblank evasion
evades the entire SCL window anyway so should already be fine.
But that last point actually means that the deadline for a commit
is anyway defined by the start of SCL, so not sure there's any actual
benefit from stretching the SCL rather than the guardband.
--
Ville Syrjälä
Intel
