On 6/5/2026 9:05 PM, Ville Syrjälä wrote:
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.
Makes sense. I'll keep that helper unchanged and instead introduce a
separate
pre_commit_use_vrr_safe_window() for the DSB paths that need this
behaviour.
Regards,
Ankit
+
/* VRR will be enabled afterwards, if necessary */
if (intel_crtc_needs_modeset(new_crtc_state))
return false;
--
2.45.2
