On Tue, Feb 16, 2021 at 12:00 PM Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxxxx>
> > Date: Tue, 16 Feb 2021 10:41:11 +0100
> >
> > On Mon, Feb 15, 2021 at 1:17 PM Hector Martin <marcan@xxxxxxxxx> wrote:
> > > +
> > > + 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
