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

["Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>]

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.nautiyal@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