public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: "Jouni Högander" <jouni.hogander@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v9 6/8] drm/i915/psr: Wait for idle only after possible send push
Date: Fri, 23 Jan 2026 10:42:45 +0530	[thread overview]
Message-ID: <904618e8-d4e5-4775-bc42-69cf7a7d2c34@intel.com> (raw)
In-Reply-To: <20251223105120.21505-7-jouni.hogander@intel.com>


On 12/23/2025 4:21 PM, Jouni Högander wrote:
> We are planning to move using trans push mechanism to trigger the Frame
> Change event. in that case we can't wait PSR to idle before send push
> happens. Due to this move wait for idle to be done after possible send push
> is done.
>
> This should be ok for Frame Change event triggered by register write as
> well. Wait for idle is needed only for corner case where PSR is
> transitioning into DEEP_SLEEP when Frame Change event is triggered. It just
> has to be before wait for vblank. Otherwise we may have vblank before PSR
> enters DEEP_SLEEP and still using old frame buffers for first frame after
> wake up.
>
> Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> ---
>   drivers/gpu/drm/i915/display/intel_display.c | 13 ++++++++++---
>   1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index c7ca4f53b8b8..1aca4802b7d5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7333,9 +7333,6 @@ static void intel_atomic_dsb_finish(struct intel_atomic_state *state,
>   		intel_psr_trigger_frame_change_event(new_crtc_state->dsb_commit,
>   						     state, crtc);
>   
> -		intel_psr_wait_for_idle_dsb(new_crtc_state->dsb_commit,
> -					    new_crtc_state);
> -
>   		if (new_crtc_state->use_dsb)
>   			intel_dsb_vblank_evade(state, new_crtc_state->dsb_commit);
>   
> @@ -7375,6 +7372,16 @@ static void intel_atomic_dsb_finish(struct intel_atomic_state *state,
>   
>   		intel_vrr_send_push(new_crtc_state->dsb_commit, new_crtc_state);
>   
> +		/*
> +		 * Wait for idle is needed for corner case where PSR HW
> +		 * is transitioning into DEEP_SLEEP/SRDENT_OFF when
> +		 * new Frame Change event comes in. It is ok to do it
> +		 * here for both Frame Change mecanisms (trans push
> +		 * and register write).
> +		 */
> +		intel_psr_wait_for_idle_dsb(new_crtc_state->dsb_commit,
> +					    new_crtc_state);
> +

If I understand correctly:

For Fixed RR case:
Suppose we are in PSR:
Skip_wait_en is set.
The portion around the Send Push will be like:


-dsb_wait_vblank will no longer wait for the undelayed vblank (we are in 
PSR and skip_wait_en is set)
-we send push -> to trigger frame change event for PSR HW.

-After this PSR HW is supposed to receive the event and may be in 
transition period so we wait for idle dsb.(which internally makes sure 
that we are out of PSR)

-We are not sure whether we are in active or in vblank region at this 
point of time so we want to use dsb_wait_vblank. The skip_wait_en will 
now not come in picture since we have made sure that we are not in PSR 
in previous step.

Then other steps will be similar to what we have been doing.

Is my understanding correct?

What happens when Panel Replay is in picture, given we can have PR 
enable with Variable Refresh Rate timings.


Regards,

Ankit

>   		/*
>   		 * In case PSR uses trans push as a "frame change" event and
>   		 * VRR is not in use we need to wait vblank. Othervise we may

  reply	other threads:[~2026-01-23  5:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-23 10:51 [PATCH v9 0/8] Use trans push mechanism to generate frame change event Jouni Högander
2025-12-23 10:51 ` [PATCH v9 1/8] drm/i915/psr: Add TRANS_PUSH register bit definition for PSR Jouni Högander
2025-12-23 10:51 ` [PATCH v9 2/8] drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is used Jouni Högander
2025-12-23 10:51 ` [PATCH v9 3/8] drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame change Jouni Högander
2026-01-22 11:04   ` Nautiyal, Ankit K
2026-01-22 11:39     ` Hogander, Jouni
2025-12-23 10:51 ` [PATCH v9 4/8] drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwards Jouni Högander
2026-01-23  4:41   ` Nautiyal, Ankit K
2026-01-23  6:19     ` Hogander, Jouni
2025-12-23 10:51 ` [PATCH v9 5/8] drm/i915/display: Wait for vblank in case of PSR is using trans push Jouni Högander
2025-12-23 10:51 ` [PATCH v9 6/8] drm/i915/psr: Wait for idle only after possible send push Jouni Högander
2026-01-23  5:12   ` Nautiyal, Ankit K [this message]
2026-01-23  6:37     ` Hogander, Jouni
2026-01-23 11:33       ` Nautiyal, Ankit K
2025-12-23 10:51 ` [PATCH v9 7/8] drm/i915/psr: Do PSR exit on frontbuffer flush on LunarLake and onwards Jouni Högander
2026-01-23  6:18   ` Nautiyal, Ankit K
2025-12-23 10:51 ` [PATCH v9 8/8] drm/i915/psr: Use TRANS_PUSH to trigger frame change event Jouni Högander
2026-01-22 11:04   ` Nautiyal, Ankit K
2026-01-22 11:43     ` Hogander, Jouni
2025-12-23 12:23 ` ✓ i915.CI.BAT: success for Use trans push mechanism to generate " Patchwork
2025-12-24 17:26 ` ✓ i915.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=904618e8-d4e5-4775-bc42-69cf7a7d2c34@intel.com \
    --to=ankit.k.nautiyal@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jouni.hogander@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