From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Hogander, Jouni" <jouni.hogander@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Manna, Animesh" <animesh.manna@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Syrjala, Ville" <ville.syrjala@intel.com>
Subject: Re: [PATCH v4 11/13] drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabled
Date: Fri, 24 Jan 2025 14:37:32 +0200 [thread overview]
Message-ID: <Z5OJjKVW5QJEKrPP@intel.com> (raw)
In-Reply-To: <dbf6d20903c2ca8dbab3437b0af7ad414b14f99c.camel@intel.com>
On Fri, Jan 24, 2025 at 11:57:10AM +0000, Hogander, Jouni wrote:
> On Fri, 2025-01-24 at 13:39 +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2025 at 12:56:22PM +0200, Jouni Högander wrote:
> > > PIPEDSL is reading as 0 when in SRDENT(PSR1) or DEEP_SLEEP(PSR2).
> > > On
> > > wake-up scanline counting starts from vblank_start - 1. We don't
> > > know if
> > > wake-up is already ongoing when evasion starts. In worst case
> > > PIPEDSL could
> > > start reading valid value right after checking the scanline. In
> > > this
> > > scenario we wouldn't have enough time to write all registers. To
> > > tackle
> > > this evade scanline 0 as well. As a drawback we have 1 frame delay
> > > in flip
> > > when waking up.
> > >
> > > Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dsb.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > > index bb77ded8bf726..914f0be4491c4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > > @@ -528,6 +528,18 @@ void intel_dsb_vblank_evade(struct
> > > intel_atomic_state *state,
> > > int latency = intel_usecs_to_scanlines(&crtc_state-
> > > >hw.adjusted_mode, 20);
> > > int start, end;
> > >
> > > + /*
> > > + * PIPEDSL is reading as 0 when in SRDENT(PSR1) or
> > > DEEP_SLEEP(PSR2). On
> > > + * wake-up scanline counting starts from vblank_start - 1.
> > > We don't know
> > > + * if wake-up is already ongoing when evasion starts. In
> > > worst case
> > > + * PIPEDSL could start reading valid value right after
> > > checking the
> > > + * scanline. In this scenario we wouldn't have enough time
> > > to write all
> > > + * registers. To tackle this evade scanline 0 as well. As
> > > a drawback we
> > > + * have 1 frame delay in flip when waking up.
> > > + */
> > > + if (crtc_state->has_psr && !crtc_state->has_panel_replay)
> >
> > What's the deal with panel replay here?
>
> I couldn't see PIPEDSL returning 0 when using Panel Replay. Even on
> same setup with PSR I saw it, but with PR I couldn't see.
Hmm. Are you sure it's reaching DC5/6?
Though I suppose it's possible that panel replay (unlike PSR)
does pretty much everything from the DMC's DC state handler,
so as soon as you read the register it restores things fully
enough that you get the vblank_start-1 response...
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-01-24 12:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-24 10:56 [PATCH v4 00/13] PSR DSB support Jouni Högander
2025-01-24 10:56 ` [PATCH v4 01/13] drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update Jouni Högander
2025-01-24 10:56 ` [PATCH v4 02/13] drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_update Jouni Högander
2025-01-24 10:56 ` [PATCH v4 03/13] drm/i915/psr: Split setting sff and cff bits away from intel_psr_force_update Jouni Högander
2025-01-24 10:56 ` [PATCH v4 04/13] drm/i915/psr: Add register definitions for SFF_CTL and CFF_CTL registers Jouni Högander
2025-01-24 10:56 ` [PATCH v4 05/13] drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwards Jouni Högander
2025-01-24 10:56 ` [PATCH v4 06/13] drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSB Jouni Högander
2025-01-24 10:56 ` [PATCH v4 07/13] drm/i915/psr: Changes for PSR2_MAN_TRK_CTL handling when DSB is in use Jouni Högander
2025-01-24 10:56 ` [PATCH v4 08/13] drm/i915/psr: Add intel_psr_is_psr_mode_changing Jouni Högander
2025-01-24 10:56 ` [PATCH v4 09/13] drm/i915/display: Don't use DSB if psr mode changing Jouni Högander
2025-01-24 11:53 ` Ville Syrjälä
2025-01-24 12:09 ` Hogander, Jouni
2025-01-24 12:16 ` Hogander, Jouni
2025-01-24 12:32 ` Ville Syrjälä
2025-01-24 12:35 ` Hogander, Jouni
2025-01-24 10:56 ` [PATCH v4 10/13] drm/i915/psr: Remove DSB_SKIP_WAITS_EN chicken bit Jouni Högander
2025-01-24 11:46 ` Ville Syrjälä
2025-01-24 11:51 ` Hogander, Jouni
2025-01-24 10:56 ` [PATCH v4 11/13] drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabled Jouni Högander
2025-01-24 11:39 ` Ville Syrjälä
2025-01-24 11:57 ` Hogander, Jouni
2025-01-24 12:37 ` Ville Syrjälä [this message]
2025-01-24 12:41 ` Hogander, Jouni
2025-01-24 12:49 ` Ville Syrjälä
2025-01-27 14:53 ` Hogander, Jouni
2025-01-24 10:56 ` [PATCH v4 12/13] drm/i915/display: Ensure we have "Frame Change" event in DSB commit Jouni Högander
2025-01-24 11:43 ` Ville Syrjälä
2025-01-24 11:57 ` Ville Syrjälä
2025-01-24 12:10 ` Hogander, Jouni
2025-01-24 10:56 ` [PATCH v4 13/13] drm/i915/psr: Allow DSB usage when PSR is enabled Jouni Högander
2025-01-24 11:05 ` ✗ CI.Patch_applied: failure for PSR DSB support (rev4) 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=Z5OJjKVW5QJEKrPP@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=animesh.manna@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jouni.hogander@intel.com \
--cc=ville.syrjala@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