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;
> > +}
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.