On 08/02/2021 03.49, Arnd Bergmann wrote:
Ok, I had not realized the timer was level triggered. In case of the
timer, I suppose it could be either masked or acknowledged from the
fiq top-half handler when deferring to irq, but I agree that it means a
layering violation in either case.
What
On 07/02/2021 21.25, Arnd Bergmann wrote:
On Sun, Feb 7, 2021 at 9:36 AM Hector Martin 'marcan' wrote:
On 07/02/2021 01.22, Arnd Bergmann wrote:
* In the fiq handler code, check if normal interrupts were enabled
when the fiq hit. Normally they are enabled, so just proceed to
handle
On 07/02/2021 00.37, Marc Zyngier wrote:
See my digression in patch 8. I really wonder what the benefit is to
treat FIQ independently of IRQ, and we might as well generalise
this. We could always panic on getting a FIQ on platforms that don't
expect one.
It'd be good to rope in the other
On 07/02/2021 01.22, Arnd Bergmann wrote:
* In the fiq handler code, check if normal interrupts were enabled
when the fiq hit. Normally they are enabled, so just proceed to
handle the timer and ipi directly
* if irq was disabled, defer the handling by doing a self-ipi
through the aic's
Apple SoCs (A11 and newer) have some interrupt sources hardwired to the
FIQ line. Implement support for this by simply treating IRQs and FIQs
the same way in the interrupt vectors. This is conditional on the
ARM64_NEEDS_FIQ CPU feature flag, and thus will not affect other
systems.
Root irqchip
5 matches
Mail list logo