[Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
> 
> On 08/04/2019 10:17, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
> > index da342e9a8c2e..4f8ef45e6344 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -39,9 +39,17 @@ intel_context_lookup(struct i915_gem_context *ctx,
> >    * can neither be bound to the GPU or unbound whilst the lock is held, i.e.
> >    * intel_context_is_pinned() remains stable.
> >    */
> > -struct intel_context *
> > -intel_context_pin_lock(struct i915_gem_context *ctx,
> > -                    struct intel_engine_cs *engine);
> > +static inline int intel_context_pin_lock(struct intel_context *ce)
> > +     __acquires(ce->pin_mutex)
> > +{
> > +     return mutex_lock_interruptible(&ce->pin_mutex);
> > +}
> 
> So if this is not getting the kref any more why are the other callers 
> okay? In previous patch(es) some certainly looked like they assume pin 
> implies a reference.

This is not 'pin' but locking the pinned state.
Maybe lock_pin and unlock_pin? (I was going to say lock_pin_count, but
it strictly does not prevent updates to pin_count, merely the transition
to/from .pin_count == 0.)

The usecase example is ctx_sseu that wants to inspect the current status
of the context and operate on pinned/not-pinned safe in the knowledge
that can't change as it does so.
-Chris