Re: Question about SPIs' interrupt trigger type restrictions

[Daniel Thompson <daniel.thompson@linaro.org>]

On Tue, Jun 07, 2022 at 09:29:06AM +0800, richard clark wrote:
> On Mon, Jun 6, 2022 at 6:08 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> > There is a secondary interrupt
> > controller between the SoC pin and the GIC which inverts the logic (and
> > also obviates any need to deploy the GIC's edge detection features at
> > all... IMHO the GIC trigger mode should be active high).
>
> I don't think there's a interrupt controller between SOC WKPU and GIC,
> all the WKPU interrupt related does is to *detect* the external
> signal(falling/rising) and route to the GIC

See below.


> > Instead, I think the reason your code is weird is because the irqchip
> > driver for the WKPU is missing or broken. A secondary interrupt
> > controller requires an irqchip driver or you will end up with pieces of
> > the interrupt controller management code (e.g. weird pokes to the WKPU
> > to acknowledge things) appearing in all manner of inappropriate places.
>
> Again, no so-called second irq-chip except the GIC within the SOC.

Yes there is.

The WKPU is an interrupt controller and it sits between the SoC pin and
the GIC. To avoid weird code then you need a WKPU driver. Drivers for
interrupt controllers normally belong in drivers/irqchip.

I believe, in your case, this driver is either missing or broken. This
belief is based on evidence that you provided. You code appears to
attach an ISR directly to a GIC SPI irqno: if an irqchip driver for
the WKPU was present and working then I think you would be unable to
do this (because it would be busy).


> For me, the most important thing is WHY the GIC only support the
> rising edge just as its document said.

I can't help you with that. Sure, it might be interesting to know more
but I'm a pragmatist: I simply not that invested in revisiting a fifteen
year old design decision that can no longer be changed.


Daniel.