Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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;
>>   }
>

  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