[QUERY]: Acknowledgment of edge triggered interrupts

[Lad, Prabhakar]

Hi Marc,

Sorry for the late reply.

On Mon, May 2, 2022 at 10:44 AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Sat, 30 Apr 2022 19:41:24 +0100,
> "Lad, Prabhakar" <prabhakar.csengg at gmail.com> wrote:
> >
> > Hi Marc,
> >
> > I am currently working on the irq-sifive-plic.c driver. The
> > irq-sifive-plic.c driver is currently implemented as a chained domain.
> > On our SoC which uses this block for EDGE interrupts we need to first
> > acknowledge the interrupt before handling it.
>
> Isn't that what the CLAIM register does on the PLIC? AFAICT, this
> interrupt controller is able to implement the whole flow, irrespective
> of the trigger mechanism.
>
Yes, the CLAIM register is used to ACK interrupts.

> The spec strongly hints at that, see [1] ("Interrupt gateways"), and
> the uniform handling that results of it. In a way, this is strikingly
> similar to what the original ARM GIC does.
>
The ARM GIC allows the next interrupts to be pending, that is it can
stock interrupts (pending interrupt counter).

> [1] https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc
>
> >
> > I came across a similar situation on a different driver (patch [0])
> > but it isn't a chained handler.
> >
> > What approach should be taken for chained IRQ domains to handle such cases?
>
> I don't think there is anything to change. At least, as long as the
> Interrupt Gateway is doing its job correctly. How this gateway is
> configured is unfortunately out of the scope of the architecture, it
> seems, and I'd expect your HW to have some sort of knobs for the
> trigger type to be configured. This would be dealt with in a separate
> stacked driver.
>
Renesas RZ/Five Soc has a AX45MP AndesCore which has NCEPLIC100.
Quoting from https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#interrupt-gateways

"If the global interrupt source was edge-triggered, the gateway will
convert the first matching signal edge into an interrupt request.
Depending on the design of the device and the interrupt handler, in
between sending an interrupt request and receiving notice of its
handler’s completion, the gateway might either ignore additional
matching edges or increment a counter of pending interrupts. In either
case, the next interrupt request will not be forwarded to the PLIC
core until the previous completion message has been received"

Andes NCEPLIC100 ignores the next interrupt edge until the previous
completion message has been received and to top it the gateway doesn't
have a pending interrupt counter. So the only workaround for handling
edge interrupts is to first acknowledge it and then run the handler as
shown in the attached image.

Cheers,
Prabhakar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interrupt.png
Type: image/png
Size: 20727 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220506/361de2ed/attachment-0001.png>