From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.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 12:41:11 +0000 [thread overview]
Message-ID: <78d2f599c2ebffb3936071048b3e8d3a343de5c1.camel@intel.com> (raw)
In-Reply-To: <Z5OJjKVW5QJEKrPP@intel.com>
On Fri, 2025-01-24 at 14:37 +0200, Ville Syrjälä wrote:
> 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...
Maybe we just add that evasion without checking panel replay. It
shouldn't be too expensive anyways. What do you think?
BR,
Jouni Högander
>
next prev parent reply other threads:[~2025-01-24 12:41 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ä
2025-01-24 12:41 ` Hogander, Jouni [this message]
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=78d2f599c2ebffb3936071048b3e8d3a343de5c1.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=animesh.manna@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=ville.syrjala@intel.com \
--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