Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 v2] drm/i915/display: Ensure a non-zero safe window from PTL onwards
Date: Wed, 22 Jul 2026 12:16:35 +0530	[thread overview]
Message-ID: <08b741c1-b187-410a-b7cd-7199f73a5184@intel.com> (raw)
In-Reply-To: <20260722062449.1166411-1-ankit.k.nautiyal@intel.com>



On 7/22/2026 11:54 AM, Ankit Nautiyal wrote:
>  From PTL onwards, the set context latency can be in the vactive region,
> letting the safe window start some lines before the vblank start. The DSB
> waits on this safe window instead of vblank (bits [15:14] select the safe
> window signal from the DPT unit to start the DMA engine).
> 
> 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, leading to:
> 
>    *ERROR* [CRTC:159:pipe A] flip_done timed out
>    *ERROR* [CRTC:159:pipe A] DSB 0 timed out waiting for idle
> 
> Keep the set context latency at a minimum of 1 to avoid this.
> 
> v2: Fix the bit numbers and correct the commit message. (Chaitanya)
> 

It still looks *safe* to me ;) the commit message is good now.

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  6:46 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
2026-07-22  6:24 ` [PATCH v2] " Ankit Nautiyal
2026-07-22  6:46   ` Borah, Chaitanya Kumar [this message]

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=08b741c1-b187-410a-b7cd-7199f73a5184@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