Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Use correct lock for CT event handler

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 20/11/2020 14:32, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-11-20 09:56:36)
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> CT event handler is called under the gt->irq_lock from the interrupt
>> handling paths so make it the same from the init path. I don't think this
>> mismatch caused any functional issue but we need to wean the code of the
>> global i915->irq_lock.
> 
> ct_read definitely wants to be serialised. Is guc->irq_lock the right
> choice?

Not under my understanding and also confirmed by Daniele off line.

>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> ---
>>   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 ++++---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> index 220626c3ad81..6a0452815c41 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> @@ -203,7 +203,8 @@ static void guc_disable_interrupts(struct intel_guc *guc)
>>   
>>   static int guc_enable_communication(struct intel_guc *guc)
>>   {
>> -       struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>> +       struct intel_gt *gt = guc_to_gt(guc);
>> +       struct drm_i915_private *i915 = gt->i915;
>>          int ret;
>>   
>>          GEM_BUG_ON(guc_communication_enabled(guc));
>> @@ -223,9 +224,9 @@ static int guc_enable_communication(struct intel_guc *guc)
>>          guc_enable_interrupts(guc);
>>   
>>          /* check for CT messages received before we enabled interrupts */
>> -       spin_lock_irq(&i915->irq_lock);
>> +       spin_lock_irq(&gt->irq_lock);
>>          intel_guc_ct_event_handler(&guc->ct);
>> -       spin_unlock_irq(&i915->irq_lock);
>> +       spin_unlock_irq(&gt->irq_lock);
> 
> You used guc->irq_lock in the previous patch. I suggest
> intel_guc_ct_event_handler() should specify what lock it requires.

There are indeed too many locks and too little asserts to help the reader.

But the other end of the state ct_read needs is updated from the GuC 
firmware itself, which then send the interrupt, which we process in:

  guc_irq_handler
    -> intel_guc_to_host_event_handler
         -> intel_guc_ct_event_handler

And this side runs under the gt->irq_lock.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx