All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "Deak, Imre" <imre.deak@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Prevent needless toggling of DC states during modesets
Date: Thu, 22 Jun 2023 12:25:15 +0000	[thread overview]
Message-ID: <5e0ac504839d6668dd4eceacb5a5097b0c5c1267.camel@intel.com> (raw)
In-Reply-To: <ZJQ5HJk2B5G9bzt2@ideak-desk>

On Thu, 2023-06-22 at 15:05 +0300, Imre Deak wrote:
> On Thu, Jun 22, 2023 at 12:38:17PM +0300, Hogander, Jouni wrote:
> > On Fri, 2023-06-16 at 21:51 +0300, Imre Deak wrote:
> > > DC states are disabled / re-enabled around each modeset, which
> > > may
> > > lead to a needless off->on->off toggling of the DC_off power
> > > well.
> > > This has some overhead as toggling DC states involves running a
> > > DMC
> > > firmware handler and also running a periodic firmware handler
> > > while
> > > DC states are enabled. The limit of when DC states have a benefit
> > > is
> > > at 30 FPS (using DC3co) and below 30 FPS (using DC5/6), where the
> > > firmware can actually disable clocks / power off power wells.
> > > Accordingly delay powering off the DC_off powerwell (which
> > > re-enables DC states) by 17 ms at the end of a modeset to avoid
> > > the
> > > above overhead at or above 60 FPS.
> > 
> > I'm wondering in which case this toggling would happen and how the
> > patch helps it.
> 
> It happens around each modeset in cases DC states are allowed by the
> enabled outputs. For instance a single eDP output enabled and user
> space
> doing back-to-back page flipping (issuing a new flip once the
> previous
> one completes). The reason to avoid the
> disable DC state -> flip -> re-enable DC state
> toggling of DC states around each flip in this case is to avoid the
> overhead of the DMC FW handlers running I described above (as the
> firmware won't actually get to enter DC states anyway).
> 
> > We have PSR idle frames configured > 6. I.e. Only after 6 frames
> > without changes our HW is supposed to enter DC5/6. This is purely
> > with
> > PSR glasses on. Do we have some other (than PSR) use-case this is
> > targeting where DC5/DC6 would be possible while display is on?
> 
> DC3co would allow the DMC FW to enter DC states (actually disabling
> clocks/power wells) after each frame at 30 FPS.

Thank you for the clarification. For the whole set:

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

> 
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index dd52c689267f4..de77d130d6f9f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -7148,7 +7148,11 @@ static void
> > > intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > >                  */
> > >                
> > > intel_uncore_arm_unclaimed_mmio_detection(&dev_priv-
> > > > uncore);
> > >         }
> > > -       intel_display_power_put(dev_priv, POWER_DOMAIN_DC_OFF,
> > > wakeref);
> > > +       /*
> > > +        * Delay re-enabling DC states by 17 ms to avoid the off-
> > > >on-
> > > > off
> > > +        * toggling overhead at and above 60 FPS.
> > > +        */
> > > +       intel_display_power_put_async_delay(dev_priv,
> > > POWER_DOMAIN_DC_OFF, wakeref, 17);
> > >         intel_runtime_pm_put(&dev_priv->runtime_pm, state-
> > > >wakeref);
> > > 
> > >         /*
> > 


  reply	other threads:[~2023-06-22 12:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-16 18:51 [Intel-gfx] [PATCH 1/4] drm/i915: Add missing forward declarations/includes to display power headers Imre Deak
2023-06-16 18:51 ` [Intel-gfx] [PATCH 2/4] drm/i915: Remove redundant forward declarations from " Imre Deak
2023-06-16 18:51 ` [Intel-gfx] [PATCH 3/4] drm/i915: Add way to specify the power-off delay of a display power domain Imre Deak
2023-06-16 18:51 ` [Intel-gfx] [PATCH 4/4] drm/i915: Prevent needless toggling of DC states during modesets Imre Deak
2023-06-22  9:38   ` Hogander, Jouni
2023-06-22 12:05     ` Imre Deak
2023-06-22 12:25       ` Hogander, Jouni [this message]
2023-06-16 19:35 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Add missing forward declarations/includes to display power headers Patchwork
2023-06-16 19:36 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-06-17  0:44 ` [Intel-gfx] [PATCH 1/4] " Randy Dunlap
2023-06-17  5:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] " Patchwork
2023-06-17 13:10 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-06-19 10:48   ` Imre Deak
2023-06-22 17:21 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Add missing forward declarations/includes to display power headers (rev2) Patchwork
2023-06-22 17:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-06-22 17:35 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-06-22 17:57   ` Imre Deak
2023-06-26 11:30     ` Imre Deak

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=5e0ac504839d6668dd4eceacb5a5097b0c5c1267.camel@intel.com \
    --to=jouni.hogander@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.