devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Hoan Tran <hoan@os.amperecomputing.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Saravana Kannan <saravanak@google.com>,
	Serge Semin <fancer.lancer@gmail.com>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Pascal Eberhard <pascal.eberhard@se.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v5 7/8] soc: renesas: Add support for Renesas RZ/N1 GPIO Interrupt Multiplexer
Date: Wed, 22 Oct 2025 15:03:39 +0200	[thread overview]
Message-ID: <20251022150339.4c48649e@bootlin.com> (raw)
In-Reply-To: <CAMuHMdV03D_3b_JA2vzW4tE_QbkkT1bN1dm+zLLLX24oDHMj0Q@mail.gmail.com>

Hi Geert,

On Tue, 21 Oct 2025 15:05:35 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Hervé,
> 
> On Mon, 20 Oct 2025 at 10:08, Herve Codina (Schneider Electric)
> <herve.codina@bootlin.com> wrote:
> > On the Renesas RZ/N1 SoC, GPIOs can generate interruptions. Those
> > interruption lines are multiplexed by the GPIO Interrupt Multiplexer in
> > order to map 32 * 3 GPIO interrupt lines to 8 GIC interrupt lines.
> >
> > The GPIO interrupt multiplexer IP does nothing but select 8 GPIO
> > IRQ lines out of the 96 available to wire them to the GIC input lines.
> >
> > Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>  
> 
> Thanks for your patch!
> 
> > --- a/drivers/soc/renesas/Makefile
> > +++ b/drivers/soc/renesas/Makefile
> > @@ -14,4 +14,5 @@ obj-$(CONFIG_SYS_R9A09G057)   += r9a09g057-sys.o
> >  # Family
> >  obj-$(CONFIG_PWC_RZV2M)                += pwc-rzv2m.o
> >  obj-$(CONFIG_RST_RCAR)         += rcar-rst.o
> > +obj-$(CONFIG_RZN1_IRQMUX)              += rzn1_irqmux.o  
> 
> One TAB too much.

Yes indeed, will be removed.

> 
> > --- /dev/null
> > +++ b/drivers/soc/renesas/rzn1_irqmux.c
> > @@ -0,0 +1,150 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * RZ/N1 GPIO Interrupt Multiplexer
> > + *
> > + * Copyright 2025 Schneider Electric
> > + * Author: Herve Codina <herve.codina@bootlin.com>
> > + */
> > +
> > +#include <linux/bitops.h>
> > +#include <linux/build_bug.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/platform_device.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/*
> > + * The array index is the output line index, the value at the index is the
> > + * GIC SPI interrupt number the output line is connected to.
> > + */
> > +static const u32 rzn1_irqmux_output_lines[] = {
> > +       103, 104, 105, 106, 107, 108, 109, 110
> > +};  
> 
> I did read the discussion with Wolfram, but the flexibility (and
> overhead) provided by this array sounds a bit overkill to me.
> 
> What about just defining:
> 
>     #define RZN1_IRQMUX_SPI_BASE    103
>     #define RZN1_IRQMUX_NUM_IRQS    8
> 
> ?
> 
> If/when a new SoC with a similar setup ever arrives, you can probably
> just replace the constants above by variables inside SoC-specific
> match data.  And if the new mapping would be non-contiguous, you can
> still revive this array ;-)

I have in mind a use case that can lead to a non-contiguous mapping.

The RZ/N1 SoC embeds a Cortex-M3 CPU. This CPU can use GPIOs and
some of them for interrupt purpose. In that case, those GPIOs have
to be routed to the interrupt line expected by the Cortex-M3.

And so, we have some interrupts reserved for CPUs running Linux and
some others for the Cortex-M3.

Among those reserved interrupts may some are not used.

for instance:
  Interrupt 103, 102: Reserved and used by Linux
  Interrupt 103: Reserved for Linux but not used -> Hole in the mapping
  Interrupt 104: Reserved and used my Cortex-M3 (need to be routed by Linux)

I don't know if this use case is relevant but I think we should be too restrictive
on the mapping and so accept holes.

With that in mind, I let you confirm that you still prefer to have a mapping
without any holes. A future patch to support that is always possible.

> 
> More about this below...
> 
> > +
> > +static int rzn1_irqmux_parent_args_to_line_index(struct device *dev,
> > +                                                const struct of_phandle_args *parent_args,
> > +                                                const u32 output_lines[],
> > +                                                unsigned int output_lines_count)
> > +{
> > +       unsigned int i;
> > +
> > +       /*
> > +        * The parent interrupt should be one of the GIC controller.
> > +        * Three arguments must be provided.
> > +        *  - args[0]: GIC_SPI
> > +        *  - args[1]: The GIC interrupt number
> > +        *  - args[2]: The interrupt flags
> > +        *
> > +        * We retrieve the line index based on the GIC interrupt number
> > +        * provided and rzn1_irqmux_output_line[] mapping array.
> > +        */
> > +
> > +       if (parent_args->args_count != 3 ||
> > +           parent_args->args[0] != GIC_SPI) {
> > +               dev_err(dev, "Invalid interrupt-map item\n");
> > +               return -EINVAL;
> > +       }
> > +
> > +       for (i = 0; i < output_lines_count; i++) {
> > +               if (parent_args->args[1] == output_lines[i])
> > +                       return i;
> > +       }  
> 
> ... then this loop can be replaced by two simple comparisons.
> 
> > +
> > +       dev_err(dev, "Invalid GIC interrupt %u\n", parent_args->args[1]);
> > +       return -EINVAL;
> > +}
> > +
> > +static int rzn1_irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)
> > +{
> > +       struct of_imap_parser imap_parser;
> > +       struct of_imap_item imap_item;
> > +       unsigned long index_done = 0;  
> 
> Perhaps "DECLARE_BITMAP(index_done, RZN1_IRQMUX_NUM_IRQS)",
> so the BITS_PER_LONG limit can be lifted, without any cost?

Yes.

> 
> > +       int index;
> > +       int ret;
> > +       u32 tmp;
> > +
> > +       /* We support only #interrupt-cells = <1> and #address-cells = <0> */
> > +       ret = of_property_read_u32(np, "#interrupt-cells", &tmp);
> > +       if (ret)
> > +               return ret;
> > +       if (tmp != 1)
> > +               return -EINVAL;
> > +
> > +       ret = of_property_read_u32(np, "#address-cells", &tmp);
> > +       if (ret)
> > +               return ret;
> > +       if (tmp != 0)
> > +               return -EINVAL;
> > +
> > +       ret = of_imap_parser_init(&imap_parser, np, &imap_item);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* 8 output lines are available */
> > +       BUILD_BUG_ON(ARRAY_SIZE(rzn1_irqmux_output_lines) != 8);  
> 
> ... then this check can be removed, too.
> 
> > +
> > +       /*
> > +        * index_done is an unsigned long integer. Be sure that no buffer
> > +        * overflow can occur.
> > +        */
> > +       BUILD_BUG_ON(ARRAY_SIZE(rzn1_irqmux_output_lines) > BITS_PER_LONG);  
> 
> Currently this is less strict than the check above, so a bit useless?

Yes. My first intention was to explicitly check both constraints:
  - The number of output lines which lead to the maximum index value used to
    index register addresses (i.e. writel(imap_item.child_imap[0], regs + index)
    below).

  - The number of output lines to the maximum index value used to
    index register addresses which which lead to the maximum index value used
    for testing and setting the "index_done" flags.

But yes, I can keep the stricter one.

Also, if RZN1_IRQMUX_NUM_IRQS is introduced and related DECLARE_BITMAP(index_done,
RZN1_IRQMUX_NUM_IRQS), a single check against RZN1_IRQMUX_NUM_IRQS will be enough
for both cases

> 
> > +
> > +       for_each_of_imap_item(&imap_parser, &imap_item) {
> > +               index = rzn1_irqmux_parent_args_to_line_index(dev,
> > +                                                             &imap_item.parent_args,
> > +                                                             rzn1_irqmux_output_lines,
> > +                                                             ARRAY_SIZE(rzn1_irqmux_output_lines));
> > +               if (index < 0) {
> > +                       of_node_put(imap_item.parent_args.np);
> > +                       return index;
> > +               }
> > +
> > +               if (test_and_set_bit(index, &index_done)) {
> > +                       of_node_put(imap_item.parent_args.np);
> > +                       dev_err(dev, "Mux output line already defined\n");
> > +                       return -EINVAL;
> > +               }
> > +
> > +               /*
> > +                * The child #address-cells is 0 (already checked). The first
> > +                * value in imap item is the src hwirq.
> > +                */
> > +               writel(imap_item.child_imap[0], regs + index);
> > +       }
> > +
> > +       return 0;
> > +}  
> 


  reply	other threads:[~2025-10-22 13:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20  8:06 [PATCH v5 0/8] gpio: renesas: Add support for GPIO and related interrupts in RZ/N1 SoC Herve Codina (Schneider Electric)
2025-10-20  8:06 ` [PATCH v5 1/8] of/irq: Introduce for_each_of_imap_item Herve Codina (Schneider Electric)
2025-10-26 21:26   ` Rob Herring (Arm)
2025-10-20  8:06 ` [PATCH v5 2/8] of: unittest: Add a test case for for_each_of_imap_item iterator Herve Codina (Schneider Electric)
2025-10-26 21:28   ` Rob Herring (Arm)
2025-10-20  8:06 ` [PATCH v5 3/8] irqchip/ls-extirq: Use " Herve Codina (Schneider Electric)
2025-10-20  8:06 ` [PATCH v5 4/8] irqchip/renesas-rza1: " Herve Codina (Schneider Electric)
2025-10-20  8:06 ` [PATCH v5 5/8] ARM: dts: r9a06g032: Add GPIO controllers Herve Codina (Schneider Electric)
2025-10-20  8:06 ` [PATCH v5 6/8] dt-bindings: soc: renesas: Add the Renesas RZ/N1 GPIO Interrupt Multiplexer Herve Codina (Schneider Electric)
2025-10-26 21:29   ` Rob Herring (Arm)
2025-10-20  8:06 ` [PATCH v5 7/8] soc: renesas: Add support for " Herve Codina (Schneider Electric)
2025-10-21 13:05   ` Geert Uytterhoeven
2025-10-22 13:03     ` Herve Codina [this message]
2025-10-23 11:30       ` Geert Uytterhoeven
2025-10-23 13:20         ` Herve Codina
2025-10-24  7:24           ` Geert Uytterhoeven
2025-10-20  8:06 ` [PATCH v5 8/8] ARM: dts: r9a06g032: Add support for GPIO interrupts Herve Codina (Schneider Electric)
2025-10-21  7:13 ` [PATCH v5 0/8] gpio: renesas: Add support for GPIO and related interrupts in RZ/N1 SoC Linus Walleij
2025-10-22  9:00 ` Wolfram Sang
2025-10-25  8:52   ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251022150339.4c48649e@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=hoan@os.amperecomputing.com \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=pascal.eberhard@se.com \
    --cc=phil.edworthy@renesas.com \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).