On Mon, May 25, 2026 at 02:41:59PM +0530, Ankit Nautiyal wrote: > When the VRR timing generator is always used, the hardware behaves > as VRR-active regardless of crtc_state->vrr.enable. Return true > early so DSB picks the VRR path for chicken bits and the delayed > vblank wait. > > Signed-off-by: Ankit Nautiyal <[email protected]> > --- > drivers/gpu/drm/i915/display/intel_dsb.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c > b/drivers/gpu/drm/i915/display/intel_dsb.c > index dae8ea33d069..6cbbd23f7327 100644 > --- a/drivers/gpu/drm/i915/display/intel_dsb.c > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c > @@ -154,11 +154,15 @@ static void dsb_buffer_flush_map(struct intel_dsb *dsb) > static bool pre_commit_is_vrr_active(struct intel_atomic_state *state, > struct intel_crtc *crtc) > { > + struct intel_display *display = to_intel_display(state); > const struct intel_crtc_state *old_crtc_state = > intel_atomic_get_old_crtc_state(state, crtc); > const struct intel_crtc_state *new_crtc_state = > intel_atomic_get_new_crtc_state(state, crtc); > > + if (intel_vrr_always_use_vrr_tg(display)) > + return true;
I don't think we want this check inside pre_commit_is_vrr_active(). It affects too many things. I guess we have three places where we do want it, so maybe wrap this into a pre_commit_use_safe_window() for them. > + > /* VRR will be enabled afterwards, if necessary */ > if (intel_crtc_needs_modeset(new_crtc_state)) > return false; > -- > 2.45.2 -- Ville Syrjälä Intel
