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

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

[Vidya Srinivas]

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.

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

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

[Ville Syrjälä]

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

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

[Srinivas, Vidya]

> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Sent: 17 April 2026 21:13
> To: Srinivas, Vidya <vidya.srinivas@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; intel-xe@lists.freedesktop.org; Shankar,
> Uma <uma.shankar@intel.com>; Nautiyal, Ankit K
> <ankit.k.nautiyal@intel.com>; seanpaul@google.com; Navare, Manasi
> <navaremanasi@google.com>; Lee, Shawn C <shawn.c.lee@intel.com>
> Subject: Re: [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed
> RR on VRR-TG-always platforms
> 
> 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.

Hello Ville,

Apologies for missing this. Thank you so much.
Will check what else might be wrong in our case.

Regards
Vidya

> 
> >
> > 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