Re: [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Apr 17, 2026 at 06:14:39PM +0530, Vidya Srinivas wrote:
> On LNL+ VRR timing generator is always active.
> For panels like this
> 
> "2880x1800": 120 709633 2880 2888 2920 3080 1800 1880 1896 1920 0x48 0xa
> "2880x1800":  60 709633 2880 2888 2920 3080 1800 3800 3816 3840 0x40 0xa
> 
> that use the same pixel clock with a stretched vtotal have a large front
> porch. For this case 2880x1800 panel:
> 120Hz: vtotal=1920 (120 lines of front porch)
> 60Hz: vtotal=3840 (2000 lines of front porch)
> 
> When at lower RR (60Hz) and "vrr_enable = false" this issue was seen
> The intel_crtc_active_timings() function is not adjusting
> crtc_vblank_start for the VRR TG when vrr_enable=false, leaving it at
> the raw mode value of 1800 (vactive end). Since the VRR TG counts all
> the way to vtotal=3840, the actual frame latch happens at line 3840
> (16.67ms), but the vblank timestamp was reported at line 1800 (7.8ms).
> 
> This caused Android SurfaceFlinger to miscalculate frame deadlines --
> it received fence signals ~8ms into the 16.67ms frame and concluded
> frames were being presented late, leading to dropped frames during
> heavy workloads like video playback at 60Hz.
> 
> Fix by adjusting crtc_vblank_start, crtc_vblank_end, and crtc_vtotal
> to match the VRR timing generator values when
> intel_vrr_always_use_vrr_tg() is true, even when vrr_enable is false.a

intel_vrr_compute_guardband() is supposed to tweak the
adjusted_mode timings appropriately.

> 
> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_vblank.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
> index 0726a2abed38..8e0798277d5e 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -527,8 +527,26 @@ static void intel_crtc_active_timings(struct drm_display_mode *mode,
>  	drm_mode_init(mode, &crtc_state->hw.adjusted_mode);
>  	*vmax_vblank_start = 0;
>  
> -	if (!vrr_enable)
> +	if (!vrr_enable) {
> +		/*
> +		 * On platforms that always use the VRR timing generator
> +		 * LNL+, even fixed refresh rate modes run
> +		 * through the VRR TG. The actual frame boundary is at
> +		 * flipline (= vtotal), not at vactive end. Without this
> +		 * adjustment, vblank timestamps and flip-done fences are
> +		 * signaled at vactive end (line 1800 for 60Hz) instead of
> +		 * near the real frame boundary, causing
> +		 * compositors like SurfaceFlinger to see ~8ms late fences
> +		 * and drop frames during GPU-heavy workloads.
> +		 */
> +		if (intel_vrr_always_use_vrr_tg(to_intel_display(crtc_state))) {
> +			mode->crtc_vtotal = intel_vrr_vmin_vtotal(crtc_state);
> +			mode->crtc_vblank_end = intel_vrr_vmin_vtotal(crtc_state);
> +			mode->crtc_vblank_start =
> +				intel_vrr_vmin_vblank_start(crtc_state);
> +		}
>  		return;
> +	}
>  
>  	mode->crtc_vtotal = intel_vrr_vmax_vtotal(crtc_state);
>  	mode->crtc_vblank_end = intel_vrr_vmax_vtotal(crtc_state);
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel