Re: [PATCH] drm/i915/display: use set_context_latency for DSB W2-line waits

[Nautiyal, Ankit K]

On 5/18/2026 8:22 PM, Ville Syrjälä wrote:
On Mon, May 18, 2026 at 11:35:22AM +0530, Ankit Nautiyal wrote:
set_context_latency represents W2 window/latency lines.
Earlier, delayed and undelayed vblank coincided, so this matched the
distance from vactive end to undelayed vblank start.

After guardband optimization changes, delayed vblank start can move
away from undelayed vblank. In DSB non-VRR paths, the older
intel_mode_vblank_delay() is still used in some code paths.

Fix this by using set_context_latency directly for W2-line waits.

Signed-off-by: Ankit Nautiyal <ankit.k.nauti...@intel.com>
---
  drivers/gpu/drm/i915/display/intel_dsb.c | 11 ++---------
  1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index fec8a56e21ea..8521f5969aca 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -745,6 +745,7 @@ void intel_dsb_vblank_evade(struct intel_atomic_state 
*state,
                intel_pre_commit_crtc_state(state, crtc);
        int latency = intel_usecs_to_scanlines(&crtc_state->hw.adjusted_mode,
                                               intel_dsb_arm_exec_time_us());
+       int vblank_delay = crtc_state->set_context_latency;
        int start, end;
  
  	/*
@@ -760,7 +761,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state 
*state,
                intel_dsb_emit_wait_dsl(dsb, DSB_OPCODE_WAIT_DSL_OUT, 0, 0);
  
  	if (pre_commit_is_vrr_active(state, crtc) && crtc_state->vrr.dc_balance.enable) {
-               int vblank_delay = crtc_state->set_context_latency;
                int vmin_vblank_start, vmax_vblank_start;
  
  		vmin_vblank_start = intel_vrr_dcb_vmin_vblank_start_next(crtc_state);
@@ -789,8 +789,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state 
*state,
                start = end - vblank_delay - latency;
                intel_dsb_wait_scanline_out(state, dsb, start, end);
        } else if (pre_commit_is_vrr_active(state, crtc)) {
-               int vblank_delay = crtc_state->set_context_latency;
-
                end = intel_vrr_vmin_vblank_start(crtc_state);
                start = end - vblank_delay - latency;
                intel_dsb_wait_scanline_out(state, dsb, start, end);
@@ -799,8 +797,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state 
*state,
                start = end - vblank_delay - latency;
                intel_dsb_wait_scanline_out(state, dsb, start, end);
        } else {
-               int vblank_delay = 
intel_mode_vblank_delay(&crtc_state->hw.adjusted_mode);
-
                end = intel_mode_vblank_start(&crtc_state->hw.adjusted_mode);
                start = end - vblank_delay - latency;
                intel_dsb_wait_scanline_out(state, dsb, start, end);
@@ -889,7 +885,7 @@ void intel_dsb_wait_for_delayed_vblank(struct 
intel_atomic_state *state,
                intel_pre_commit_crtc_state(state, crtc);
        const struct drm_display_mode *adjusted_mode =
                &crtc_state->hw.adjusted_mode;
-       int wait_scanlines;
+       int wait_scanlines = crtc_state->set_context_latency + 1;
  
  	if (pre_commit_is_vrr_active(state, crtc)) {
                /*
@@ -912,9 +908,6 @@ void intel_dsb_wait_for_delayed_vblank(struct 
intel_atomic_state *state,
                 * scanline until the delayed vblank occurs after
                 * TRANS_PUSH has been written.
                 */
-               wait_scanlines = crtc_state->set_context_latency + 1;
-       } else {
-               wait_scanlines = intel_mode_vblank_delay(adjusted_mode);
After further consideration I think the current code is in fact correct.
intel_dsb_wait_vblanks()/DSB_WAIT_FOR_VBLANK will wait for the undelayed
vblank when VRR is disabled, so this does need the full wait.

So I think the actual issue is more of a userspace bug in that they
assume the event fires at vblank_start and guesstimate the deadline
based on the time when the event was received. What they need to do
is calculate the deadline based on the event timestamp.

Another option might be to switch to using the safe window even for
the '!vrr && always_use_vrr_tg()' case. But that probably needs some
actual thought...

Using the safe window for the above case with changing the 
pre_commit_is_vrr_active() to return true for have always_use_vrr_tg() 
works in general.

However there seem to be an issue with non-VRR case:

It looks like WAIT_VBLANKS / DSB_WAIT_FOR_VBLANK is releasing right at 
the vblank edge,

or perhaps sometimes one scanline early (its not SCL though).

So by the time DSB reaches the WAIT_DSL_OUT(safe_window_start, 
vmin_safe_window_end),

PIPEDSL is sitting exactly at safe_window_start (or just below perhaps).

When DSB instruction checks perhaps is sees that this as "not in window" 
and the wait gets skipped.

The following WAIT_USEC(SCL + 1) then starts from too early, and results 
in DSB interrupt getting fired earlier that expected.

Adding a 1 scanline delay (actually even a smaller usec delay is 
sufficient) is helping here.

I am wondering why this is not observed with VRR case, though.


Regards,

Ankit




        }
  
  	intel_dsb_wait_usec(dsb, intel_scanlines_to_usecs(adjusted_mode, wait_scanlines));
--
2.45.2