All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop
Subject: Re: [PATCH 2/2] drm/i915/dsb: handle always_use_vrr_tg in pre_commit_is_vrr_active()
Date: Fri, 5 Jun 2026 18:35:02 +0300	[thread overview]
Message-ID: <aiLsptasB2CKlwwJ@intel.com> (raw)
In-Reply-To: <20260525091159.564066-3-ankit.k.nautiyal@intel.com>

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

  reply	other threads:[~2026-06-05 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25  9:11 [PATCH 0/2] Extend VRR safe window wait for VRR TG Ankit Nautiyal
2026-05-25  9:11 ` [PATCH 1/2] drm/i915/dsb: wait one scanline before delayed-vblank DSL wait Ankit Nautiyal
2026-06-05 14:42   ` Ville Syrjälä
2026-05-25  9:11 ` [PATCH 2/2] drm/i915/dsb: handle always_use_vrr_tg in pre_commit_is_vrr_active() Ankit Nautiyal
2026-06-05 15:35   ` Ville Syrjälä [this message]
2026-05-25 15:23 ` ✓ i915.CI.BAT: success for Extend VRR safe window wait for VRR TG Patchwork
2026-05-25 19:47 ` ✓ i915.CI.Full: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aiLsptasB2CKlwwJ@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ankit.k.nautiyal@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.