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.org
Subject: Re: [PATCH 6/9] drm/i915/display: Wait for scl start instead of dsb_wait_vblanks
Date: Wed, 24 Sep 2025 15:11:43 +0300	[thread overview]
Message-ID: <aNPf_7jBUpQ6sI_x@intel.com> (raw)
In-Reply-To: <20250924105129.2771196-7-ankit.k.nautiyal@intel.com>

On Wed, Sep 24, 2025 at 04:21:26PM +0530, Ankit Nautiyal wrote:
> Until LNL, intel_dsb_wait_vblanks() used to wait for the undelayed vblank
> start. However, from PTL onwards, it waits for the start of the
> safe-window defined by the number of lines programmed in the register
> TRANS_SET_CONTEXT_LATENCY. This change was introduced to move the SCL
> window out of the vblank region, supporting modes with higher refresh
> rates and smaller vblanks. This change introduces a "safe window" a
> scanline range from (undelayed vblank - SCL) to (delayed vblank - SCL).
> 
> As a result, on PTL+ platforms, the DSB wait for vblank completes exactly
> SCL lines earlier than the undelayed vblank start (safe window start).
> If the flip occurs in the active region and the push happens before the
> vmin decision boundary, the DSB wait fires early, and the push is sent
> inside this safe window. In such cases, the push bit is cleared at the
> delayed vblank, but our wait logic does not account for the early trigger,
> leading to DSB poll errors.
> 
> To fix this, we add an explicit wait for the end of the safe window i.e.,
> the scanline range from (undelayed vblank - SCL) to (delayed vblank - SCL).
> Once past this window, we are exactly SCL lines away from the delayed
> vblank, and our existing wait logic works as intended.
> 
> This additional wait is only effective if the push occurs before the vmin
> decision boundary. If the push happens after the boundary, the hardware
> already guarantees we're SCL lines away from the delayed vblank, and the
> extra wait becomes a no-op.
> 
> v2:
> - Use helpers for safe window start/end. (Ville)
> - Move the extra wait inside the helper to wait for delayed vblank. (Ville)
> - Update the commit message.
> 
> v3:
> - Add more documentation for explanation for the wait. (Ville)
> - Rename intel_vrr_vmin_safe_window_start/end as this is vmin safe
>   window. (Ville)
> - Minor refactoring to align with the code. (Ville)
> - Update the commit message for more clarity.
> 
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dsb.c | 16 ++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_vrr.c | 17 +++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_vrr.h |  2 ++
>  3 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 135d40852e4c..3cb4c9be146f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -824,6 +824,22 @@ void intel_dsb_wait_for_delayed_vblank(struct intel_atomic_state *state,
>  	int usecs = intel_scanlines_to_usecs(&crtc_state->hw.adjusted_mode,
>  					     dsb_vblank_delay(state, crtc));
>  
> +	/*
> +	 * If the push happened before the vmin decision boundary
> +	 * we don't know how far we are from the undelayed vblank.
> +	 * Wait until we're past the vmin safe window, at which
> +	 * point we're SCL lines away from the delayed vblank.
> +	 *
> +	 * If the push happened after the vmin decision boundary
> +	 * the hardware itself guarantees that we're SCL lines
> +	 * away from the delayed vblank, and we won't be inside
> +	 * the vmin safe window so this extra wait does nothing.
> +	 */
> +	if (pre_commit_is_vrr_active(state, crtc))
> +		intel_dsb_wait_scanline_out(state, dsb,
> +					    intel_vrr_vmin_safe_window_start(crtc_state),
> +					    intel_vrr_vmin_safe_window_end(crtc_state));

Hmm, I thought we already had a 'if (vrr)' check here. But I guess that
was in dsb_vblank_delay(). Hmm, yeah I think what you did here is fine
for the moment.

I'm thinking we should follow up with inlining dsb_vblank_delay()
directly into intel_dsb_wait_for_delayed_vblank(), just to keep all
the VRR related wait magic in one place. I don't think there are any
other users of dsb_vblank_delay().

> +
>  	intel_dsb_wait_usec(dsb, usecs);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 1bb9db06f43d..26c5c32a9a58 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -800,3 +800,20 @@ void intel_vrr_get_config(struct intel_crtc_state *crtc_state)
>  	if (crtc_state->vrr.enable)
>  		crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
>  }
> +
> +int intel_vrr_vmin_safe_window_start(const struct intel_crtc_state *crtc_state)

I only wanted you to rename the safe_window_end(). The safe window
start doesn't change for vmin/vmax/etc. So should drop the "vmin"
again from this one.

With that
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> +{
> +	struct intel_display *display = to_intel_display(crtc_state);
> +
> +	if (DISPLAY_VER(display) >= 30)
> +		return crtc_state->hw.adjusted_mode.crtc_vdisplay -
> +		       crtc_state->set_context_latency;
> +	else
> +		return crtc_state->hw.adjusted_mode.crtc_vdisplay;
> +}
> +
> +int intel_vrr_vmin_safe_window_end(const struct intel_crtc_state *crtc_state)
> +{
> +	return intel_vrr_vmin_vblank_start(crtc_state) -
> +	       crtc_state->set_context_latency;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> index 38bf9996b883..239e4f94725c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> @@ -41,5 +41,7 @@ void intel_vrr_transcoder_enable(const struct intel_crtc_state *crtc_state);
>  void intel_vrr_transcoder_disable(const struct intel_crtc_state *crtc_state);
>  void intel_vrr_set_fixed_rr_timings(const struct intel_crtc_state *crtc_state);
>  bool intel_vrr_always_use_vrr_tg(struct intel_display *display);
> +int intel_vrr_vmin_safe_window_start(const struct intel_crtc_state *crtc_state);
> +int intel_vrr_vmin_safe_window_end(const struct intel_crtc_state *crtc_state);
>  
>  #endif /* __INTEL_VRR_H__ */
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-09-24 12:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 10:51 [PATCH 0/9] Introduce set_context_latency and refactor VRR/DSB timing logic Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 1/9] drm/i915/psr: s/intel_psr_min_vblank_delay/intel_psr_min_set_context_latency Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 2/9] drm/i915/display: Add set_context_latency to crtc_state Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 3/9] drm/i915/vrr: Use set_context_latency instead of intel_vrr_real_vblank_delay() Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 4/9] drm/i915/vrr: Use SCL for computing guardband Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 5/9] drm/i915/dsb: s/intel_dsb_wait_vblank_delay/intel_dsb_wait_for_delayed_vblank Ankit Nautiyal
2025-09-24 10:51 ` [PATCH 6/9] drm/i915/display: Wait for scl start instead of dsb_wait_vblanks Ankit Nautiyal
2025-09-24 12:11   ` Ville Syrjälä [this message]
2025-09-24 14:04     ` Nautiyal, Ankit K
2025-09-24 10:51 ` [PATCH 7/9] drm/i915/reg_defs: Add REG_FIELD_MAX wrapper for FIELD_MAX() Ankit Nautiyal
2025-09-24 12:24   ` Andi Shyti
2025-09-24 14:17     ` Nautiyal, Ankit K
2025-09-24 10:51 ` [PATCH 8/9] drm/i915/vrr: Clamp guardband as per hardware and timing constraints Ankit Nautiyal
2025-09-24 12:04   ` Ville Syrjälä
2025-09-24 14:19     ` Nautiyal, Ankit K
2025-09-24 10:51 ` [PATCH 9/9] drm/i915/display: Drop intel_vrr_vblank_delay and use set_context_latency Ankit Nautiyal
2025-09-24 12:13   ` Ville Syrjälä
2025-09-24 11:35 ` ✓ CI.KUnit: success for Introduce set_context_latency and refactor VRR/DSB timing logic (rev3) Patchwork
2025-09-24 11:50 ` ✗ CI.checksparse: warning " Patchwork
2025-09-24 12:05 ` ✓ i915.CI.BAT: success " Patchwork
2025-09-24 12:09 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-24 15:02 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-24 20:35 ` ✗ 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=aNPf_7jBUpQ6sI_x@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.org \
    /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.