Re: [PATCH v9 6/8] drm/i915/psr: Wait for idle only after possible send push

["Hogander, Jouni" <jouni.hogander@intel.com>]

On Fri, 2026-01-23 at 10:42 +0530, Nautiyal, Ankit K wrote:
> 
> 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_stat
> > e->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.

I don't know how having VRR enabled would impact this sequence? send
push triggers "Frame Change" event -> possible PR active is exited ->
wait for vblank -> wait_for_delayed_vblank -> check push is sent.

Do you have something specific in your mind?

BR,
Jouni Högander

> 
> 
> 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