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
next prev parent reply other threads:[~2025-10-15 16:36 UTC|newest]
Thread overview: 15+ 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 11:57 ` ✗ i915.CI.BAT: failure for Optimize vrr.guardband Patchwork
2025-10-15 17:00 ` ✗ CI.checkpatch: warning " 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 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.