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 15/15] drm/i915/display: Use optimized guardband to set vblank start
Date: Mon, 29 Sep 2025 12:00:28 +0300	[thread overview]
Message-ID: <aNpKrMapLVw4bvGb@intel.com> (raw)
In-Reply-To: <20250928070541.3892890-16-ankit.k.nautiyal@intel.com>

On Sun, Sep 28, 2025 at 12:35:40PM +0530, Ankit Nautiyal wrote:
> As we move towards using a shorter, optimized guardband, we need to adjust
> how the delayed vblank start is computed.
> 
> Use the helper intel_vrr_compute_guardband() to calculate the optimized
> guardband. Since this is measured from the vblank end, we shift the
> vblank-start accordingly.
> 
> Calculate the minimum delay required based on the guardband and apply it in
> intel_crtc_vblank_delay() to update crtc_vblank_start.
> 
> Additionally, introduce a new allow_vblank_delay_fastset() helper that
> combines the existing LRR-based logic with an additional check for the
> optimized guardband usage.
> 
> v2:
> - Check if optimized guardband is more than vblank length and add debug
>   print.
> - Extend vblank delay fastset logic to cover optimized guardband.
> 
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 79 +++++++++++++++++++-
>  1 file changed, 76 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 4135f9be53fd..97a3121a204f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2361,6 +2361,67 @@ static int intel_crtc_compute_pipe_mode(struct intel_crtc_state *crtc_state)
>  	return 0;
>  }
>  
> +static
> +int intel_crtc_min_guardband_delay(struct intel_atomic_state *state,
> +				   struct intel_crtc *crtc)
> +{
> +	struct intel_display *display = to_intel_display(state);
> +	struct intel_crtc_state *crtc_state =
> +		intel_atomic_get_new_crtc_state(state, crtc);
> +	const struct drm_display_mode *adjusted_mode =
> +		&crtc_state->hw.adjusted_mode;
> +	struct drm_connector_state *conn_state;
> +	struct drm_connector *drm_connector;
> +	int vblank_length;
> +	int i;
> +
> +	if (!intel_vrr_use_optimized_guardband(crtc_state))
> +		return 0;
> +
> +	vblank_length = crtc_state->vrr.vmin -
> +			adjusted_mode->crtc_vdisplay;
> +
> +	for_each_new_connector_in_state(&state->base,
> +					drm_connector,
> +					conn_state, i) {
> +		int guardband;
> +		struct intel_connector *connector;
> +
> +		if (conn_state->crtc != &crtc->base)
> +			continue;
> +
> +		connector = to_intel_connector(drm_connector);
> +		guardband = intel_vrr_compute_guardband(crtc_state,
> +							connector);
> +		if (guardband > vblank_length) {
> +			drm_dbg_kms(display->drm,
> +				    "[CRTC:%d:%s] Cannot optimize guardband (%d) exceeds max (%d)\n",
> +				    crtc->base.base.id, crtc->base.name,
> +				    guardband,
> +				    vblank_length);
> +			return 0;
> +		}
> +
> +		return vblank_length - guardband;
> +	}
> +
> +	return 0;
> +}
> +
> +static void intel_crtc_vblank_delay(struct intel_atomic_state *state,
> +				    struct intel_crtc *crtc)
> +{
> +	struct intel_crtc_state *crtc_state =
> +		intel_atomic_get_new_crtc_state(state, crtc);
> +	struct drm_display_mode *adjusted_mode =
> +		&crtc_state->hw.adjusted_mode;
> +	int vblank_delay = 0;
> +
> +	vblank_delay = intel_crtc_min_guardband_delay(state, crtc);
> +
> +	adjusted_mode->crtc_vblank_start += vblank_delay;
> +}
> +
>  static int intel_crtc_set_context_latency(struct intel_crtc_state *crtc_state)
>  {
>  	struct intel_display *display = to_intel_display(crtc_state);
> @@ -2413,6 +2474,7 @@ static int intel_crtc_compute_config(struct intel_atomic_state *state,
>  	ret = intel_crtc_compute_set_context_latency(state, crtc);
>  	if (ret)
>  		return ret;
> +	intel_crtc_vblank_delay(state, crtc);

IMO we should get rid of all this vblank_delay terminology here.
This one I think should just be our current
intel_vrr_compute_config_late() (renamed to eg.
intel_vrr_compute_guardband()).

After which we just have to solve all the chicken vs. egg problems
to really compute the approriate optimized guardband value.
  
>  	ret = intel_dpll_crtc_compute_clock(state, crtc);
>  	if (ret)
> @@ -5101,13 +5163,24 @@ static bool allow_vblank_delay_fastset_lrr(const struct intel_crtc_state *old_cr
>  {
>  	struct intel_display *display = to_intel_display(old_crtc_state);
>  
> +	return HAS_LRR(display) && old_crtc_state->inherited &&
> +		!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DSI);
> +}
> +
> +static bool allow_vblank_delay_fastset(const struct intel_crtc_state *old_crtc_state,
> +				       const struct intel_crtc_state *new_crtc_state)
> +{
>  	/*
>  	 * Allow fastboot to fix up vblank delay (handled via LRR
>  	 * codepaths), a bit dodgy as the registers aren't
>  	 * double buffered but seems to be working more or less...
> +	 *
> +	 * Additionally, with the optimized guardband the vblank start
> +	 * is moved further away from the undelayed vblank. Allow this
> +	 * vblank delay when optimized guardband is used.
>  	 */
> -	return HAS_LRR(display) && old_crtc_state->inherited &&
> -		!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DSI);
> +	return allow_vblank_delay_fastset_lrr(old_crtc_state) ||
> +	       intel_vrr_use_optimized_guardband(new_crtc_state);
>  }
>  
>  bool
> @@ -5242,7 +5315,7 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,
>  	PIPE_CONF_CHECK_I(name.crtc_hsync_start); \
>  	PIPE_CONF_CHECK_I(name.crtc_hsync_end); \
>  	PIPE_CONF_CHECK_I(name.crtc_vdisplay); \
> -	if (!fastset || !allow_vblank_delay_fastset_lrr(current_config)) \
> +	if (!fastset || !allow_vblank_delay_fastset(current_config, pipe_config)) \
>  		PIPE_CONF_CHECK_I(name.crtc_vblank_start); \
>  	PIPE_CONF_CHECK_I(name.crtc_vsync_start); \
>  	PIPE_CONF_CHECK_I(name.crtc_vsync_end); \
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2025-09-29  9:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-28  7:05 [PATCH 00/15] Optimize vrr.guardband and fix LRR Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 01/15] drm/i915/vrr: Use crtc_vsync_start/end for computing vrr.vsync_start/end Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 02/15] drm/i915/skl_watermark: Fix the scaling factor for chroma subsampling Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 03/15] drm/i915/skl_watermark: Pass linetime as argument to latency helpers Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 04/15] drm/i915/skl_scaler: Introduce helper for chroma downscale factor Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 05/15] drm/i915/display: Extract helpers to set dsc/scaler prefill latencies Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 06/15] drm/i915/dp: Add SDP latency computation helper Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 07/15] drm/i915/alpm: Add function to compute max link-wake latency Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 08/15] drm/i915/display: Add guardband check for feature latencies Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 09/15] drm/i915/skl_watermark: Remove redundant latency checks from vblank validation Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 10/15] drm/i915/vrr: Introduce helper to compute min static guardband Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 11/15] drm/i915/vrr: Use optimized guardband when VRR TG is active Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 12/15] drm/i915/vrr: Prepare for movement of vblank start for optimized guardband Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 13/15] drm/i915/display: Recompute crtc_vblank_start " Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 14/15] drm/i915/display: s/allow_vblank_delay_fastset/allow_vblank_delay_fastset_lrr Ankit Nautiyal
2025-09-28  7:05 ` [PATCH 15/15] drm/i915/display: Use optimized guardband to set vblank start Ankit Nautiyal
2025-09-29  8:45   ` Ville Syrjälä
2025-09-29  9:09     ` Ville Syrjälä
2025-09-29  9:21     ` Ville Syrjälä
2025-10-01 10:34     ` Nautiyal, Ankit K
2025-10-01 12:10       ` Ville Syrjälä
2025-10-01 13:16         ` Nautiyal, Ankit K
2025-09-29  9:00   ` Ville Syrjälä [this message]
2025-10-01 10:41     ` Nautiyal, Ankit K
2025-10-01 12:12       ` Ville Syrjälä
2025-10-01 13:17         ` Nautiyal, Ankit K
2025-09-28  7:31 ` ✓ CI.KUnit: success for Optimize vrr.guardband and fix LRR (rev13) Patchwork
2025-09-28  7:46 ` ✗ CI.checksparse: warning " Patchwork
2025-09-28  8:07 ` ✗ i915.CI.BAT: failure for Optimize vrr.guardband and fix LRR (rev12) Patchwork
2025-09-28  8:08 ` ✓ Xe.CI.BAT: success for Optimize vrr.guardband and fix LRR (rev13) Patchwork
2025-09-28  9:31 ` ✗ Xe.CI.Full: failure " 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=aNpKrMapLVw4bvGb@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.