[Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()
tvrtko.ursulin at linux.intel.com
Wed Apr 10 14:53:12 UTC 2019
On 10/04/2019 14:04, Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-10 13:49:32)
>> 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.)
I honestly cannot figure out now what I thought the problem is. Perhaps
I confused it with intel_context_pin.
There is so much churn in intel_context.c, both recent and in this
series, that I struggle to keep with it...
> Went with intel_context_lock_pinned() and intel_context_unlock_pinned().
...so this is also okay. Perhaps add an assert that pin count is above
zero as well.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
More information about the Intel-gfx