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

[Vidya Srinivas <vidya.srinivas@intel.com>]

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