On Sat, 25 Jun 2022 10:54:44 +0100,
"Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx> wrote:
>
> Hi Marc,
>
> Thank you for the review.
>
> On Sat, Jun 25, 2022 at 10:03 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >
> > On Fri, 24 Jun 2022 19:03:11 +0100,
> > Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> wrote:
> > >
> > > The Renesas RZ/Five SoC has a RISC-V AX45MP AndesCore with NCEPLIC100. The
> > > NCEPLIC100 supports both edge-triggered and level-triggered interrupts. In
> > > case of edge-triggered interrupts NCEPLIC100 ignores the next interrupt
> > > edge until the previous completion message has been received and
> > > NCEPLIC100 doesn't support pending interrupt counter, hence losing the
> > > interrupts if not acknowledged in time.
> > >
> > > So the workaround for edge-triggered interrupts to be handled correctly
> > > and without losing is that it needs to be acknowledged first and then
> > > handler must be run so that we don't miss on the next edge-triggered
> > > interrupt.
> > >
> > > This patch adds a new compatible string for Renesas RZ/Five SoC and
> > > changes the chained interrupt haindler for RZ/Five SoC.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > ---
> > > RFC-->v1:
> > > * Fixed review comments pointed by Geert
> > > * Dropped handle_fasteoi_ack_irq support as for the PLIC we need to
> > > claim the interrupt by reading the register and then acknowledge it.
> >
> > Why? This is exactly what the fasteoi_ack flow gives you, and your
> > initial patch was much better that this one in that regard.
> >
> > > * Add a new chained handler for RZ/Five SoC.
> > > ---
> > > drivers/irqchip/irq-sifive-plic.c | 95 +++++++++++++++++++++++++++++--
> > > 1 file changed, 91 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> > > index 173446cc9204..f53dff49e122 100644
> > > --- a/drivers/irqchip/irq-sifive-plic.c
> > > +++ b/drivers/irqchip/irq-sifive-plic.c
> > > @@ -60,10 +60,13 @@
> > > #define PLIC_DISABLE_THRESHOLD 0x7
> > > #define PLIC_ENABLE_THRESHOLD 0
> > >
> > > +#define PLIC_INTERRUPT_CELL_SIZE2 2
> > > +
> > > struct plic_priv {
> > > struct cpumask lmask;
> > > struct irq_domain *irqdomain;
> > > void __iomem *regs;
> > > + u32 intsize;
> > > };
> > >
> > > struct plic_handler {
> > > @@ -163,7 +166,7 @@ static int plic_set_affinity(struct irq_data *d,
> > > }
> > > #endif
> > >
> > > -static void plic_irq_eoi(struct irq_data *d)
> > > +static void plic_irq_ack(struct irq_data *d)
> > > {
> > > struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> > >
> > > @@ -176,6 +179,23 @@ static void plic_irq_eoi(struct irq_data *d)
> > > }
> > > }
> > >
> > > +static void plic_irq_eoi(struct irq_data *d)
> > > +{
> > > + struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> > > + unsigned int irq = irq_find_mapping(handler->priv->irqdomain, d->hwirq);
> > > +
> > > + /*
> > > + * For Renesas RZ/Five (R9A07G043) SoC if the interrupt type is
> > > + * IRQ_TYPE_EDGE_RISING we have already acknowledged it in the
> > > + * handler.
> > > + */
> > > + if (handler->priv->intsize == PLIC_INTERRUPT_CELL_SIZE2 &&
> >
> > This costs you an extra two reads on the fast path, which is an
> > unnecessary overhead for existing systems that do not suffer from this
> > problem. Consider turning it into a static key.
> >
> Sorry, by static key what did you mean?
See Documentation/staging/static-keys.rst
>
> > Also, blindly renaming plic_irq_eoi() to ack() is extremely
> > confusing. I really think you should have your own callbacks instead
> > of making a mess of the existing one.
> >
> Ok will do.
>
> > > + (irq_get_trigger_type(irq) & IRQ_TYPE_EDGE_RISING))
> > > + return;
> > > +
> > > + plic_irq_ack(d);
> > > +}
> > > +
> > > static const struct irq_chip plic_chip = {
> > > .name = "SiFive PLIC",
> > > .irq_mask = plic_irq_mask,
> > > @@ -198,6 +218,19 @@ static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
> > > return 0;
> > > }
> > >
> > > +static int plic_irq_domain_translate(struct irq_domain *d,
> > > + struct irq_fwspec *fwspec,
> > > + unsigned long *hwirq,
> > > + unsigned int *type)
> > > +{
> > > + struct plic_priv *priv = d->host_data;
> > > +
> > > + if (priv->intsize == PLIC_INTERRUPT_CELL_SIZE2)
> > > + return irq_domain_translate_twocell(d, fwspec, hwirq, type);
> > > +
> > > + return irq_domain_translate_onecell(d, fwspec, hwirq, type);
> > > +}
> > > +
> > > static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> > > unsigned int nr_irqs, void *arg)
> > > {
> > > @@ -206,7 +239,7 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> > > unsigned int type;
> > > struct irq_fwspec *fwspec = arg;
> > >
> > > - ret = irq_domain_translate_onecell(domain, fwspec, &hwirq, &type);
> > > + ret = plic_irq_domain_translate(domain, fwspec, &hwirq, &type);
> > > if (ret)
> > > return ret;
> > >
> > > @@ -220,11 +253,55 @@ static int plic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> > > }
> > >
> > > static const struct irq_domain_ops plic_irqdomain_ops = {
> > > - .translate = irq_domain_translate_onecell,
> > > + .translate = plic_irq_domain_translate,
> > > .alloc = plic_irq_domain_alloc,
> > > .free = irq_domain_free_irqs_top,
> > > };
> > >
> > > +/*
> > > + * On Renesas RZ/Five (R9A07G043) SoC IRQ_TYPE_LEVEL_HIGH and
> > > + * IRQ_TYPE_EDGE_RISING interrupts are the supported interrupt types.
> > > + * If the global interrupt source was edge-triggered NCEPLIC100 (PLIC
> > > + * core on Renesas RZ/Five SoC) ignores next edge interrupts until the
> > > + * previous completion message is received. NCEPLIC100 on Renesas RZ/Five
> > > + * SoC doesn't stack the pending interrupts so in case there is a delay
> > > + * in handling the IRQ_TYPE_EDGE_RISING interrupt we lose the subsequent
> > > + * interrupts. The workaround for IRQ_TYPE_EDGE_RISING interrupt is to
> > > + * first we have to claim the interrupt by reading the claim register,
> > > + * then quickly issue an complete interrupt by writing the source ID
> > > + * register back to the claim register and then later run the handler.
> > > + */
> > > +static void renesas_rzfive_plic_handle_irq(struct irq_desc *desc)
> > > +{
> > > + struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
> > > + struct irq_chip *chip = irq_desc_get_chip(desc);
> > > + void __iomem *claim = handler->hart_base + CONTEXT_CLAIM;
> > > + irq_hw_number_t hwirq;
> > > + unsigned int irq;
> > > + int err;
> > > +
> > > + WARN_ON_ONCE(!handler->present);
> > > +
> > > + chained_irq_enter(chip, desc);
> > > +
> > > + while ((hwirq = readl(claim))) {
> > > + irq = irq_find_mapping(handler->priv->irqdomain, hwirq);
> > > + if (!irq) {
> > > + pr_warn_ratelimited("can't find mapping for hwirq %lu\n", hwirq);
> > > + break;
> > > + }
> > > +
> > > + if (irq_get_trigger_type(irq) & IRQ_TYPE_EDGE_RISING)
> > > + plic_irq_ack(irq_get_irq_data(irq));
> > > +
> > > + err = generic_handle_irq(irq);
> >
> > No. We're not going back to this sort of constructs. Using the
> > fasteoi_ack flow should work if properly configured. Also, looking up
> > the interrupt *four* times in various tables/trees is not exactly the
> > sort of things I want to see for a driver written in this century.
> >
> > Please explain why fasteoi_ack doesn't work. It really should work out
> > of the box (I asked you to look into debugfs last time, but didn't ear
> > anything from you on the subject). And if something is broken, let's
> > fix it. But none of the above, please.
> >
> Handling an interrupt is a two-step process [0] first you claim the
> interrupt by reading the claim register, then you complete the
> interrupt by writing that source ID back to the same claim register.
I'm familiar with the architecture.
>
> Now if we go with fasteoi_ack flow this wont fit as we are first
> writing into the claim register (Interrupt completion) and then in the
> chained handler we are reading the claim register (claim the
> interrupt) and then run the handler (which my RFC patch did).
>
> With this patch I make sure we follow [0] for LEVEL interrupt and and
> for EDGE we first claim then issue interrupt completion if EDGE
> interrupt and then later run the handler (due to the core issue).
>
> Let me know if my understanding is wrong here.
You are just reinventing the wheel we are already have, except that
yours is a bit square ;-). What really should happen is that the
set_type method should set the correct flow depending on the trigger
of the interrupt, and *never* have to check the configuration on the
handling path.
M.
--
Without deviation from the norm, progress is not possible.
