On Mon, Oct 13, 2025 at 06:05:58PM +0530, Ankit Nautiyal wrote: > Currently, crtc_vblank_start is read from either the VBLANK_START register > (on pre-ADL platforms) or computed as vdisplay + set_context_latency in > intel_get_transcoder_timings(). > > This works when the entire vblank region after vdisplay is treated as > guardband, i.e.: > delayed vblank start = vdisplay + SCL = vtotal - guardband. > > However, with optimized guardband, the guardband becomes shorter, and the > delayed vblank_start moves further away from vdisplay. > > For platforms where intel_vrr_always_use_vrr_tg == false, the delayed > vblank start is only relevant in VRR mode. We retain the original > crtc_vblank_start and apply adjustments in VRR-specific paths. Evasion > logic, push clear already use vtotal - guardband directly for VRR case. > > On platforms where intel_vrr_always_use_vrr_tg == true, the delayed > vblank_start is used in both fixed and VRR modes. So we need to change the > crtc_vblank_start so that fixed rr case works properly. > > Therefore for the readout, we need to overwrite crtc_vblank_start > with vtotal - guardband to ensure correct behavior across both modes. > > This change prepares the pipeline for optimized guardband usage by ensuring > crtc_vblank_start reflects the correct timing on platforms with always-on > VRR TG. > > Signed-off-by: Ankit Nautiyal <[email protected]> > --- > drivers/gpu/drm/i915/display/intel_vrr.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c > b/drivers/gpu/drm/i915/display/intel_vrr.c > index 8d71d7dc9d12..221b25832e56 100644 > --- a/drivers/gpu/drm/i915/display/intel_vrr.c > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c > @@ -821,6 +821,20 @@ void intel_vrr_get_config(struct intel_crtc_state > *crtc_state) > */ > if (crtc_state->vrr.enable) > crtc_state->mode_flags |= I915_MODE_FLAG_VRR; > + > + /* > + * For platforms that always use the VRR timing generator, we overwrite > + * crtc_vblank_start with vtotal - guardband to reflect the delayed > + * vblank start. This works for both default and optimized guardband > values. > + * On other platforms, we keep the original value from > + * intel_get_transcoder_timings() and apply adjustments only in > VRR-specific > + * paths as needed. > + */ > + if (intel_vrr_always_use_vrr_tg(display)) > + crtc_state->hw.adjusted_mode.crtc_vblank_start = > + crtc_state->hw.adjusted_mode.crtc_vtotal - > + crtc_state->vrr.guardband;
You still lost the compute counterpart somewhere. And as mentioned, the new order of compute_pipe_mode()->compute_guardband() will require that we fix up pipe_mode well (in the compute path). Could just do it as 'pipe_mode.crtc_vblank_start = adjusted_mode.crtc_vblank_start' after adjusted_mode has been tweaked. It's a bit annoying that we need that one special pipe_mode handling in the compute path, but there is no counterpart in the readout path. But I suppose the only way to fix that would be to manually account for joiner in the guardband calculations, which might be annoying as well... -- Ville Syrjälä Intel
