Re: [PATCH 7/8] drm/i915/vrr: Recompute vblank_start for platforms with always-on VRR TG

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

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 <ankit.k.nautiyal@intel.com>
> ---
>  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