From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@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: Wed, 22 Jul 2026 10:30:44 +0530 [thread overview]
Message-ID: <68708714-7d9a-40be-8917-da8983204cd9@intel.com> (raw)
In-Reply-To: <535d50b9-82f7-437d-8eb3-76f7554aa528@intel.com>
On 7/21/2026 8:12 PM, Borah, Chaitanya Kumar wrote:
>
>
> 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]
Thats right.
>
> 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.
Yes right I missed to add that we are waiting for safe signal for Fixed
RR case. I will reframe this.
Thanks for pointing these out, will fix these in v2.
Regards,
Ankit
>
>> 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-22 5:00 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 ` [PATCH] " Borah, Chaitanya Kumar
2026-07-22 5:00 ` Nautiyal, Ankit K [this message]
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=68708714-7d9a-40be-8917-da8983204cd9@intel.com \
--to=ankit.k.nautiyal@intel.com \
--cc=chaitanya.kumar.borah@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