Intel-XE Archive on 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,
	uma.shankar@intel.com
Subject: Re: [PATCH 5/6] drm/i915/display: Add guardband check for feature latencies
Date: Wed, 15 Oct 2025 19:36:07 +0300	[thread overview]
Message-ID: <aO_Nd3xTtgPDN5RM@intel.com> (raw)
In-Reply-To: <20251015102241.1797828-6-ankit.k.nautiyal@intel.com>

On Wed, Oct 15, 2025 at 03:52:40PM +0530, Ankit Nautiyal wrote:
> Add a check during atomic crtc check phase to ensure the programmed
> guardband is sufficient to cover latencies introduced by enabled features
> such as DSC, PSR/PR, scalers, and DP SDPs.
> 
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 56 ++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 4367ecfab2b3..4e3f08a8cd9c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -126,6 +126,7 @@
>  #include "intel_vga.h"
>  #include "intel_vrr.h"
>  #include "intel_wm.h"
> +#include "skl_prefill.h"
>  #include "skl_scaler.h"
>  #include "skl_universal_plane.h"
>  #include "skl_watermark.h"
> @@ -4191,6 +4192,57 @@ static int hsw_compute_linetime_wm(struct intel_atomic_state *state,
>  	return 0;
>  }
>  
> +static int intel_crtc_guardband_atomic_check(struct intel_atomic_state *state,
> +					     struct intel_crtc *crtc)

Not sure why you're adding this. We already have the
compute_guardband().

> +{
> +	struct intel_display *display = to_intel_display(crtc);
> +	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 skl_prefill_ctx prefill_ctx;
> +	int prefill_framestart_delay = 1;
> +	int prefill_min_guardband;
> +	int prefill_latency_us;
> +	int prefill_wm0_lines;
> +	int prefill_sagv_us;
> +	int psr_latency = 0;
> +	int sdp_latency = 0;
> +	int min_guardband;
> +	int guardband;
> +
> +	skl_prefill_init(&prefill_ctx, crtc_state);
> +	prefill_wm0_lines = skl_wm0_prefill_lines(crtc_state);
> +	prefill_sagv_us = display->sagv.block_time_us;
> +	prefill_latency_us = prefill_sagv_us +
> +			     intel_scanlines_to_usecs(adjusted_mode,
> +						      prefill_framestart_delay +
> +						      prefill_wm0_lines);

All of that should pretty much just be skl_prefill_init_worst()

> +	prefill_min_guardband =
> +		skl_prefill_min_guardband(&prefill_ctx,
> +					  crtc_state,
> +					  prefill_latency_us);

The only question really is what use as the latency here.
I think we want it to be:
 max(sagv_block_time, skl_watermark_max_latency(1))
which should guarantee that we get the max power savings.

> +
> +	if (intel_crtc_has_dp_encoder(crtc_state)) {
> +		psr_latency = intel_psr_max_link_wake_latency(crtc_state);
> +		sdp_latency = intel_dp_compute_sdp_latency(crtc_state);
> +	}
> +
> +	min_guardband = max(sdp_latency, psr_latency);
> +
> +	min_guardband = max(min_guardband, prefill_min_guardband);
> +
> +	guardband = intel_crtc_vblank_length(crtc_state);
> +
> +	if (guardband < min_guardband) {
> +		drm_dbg_kms(display->drm, "actual guardband: %d shorter than min guardband: %d\n",
> +			    guardband, min_guardband);
> +		return -EINVAL;
> +	}

I don't think we want to do any checks here. This whole thing
should just be something like:

guardband = prefill_min_guardband()
guardband = max(guardband, psr_min_guardband())
guardband = max(guardband, sdp_min_guardband())

crtc_state->vrr.guardband = min(guardband, intel_vrr_max_guardband())

And then we need to check the final value against 
sdp_min_guardband() in .compute_config_late() to make sure
we got enough for the SDPs. So quite similar to PSR, except
we just want .compute_config_late() to fail if we don't have
enough for the SDPs.

I think that should be good enough for now. It may force a modeset
if the SDPs change though, so later we might want to think about
using a better worst case estimate here, eg. assume HDR metadata may
get enabled later, which we'd like to do without changing the guardband.

> +
> +	return 0;
> +}
> +
>  static int intel_crtc_atomic_check(struct intel_atomic_state *state,
>  				   struct intel_crtc *crtc)
>  {
> @@ -4253,6 +4305,10 @@ static int intel_crtc_atomic_check(struct intel_atomic_state *state,
>  	if (ret)
>  		return ret;
>  
> +	ret = intel_crtc_guardband_atomic_check(state, crtc);
> +	if (ret)
> +		return ret;
> +
>  	return 0;
>  }
>  
> -- 
> 2.45.2

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-10-15 16:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 10:22 [PATCH 0/6] Optimize vrr.guardband Ankit Nautiyal
2025-10-15 10:22 ` [PATCH 1/6] [NOT FOR REVIEW] drm/i915/vrr: prep patches for guardband optimization squashed Ankit Nautiyal
2025-10-15 10:22 ` [PATCH 2/6] [NOT FOR REVIEW] drm/i915/prefill: Prefill latency calculations series squashed Ankit Nautiyal
2025-10-15 10:22 ` [PATCH 3/6] drm/i915/dp: Add SDP latency computation helper Ankit Nautiyal
2025-10-15 10:22 ` [PATCH 4/6] drm/i915/psr: Add function to compute max link-wake latency Ankit Nautiyal
2025-10-15 10:22 ` [PATCH 5/6] drm/i915/display: Add guardband check for feature latencies Ankit Nautiyal
2025-10-15 16:36   ` Ville Syrjälä [this message]
2025-10-16  4:06     ` Nautiyal, Ankit K
2025-10-15 10:22 ` [PATCH 6/6] drm/i915/vrr: Use the min static optimized guardband Ankit Nautiyal
2025-10-15 17:00 ` ✗ CI.checkpatch: warning for Optimize vrr.guardband Patchwork
2025-10-15 17:02 ` ✓ CI.KUnit: success " Patchwork
2025-10-15 17:17 ` ✗ CI.checksparse: warning " Patchwork
2025-10-15 18:11 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-10-16  4:15 ` ✗ Xe.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=aO_Nd3xTtgPDN5RM@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 \
    --cc=uma.shankar@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox