Re: [PATCH 00/16] Optimize vrr.guardband and fix LRR

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

On Tue, Oct 07, 2025 at 12:03:47PM +0530, Nautiyal, Ankit K wrote:
> 
> On 10/7/2025 4:20 AM, Ville Syrjälä wrote:
> > On Mon, Oct 06, 2025 at 09:58:36AM +0530, Ankit Nautiyal wrote:
> >
> > I'd like to see a separate series with just the patches to fix
> > the crtc_vblank_start stuff, which I think is roughly these:
> >
> >>    drm/i915/vrr: Use crtc_vsync_start/end for computing  vrr.vsync_start/end
> >>    drm/i915/vrr: s/intel_vrr_compute_config_late/intel_vrr_compute_guardband
> >>    drm/i915/vblank: Add helper to get correct vblank length
> >>    drm/i915/vrr: Recompute vblank_start for platforms with always-on VRR TG
> >>    drm/i915/display: Add vblank_start adjustment logic for always-on VRR TG
> > (+ whatever is needed to sort out the issues I outlined in the
> >   indiviual replies)
> >
> > That is really just fixing existing things, and has nothing to
> > do with any of the prefill stuff/etc. in the rest of the series.
> 
> 
> Alright I can send a separate series for this.
> 
> 
> Then optimized guardband and pipeline fill thing can wait.
> 
> 
> For fixing LRR on PTL, is there any other stop gap?
> 
> Currently guardband depends on vmin vtotal and for LRR vtotal gets 
> changed. Is it possible to get a constant value?

If we aren't convinced that changing the guardband is ok then using
the optimized guardband is the only choice that I can see.

> 
> 
> Regards,
> 
> Ankit
> 
> >
> > The prefill stuff btw seems to be completely borked in current
> > upstream code even; it computes things based on a completely stale
> > cdclk frequency (the new frequency will be computed much later).

Also the scaler stuff is borked in the same way. Fixing that is probably
going to require some actual work :/

> >
> > I *think* I can reorder things sufficiently to fix that, but I really
> > must get https://patchwork.freedesktop.org/series/154921/ landed
> > first...
> >

-- 
Ville Syrjälä
Intel