[Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Mon Jan 15 10:38:22 UTC 2018
On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote:
>
>
> On 10/01/18 02:12, Chris Wilson wrote:
>> Quoting Paulo Zanoni (2018-01-09 23:23:17)
>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>
>>> Since it is not possible to mask individual engine instances
>>> and they are all permanently unmasked we do not need to do
>>> anything for engine interrupt management.
>>
>> This scares me as we will more than double our interrupt generation rate
>> as we have a breadcrumb interrupt after every request, just in case we
>> need to synchronize with the request. We've been relying on the ability
>> to mask those interrupts off, as historically we have been able to
>> saturate cpus with the amount of interrupts we could generate.
>> -Chris
>
> We do have masks per instance, but they're in gunit and not in the CS.
> they're defined in patch 4 of this series:
>
> +#define GEN11_RCS0_RSVD_INTR_MASK _MMIO(0x190090)
> +#define GEN11_BCS_RSVD_INTR_MASK _MMIO(0x1900a0)
> +#define GEN11_VCS0_VCS1_INTR_MASK _MMIO(0x1900a8)
> +#define GEN11_VCS2_VCS3_INTR_MASK _MMIO(0x1900ac)
> +#define GEN11_VECS0_VECS1_INTR_MASK _MMIO(0x1900d0)
>
> Each instance gets half of a register for a 16 bits vector. I think
> there was some gotcha with the masks being in gunit but can't remember
> exactly what. Tvrtko, do you remember anything on this?
I remember the message was to not use them since they were pencilled in
for removal from the HW. There was some issue with them in general which
made that decision attractive, coupled with the fact other OS did not
have a need for them.
If that removal did not materialize we could perhaps revisit the plans.
It would require a locked RMW cycle as minimum since there are two
instances in each reg but that probably isn't such a big deal.
So yeah, I think summary would be someone needs to pull on sleeves of a
HW designer, or someone close, to check what happened with the removal
plans, and what exactly was the problematic bit with frequent (un)masking.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list