* [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms @ 2026-04-17 12:44 Vidya Srinivas 2026-04-17 15:42 ` Ville Syrjälä 0 siblings, 1 reply; 3+ messages in thread From: Vidya Srinivas @ 2026-04-17 12:44 UTC (permalink / raw) To: intel-gfx Cc: intel-xe, uma.shankar, ankit.k.nautiyal, seanpaul, navaremanasi, shawn.c.lee, 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 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms 2026-04-17 12:44 [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms Vidya Srinivas @ 2026-04-17 15:42 ` Ville Syrjälä 2026-04-22 4:18 ` Srinivas, Vidya 0 siblings, 1 reply; 3+ messages in thread From: Ville Syrjälä @ 2026-04-17 15:42 UTC (permalink / raw) To: Vidya Srinivas Cc: intel-gfx, intel-xe, uma.shankar, ankit.k.nautiyal, seanpaul, navaremanasi, shawn.c.lee 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms 2026-04-17 15:42 ` Ville Syrjälä @ 2026-04-22 4:18 ` Srinivas, Vidya 0 siblings, 0 replies; 3+ messages in thread From: Srinivas, Vidya @ 2026-04-22 4:18 UTC (permalink / raw) To: Ville Syrjälä Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Shankar, Uma, Nautiyal, Ankit K, seanpaul@google.com, Navare, Manasi, Lee, Shawn C > -----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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-04-22 4:18 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-04-17 12:44 [PATCH] [RFC]: drm/i915/display: Fix vblank timestamps for fixed RR on VRR-TG-always platforms Vidya Srinivas 2026-04-17 15:42 ` Ville Syrjälä 2026-04-22 4:18 ` Srinivas, Vidya
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox