[Intel-gfx] [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status

Jesse Barnes jbarnes at virtuousgeek.org
Wed May 28 20:17:08 CEST 2014


On Wed, 28 May 2014 21:09:27 +0300
Imre Deak <imre.deak at 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 at 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



More information about the Intel-gfx mailing list