From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status
Date: Wed, 28 May 2014 11:17:08 -0700 [thread overview]
Message-ID: <20140528111708.253e2578@jbarnes-desktop> (raw)
In-Reply-To: <1401300567.3158.11.camel@ideak-mobl>
On Wed, 28 May 2014 21:09:27 +0300
Imre Deak <imre.deak@intel.com> wrote:
> On Wed, 2014-05-28 at 09:50 -0700, Jesse Barnes wrote:
> > This saves many ms per call on my BYT by eliminating Punit communication
> > from the hw readout paths.
> >
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index 452518f..09a3677 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5572,13 +5572,11 @@ bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
> >
> > mutex_lock(&power_domains->lock);
> > for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
> > - if (power_well->always_on)
> > + if (power_well->always_on || power_well->count)
> > continue;
> >
> > - if (!power_well->ops->is_enabled(dev_priv, power_well)) {
> > - is_enabled = false;
> > - break;
> > - }
> > + is_enabled = false;
> > + break;
> > }
> > mutex_unlock(&power_domains->lock);
>
> This was meant to return the HW state vs. the state based on the
> refcount. It would work in the above way now, because we enable all
> power wells for driver init time, but if remove that in the future the
> two states may not match.
>
> Perhaps we could maintain a cached version of the HW state in the
> power_well struct that we set in the sync_hw handler and update whenever
> we turn on/off the wells.
Yeah that works too, and I almost didn't send this out because I knew
the hw state is something we want to read out sometimes.
But on BYT it turns out to be pretty expensive to do the simple "get
power well" calls at the top of the display functions, so it would be
nice to find a way to avoid it.
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-05-28 18:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 16:50 [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status Jesse Barnes
2014-05-28 16:50 ` [PATCH 2/2] drm/i915: rename is_enabled to hw_state Jesse Barnes
2014-05-28 18:09 ` [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status Imre Deak
2014-05-28 18:17 ` Jesse Barnes [this message]
2014-06-05 17:31 ` [PATCH] drm/i915: cache hw power well enabled state Imre Deak
2014-06-05 17:35 ` Jesse Barnes
2014-06-05 17:44 ` Imre Deak
2014-06-06 17:19 ` Daniel Vetter
2014-06-06 17:37 ` Imre Deak
2014-06-06 18:05 ` Daniel Vetter
2014-06-19 11:45 ` Daniel Vetter
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=20140528111708.253e2578@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox