[Intel-gfx] [PATCH 10/36] drm/i915: Replace pcu_lock with sb_lock

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-03-15 12:06:57)
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> >   struct intel_rps {
> > +     struct mutex lock;
> > +
> I think this lock can now become part of struct intel_gt_pm.

Maybe, haven't decided yet. Anything but rps is so infrequent as not to
really matter... And rps by the same metric deserves its own locking.

> >       /*
> >        * work, interrupts_enabled and pm_iir are protected by
> >        * dev_priv->irq_lock
> > @@ -1783,14 +1785,6 @@ struct drm_i915_private {
> >       /* Cannot be determined by PCIID. You must always read a register. */
> >       u32 edram_cap;
> >   
> > -     /*
> > -      * Protects RPS/RC6 register access and PCU communication.
> > -      * Must be taken after struct_mutex if nested. Note that
> > -      * this lock may be held for long periods of time when
> > -      * talking to hw - so only take it when talking to hw!
> > -      */
> > -     struct mutex pcu_lock;
> > -
> >       /* gen6+ GT PM state */
> >       struct intel_gen6_power_mgmt gt_pm;
> >   
> ...
> > -int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv,
> > -                                 u32 mbox, u32 val,
> > -                                 int fast_timeout_us, int slow_timeout_ms)
> > +static int __sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv,
> > +                                          u32 mbox, u32 val,
> > +                                          int fast_timeout_us,
> > +                                          int slow_timeout_ms)
> >   {
> >       int status;
> >   
> > -     WARN_ON(!mutex_is_locked(&dev_priv->pcu_lock));
> > -
> lockdep_assert is missed here.

Because it is now static with its only pair of users immediately after,
so easy to verify both callers take the sb_lock (pair when we reduce
this to the common rw routine).
-Chris