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