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>
---
drivers/soc/renesas/Kconfig | 4 ++
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/rzn1_irqmux.c | 110 ++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+)
create mode 100644 drivers/soc/renesas/rzn1_irqmux.c
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 719b7f4f376f..0878b6884515 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -58,6 +58,7 @@ config ARCH_RZN1
select PM
select PM_GENERIC_DOMAINS
select ARM_AMBA
+ select RZN1_IRQMUX
if ARM && ARCH_RENESAS
@@ -447,6 +448,9 @@ config PWC_RZV2M
config RST_RCAR
bool "Reset Controller support for R-Car" if COMPILE_TEST
+config RZN1_IRQMUX
+ bool "Renesas RZ/N1 GPIO IRQ multiplexer support" if COMPILE_TEST
+
config SYSC_RZ
bool "System controller for RZ SoCs" if COMPILE_TEST
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 3bdcc6a395d5..daa932c7698d 100644
--- 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
obj-$(CONFIG_SYSC_RZ) += rz-sysc.o
diff --git a/drivers/soc/renesas/rzn1_irqmux.c b/drivers/soc/renesas/rzn1_irqmux.c
new file mode 100644
index 000000000000..3855e132c15f
--- /dev/null
+++ b/drivers/soc/renesas/rzn1_irqmux.c
@@ -0,0 +1,110 @@
+// 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/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
+#define IRQMUX_MAX_IRQS 8
+
+static int 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 int index = 0;
+ u32 tmp;
+ int ret;
+
+ /* 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;
+
+ for_each_of_imap_item(&imap_parser, &imap_item) {
+ /*
+ * The child #address-cells is 0 (already checked). The first
+ * value in imap item is the src hwirq.
+ *
+ * imap items matches 1:1 the interrupt lines that could
+ * be configured by registers (same order, same number).
+ * Configure the related register with the src hwirq retrieved
+ * from the interrupt-map.
+ */
+ if (index > IRQMUX_MAX_IRQS) {
+ of_node_put(imap_item.parent_args.np);
+ dev_err(dev, "too much items in interrupt-map\n");
+ return -EINVAL;
+ }
+
+ writel(imap_item.child_imap[0], regs + index);
+ index++;
+ }
+
+ return 0;
+}
+
+static int irqmux_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ u32 __iomem *regs;
+ int nr_irqs;
+ int ret;
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ nr_irqs = of_irq_count(np);
+ if (nr_irqs < 0)
+ return nr_irqs;
+
+ if (nr_irqs > IRQMUX_MAX_IRQS) {
+ dev_err(dev, "too many output interrupts\n");
+ return -ENOENT;
+ }
+
+ ret = irqmux_setup(dev, np, regs);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to setup mux\n");
+
+ return 0;
+}
+
+static const struct of_device_id irqmux_of_match[] = {
+ { .compatible = "renesas,rzn1-gpioirqmux", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, irq_mux_of_match);
+
+static struct platform_driver irqmux_driver = {
+ .probe = irqmux_probe,
+ .driver = {
+ .name = "rzn1_irqmux",
+ .of_match_table = irqmux_of_match,
+ },
+};
+module_platform_driver(irqmux_driver);
+
+MODULE_AUTHOR("Herve Codina <herve.codina@bootlin.com>");
+MODULE_DESCRIPTION("Renesas RZ/N1 GPIO IRQ Multiplexer Driver");
+MODULE_LICENSE("GPL");
--
2.51.0Hi Herve,
> +#define IRQMUX_MAX_IRQS 8
> +
> +static int irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)
The whole driver would benefit from a 'rzn1_irqmux' instead of 'irqmux'
prefix, I'd say.
> + for_each_of_imap_item(&imap_parser, &imap_item) {
> + /*
> + * The child #address-cells is 0 (already checked). The first
> + * value in imap item is the src hwirq.
> + *
> + * imap items matches 1:1 the interrupt lines that could
> + * be configured by registers (same order, same number).
> + * Configure the related register with the src hwirq retrieved
> + * from the interrupt-map.
> + */
I haven't looked into the above for_each_of_imap_item-helper. But
wouldn't it be possibleto retrieve the GIC_SPI number as well and use
the correct register based on that? That would remove the need of an
already sorted interrupt-map.
> + if (index > IRQMUX_MAX_IRQS) {
> + of_node_put(imap_item.parent_args.np);
> + dev_err(dev, "too much items in interrupt-map\n");
> + return -EINVAL;
-E2BIG? With such a unique errno, we could even drop the dev_err.
> + }
> +
> + writel(imap_item.child_imap[0], regs + index);
> + index++;
> + }
> +
> + return 0;
> +}
> +
> +static int irqmux_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + u32 __iomem *regs;
> + int nr_irqs;
> + int ret;
> +
> + regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> + nr_irqs = of_irq_count(np);
> + if (nr_irqs < 0)
> + return nr_irqs;
> +
> + if (nr_irqs > IRQMUX_MAX_IRQS) {
> + dev_err(dev, "too many output interrupts\n");
> + return -ENOENT;
-E2BIG? Wait, isn't this the same check twice?
Thanks for this work,
Wolfram
Hi Wolfram,
On Fri, 19 Sep 2025 11:41:39 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> Hi Herve,
>
> > +#define IRQMUX_MAX_IRQS 8
> > +
> > +static int irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)
>
> The whole driver would benefit from a 'rzn1_irqmux' instead of 'irqmux'
> prefix, I'd say.
Agree, I will used the 'rzn1_irqmux' prefix.
>
> > + for_each_of_imap_item(&imap_parser, &imap_item) {
> > + /*
> > + * The child #address-cells is 0 (already checked). The first
> > + * value in imap item is the src hwirq.
> > + *
> > + * imap items matches 1:1 the interrupt lines that could
> > + * be configured by registers (same order, same number).
> > + * Configure the related register with the src hwirq retrieved
> > + * from the interrupt-map.
> > + */
>
> I haven't looked into the above for_each_of_imap_item-helper. But
> wouldn't it be possibleto retrieve the GIC_SPI number as well and use
> the correct register based on that? That would remove the need of an
> already sorted interrupt-map.
Hum, this give the knowledge of the GIC interrupt number in the driver itself.
Not sure that the mapping between the output interrupt line number N (handled
by register index N) and the GIC interrupt number X should be hardcoded in
the driver.
In my v1 series iteration, I used the 'interrupts' property to provide this
missing information:
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* line 0 (reg index 0) route to GIC 103 */
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, /* line 1 (reg index 1) route to GIC 104 */
<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, /* line 2 (reg index 2) route to GIC 105 */
...
Base on the interrupts table and the interrupt-map, I deduce the reg index:
- From interrupt-map, got a GIC interrupt number
- From interrupts table and the GIC interrupt number, got the line/reg index.
Rob asked to use only interrupt-map and use directly the interrupt-map index as
the hardware index:
https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/
>
> > + if (index > IRQMUX_MAX_IRQS) {
> > + of_node_put(imap_item.parent_args.np);
> > + dev_err(dev, "too much items in interrupt-map\n");
> > + return -EINVAL;
>
> -E2BIG? With such a unique errno, we could even drop the dev_err.
Yes sure.
>
> > + }
> > +
> > + writel(imap_item.child_imap[0], regs + index);
> > + index++;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int irqmux_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + u32 __iomem *regs;
> > + int nr_irqs;
> > + int ret;
> > +
> > + regs = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(regs))
> > + return PTR_ERR(regs);
> > +
> > + nr_irqs = of_irq_count(np);
> > + if (nr_irqs < 0)
> > + return nr_irqs;
> > +
> > + if (nr_irqs > IRQMUX_MAX_IRQS) {
> > + dev_err(dev, "too many output interrupts\n");
> > + return -ENOENT;
>
> -E2BIG? Wait, isn't this the same check twice?
This is not the same check but this one should not be there.
Indeed of_irq_count() counts the number of items available in the
'interrupts' property. This is not used anymore.
I missed to remove it from v1 to v2 updates (and also from v2 to v3).
The of_irq_count() call and related checks will be remove in the next
iteration.
Best regards,
Hervé
> Rob asked to use only interrupt-map and use directly the interrupt-map index as > the hardware index: > https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/ I agree with that. Currently an interrupt-map entry looks like: interrupt-map = <0 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, And the number after GIC_SPI determines the index register, no? Can't we simply say 'index = <SPI_nr_from_dt> - 103' incl. some sanity checks?
Hi Wolfram,
On Fri, 19 Sep 2025 16:40:06 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> > Rob asked to use only interrupt-map and use directly the interrupt-map index as
> > the hardware index:
> > https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/
>
> I agree with that. Currently an interrupt-map entry looks like:
>
> interrupt-map = <0 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
>
> And the number after GIC_SPI determines the index register, no? Can't we
> simply say 'index = <SPI_nr_from_dt> - 103' incl. some sanity checks?
>
And so 103 used to compute the index is hardcoded on the driver.
Further more the wiring of irq-mux interrupt output to the GIC input
line depends on the irq-mux integration and not the irq-mux itself.
Nothing in the irq-mux itself requires a specific connection to the
GIC.
But well, without adding this mapping information in the DT, maybe a
table in the driver in order to determine reg index from GIC IRQ number.
kind of:
static u8 reg_index[8] = {103, 104, 105, ... , 110};
Base on GIC IRQ number retrieve from the interrupt-map item, we search for
the index in reg_index that match this number. The index found is the index
used to access the register.
What do you think about this?
Best regards,
Hervé
> kind of:
> static u8 reg_index[8] = {103, 104, 105, ... , 110};
>
> Base on GIC IRQ number retrieve from the interrupt-map item, we search for
> the index in reg_index that match this number. The index found is the index
> used to access the register.
>
> What do you think about this?
I sure like it better than a fixed ordering in DT. And the advantage
compared to subtracting 103 is that reg_index can be flexible in case we
want to support other SoCs than RZ/N1?
© 2016 - 2025 Red Hat, Inc.