[Intel-gfx] [PATCH 4/4] drm/i915: Introduce PSR Block Power Domains.

[Chris Wilson]

On Thu, Aug 04, 2016 at 03:52:06AM +0100, Chris Wilson wrote:
> > +static bool gen9_psr_blk_power_well_enabled(struct drm_i915_private *dev_priv,
> > +					    struct i915_power_well *power_well)
> > +{
> > +	return (dev_priv->psr.rpm_block);
> 
> Looks like rpm_block only exists to duplicate rpm state.
> 
> > +}
> > +
> > +static void gen9_psr_blk_power_well_enable(struct drm_i915_private *dev_priv,
> > +					   struct i915_power_well *power_well)
> > +{
> > +	intel_psr_rpm_block(dev_priv);
> 
> intel_psr_rpm_block -> intel_psr_block()
> 
> > +
> > +	WARN_ON(dev_priv->psr.active);
> > +}
> > +
> > +static void gen9_psr_blk_power_well_disable(struct drm_i915_private *dev_priv,
> > +					    struct i915_power_well *power_well)
> > +{
> > +	intel_psr_rpm_unblock(dev_priv);
> 
> intel_psr_rpm_unblock -> intel_psr_unblock()

That rpm_block is not used outside of the runtime pm paths is a little
fishy.

intel_psr_enter()
{
	if (READ_ONCE(psr.block))
		return;
	
	if (!dev_priv->psr.active)
		schedule_delayed_work(&dev_priv->psr.work, msecs_to_jiffies(100));
	
	/* scheduling an already active work does not requeue it, that
	 * requires mod_delayed_work
	 */
}

Then intel_psr_flush() uses
	if (!psr.busy_frontbuffer_bits) intel_psr_entry();

and intel_psr_unblock() as in the earlier email.

Would be nice to markup which psr functions require the caller to hold
psr.lock
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre