From: Arnd Bergmann <arnd@kernel.org>
Date: Tue, 16 Feb 2021 10:41:11 +0100
On Mon, Feb 15, 2021 at 1:17 PM Hector Martin [off-list ref] wrote:
quoted
+
+ The 2nd cell contains the interrupt number.
+ - HW IRQs: interrupt number
+ - FIQs:
+ - 0: physical HV timer
+ - 1: virtual HV timer
+ - 2: physical guest timer
+ - 3: virtual guest timer
I wonder if you could just model the FIQ as a single shared level interrupt
(which is essentially what it is), and have every driver that uses it do a
request_irq() on the same IRQ number.
This would avoid having to come up with a fake binding for it, and simplify
the implementation that then no longer has to peek into each interrupt
source.
That would tie the binding more closely to the implementation as it
would remove the option of peeking at the interrupt source. And
wouldn't it mean that the arch_timer driver would need to know whether
the interrupt is shared or not?
On Tue, Feb 16, 2021 at 12:00 PM Mark Kettenis [off-list ref] wrote:
quoted
From: Arnd Bergmann <arnd@kernel.org>
Date: Tue, 16 Feb 2021 10:41:11 +0100
On Mon, Feb 15, 2021 at 1:17 PM Hector Martin [off-list ref] wrote:
quoted
+
+ The 2nd cell contains the interrupt number.
+ - HW IRQs: interrupt number
+ - FIQs:
+ - 0: physical HV timer
+ - 1: virtual HV timer
+ - 2: physical guest timer
+ - 3: virtual guest timer
I wonder if you could just model the FIQ as a single shared level interrupt
(which is essentially what it is), and have every driver that uses it do a
request_irq() on the same IRQ number.
This would avoid having to come up with a fake binding for it, and simplify
the implementation that then no longer has to peek into each interrupt
source.
That would tie the binding more closely to the implementation as it
would remove the option of peeking at the interrupt source.
I don't think having the binding match the implementation is a bad thing ;-)
If a future SoC variant handles it differently, it will need a binding update
anyway.
And wouldn't it mean that the arch_timer driver would need to know whether
the interrupt is shared or not?
Indeed, it does require each driver to pass IRQF_SHARED, and be
prepared to be called when no irq is pending (returning IRQ_NONE
otherwise), so a downside would be that this requires changing the
bindings for the timer and anything else that ends up using FIQ
later. It may be possible to just always pass IRQF_SHARED when
registering the arch timer handler, not sure if there are any downsides
in case for the normal (non-shared) case.
This is a drawback, but I still find it a little cleaner than having to
encode information about the individual irq sources into the irqchip
driver.
Arnd