[Intel-gfx] [PATCH 1/3] drm/i915: Rework some interrupt handling functions to take intel_gt
Daniele Ceraolo Spurio
daniele.ceraolospurio at intel.com
Tue Jul 2 17:14:08 UTC 2019
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 at 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 at intel.com>
>>> Co-authored-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at 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 at 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 at intel.com>
Daniele
>
> Regards,
>
> Tvrtko
More information about the Intel-gfx
mailing list