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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
