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
