Re: [PATCH 1/3] drm/i915: Rework some interrupt handling functions to take intel_gt

[Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>]

On 7/2/19 4:45 AM, Tvrtko Ursulin wrote:
> 
> On 02/07/2019 11:34, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2019-07-02 11:23:11)
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> Some interrupt handling functions already have gt in their names
>>> suggesting them as obvious candidates to make them take struct intel_gt
>>> instead of i915.
>>>
>>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> Co-authored-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>
>>>   static void
>>> -gen11_other_irq_handler(struct drm_i915_private * const i915,
>>> -                       const u8 instance, const u16 iir)
>>> +gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
>>> +                       const u16 iir)
>>>   {
>>> +       struct drm_i915_private *i915 = gt->i915;
>>> +
>>>          if (instance == OTHER_GUC_INSTANCE)
>>>                  return gen11_guc_irq_handler(i915, iir);
>>
>> That looks like a candidate for gt as well. Even for the guc, the
>> interrupt vector is GT centric. I was hoping we could place guc/ parallel
>> to gt/, but it looks like it will indeed be a child of intel_gt.
> 
> Yeah. Daniele will deal with the GuC code paths.
> 
>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Thanks. I'll also let Daniele comment on whether this refactoring fits 
> with his work before merging it.

Yup, works for me. On the whole series:

Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

Daniele

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