From: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com>
To: Ankit Nautiyal <ankit.k.nautiyal@intel.com>,
<intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>
Cc: <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH] drm/i915/display: Ensure a non-zero safe window from PTL onwards
Date: Tue, 21 Jul 2026 20:12:28 +0530 [thread overview]
Message-ID: <535d50b9-82f7-437d-8eb3-76f7554aa528@intel.com> (raw)
In-Reply-To: <20260720081803.1123264-1-ankit.k.nautiyal@intel.com>
On 7/20/2026 1:48 PM, Ankit Nautiyal wrote:
> From PTL onwards the DSB waits on the VRR safe window instead of vblank
> (chicken bit 14 selects the safe window signal from the DPT unit to
bit [15:14]
It is not entirely true that Safe window signal was used only from PTL
onwards. Pre-PTL it was still used but just for VRR.
> start the DMA engine). The safe window starts at (undelayed vblank
> start - set context latency) and ends at the delayed vblank start.
>
> With modes that have a smaller vblank region, the computed guardband is
> clamped to the vblank length, which makes the undelayed and delayed
> vblank coincide. If the set context latency (SCL) is also 0, the safe
> window collapses to 0. The DSB, configured to wait for the safe window,
> then stalls forever since the hardware never signals it, leading to:
>
> *ERROR* [CRTC:159:pipe A] flip_done timed out
> *ERROR* [CRTC:159:pipe A] DSB 0 timed out waiting for idle
>
> Clamp the set context latency to a minimum of 1 from PTL onwards so the
> safe window always keeps a non-zero width.
>
I could not thoroughly check if there are any side effects of this on
the optimized guardband (and therefore on PSR, LOBF etc.) but the change
looks safe enough to me.
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
> Fixes: 4a68c7516c57 ("drm/i915/dsb: Use safe window path when VRR TG is used")
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Assisted-by: GitHub-Copilot:Claude-Opus-4.8
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 38763a6802c5..0822a2194c7f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2459,6 +2459,19 @@ static int intel_crtc_set_context_latency(struct intel_crtc_state *crtc_state)
> set_context_latency = max(set_context_latency,
> intel_psr_min_set_context_latency(crtc_state));
>
> + /*
> + * From PTL onwards, the set context latency can be in the vactive
> + * region, letting the safe window start some lines before the vblank
> + * start. With modes that have a smaller vblank region, the computed
> + * guardband is clamped to the vblank length, making the undelayed and
> + * delayed vblank coincide. If the SCL is also 0, the 'safe window'
> + * becomes effectively 0, and the DSB configured to wait for it gets
> + * stalled, since the hardware never signals the safe window. Keep the
> + * set context latency at a minimum of 1 to avoid this.
> + */
> + if (DISPLAY_VER(display) >= 30)
> + set_context_latency = max(1, set_context_latency);
> +
> return set_context_latency;
> }
>
next prev parent reply other threads:[~2026-07-21 14:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 8:18 [PATCH] drm/i915/display: Ensure a non-zero safe window from PTL onwards Ankit Nautiyal
2026-07-20 12:37 ` ✓ CI.KUnit: success for " Patchwork
2026-07-20 13:26 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-20 16:14 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-07-21 14:42 ` Borah, Chaitanya Kumar [this message]
2026-07-22 5:00 ` [PATCH] " Nautiyal, Ankit K
2026-07-22 6:24 ` [PATCH v2] " Ankit Nautiyal
2026-07-22 6:46 ` Borah, Chaitanya Kumar
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=535d50b9-82f7-437d-8eb3-76f7554aa528@intel.com \
--to=chaitanya.kumar.borah@intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=ville.syrjala@linux.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