[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45d2e6c2-3b4b-5720-0431-002c74b1f9cc@arm.com>
Date: Wed, 21 Sep 2022 10:20:08 +0100
From: Robin Murphy <robin.murphy@....com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc: Andre Przywara <andre.przywara@....com>,
Conor Dooley <conor.dooley@...rochip.com>,
Samuel Holland <samuel@...lland.org>,
Biju Das <biju.das.jz@...renesas.com>,
Chris Paterson <Chris.Paterson2@...esas.com>,
Atish Patra <atishp@...shpatra.org>,
"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Similar SoCs with different CPUs and interrupt bindings
On 2022-09-21 08:46, Geert Uytterhoeven wrote:
> Hi Rob, Krzysztof,
>
> This is a topic that came up at the RISC-V BoF at Plumbers, and it was
> suggested to bring it up with you.
>
> The same SoC may be available with either RISC-V or other (e.g. ARM) CPU
> cores (an example of this are the Renesas RZ/Five and RZ/G2UL SoCs).
> To avoid duplication, we would like to have:
> - <riscv-soc>.dtsi includes <base-soc>.dtsi,
> - <arm-soc>.dtsi includes <base-soc>.dtsi.
>
> Unfortunately RISC-V and ARM typically use different types of interrupt
> controllers, using different bindings (e.g. 2-cell vs. 3-cell), and
> possibly using different interrupt numbers. Hence the interrupt-parent
> and interrupts{-extended} properties should be different, too.
>
> Possible solutions[1]:
> 1. interrupt-map
>
> 2. Use a SOC_PERIPHERAL_IRQ() macro in interrupts properties in
> <base-soc>.dtsi, with
> - #define SOC_PERIPHERAL_IRQ(nr, na) nr // RISC-V
> - #define SOC_PERIPHERAL_IRQ(nr, na) GIC_SPI na // ARM
> Note that the cpp/dtc combo does not support arithmetic, so even
> the simple case where nr = 32 + na cannot be simplified.
>
> 3. Wrap inside RISCV() and ARM() macros, e.g.:
>
> RISCV(interrupts = <412 IRQ_TYPE_LEVEL_HIGH>;)
> ARM(interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;)
>
> Cfr. ARM() and THUMB() in arch/arm/include/asm/unified.h, as used
> to express the same operation using plain ARM or ARM Thumb
> instructions.
4. Put all the "interrupts" properties in the SoC-specific DTSI at the
same level as the interrupt controller to which they correspond. Works
out of the box with no horrible mystery macros, and is really no more or
less error-prone than any other approach. Yes, it means replicating a
bit of structure and/or having labels for everything (many of which may
be wanted anyway), but that's not necessarily a bad thing for
readability anyway. Hierarchical definitions are standard FDT practice
and should be well understood, so this is arguably the simplest and
least surprising approach :)
Cheers,
Robin.
> Personally, I'm leaning towards the third solution, as it is the most
> flexible, and allows us to extend to more than 2 interrupt controllers.
>
> Note that this is actually not a new issue. For years, ARM SoCs have
> existed with multiple types of cores on the same die, using Cortex-A
> cores for the application, and Cortex-R/SuperH/V850/... cores for
> real-time and/or baseband operation. So far this wasn't an issue, as
> only the Cortex-A cores ran Linux, and we ignored the other cores (and
> the related interrupt controllers and hierarchy) in DT.
>
> What do you think?
> Thanks for your comments!
>
> [1] https://lore.kernel.org/lkml/20220815050815.22340-7-samuel@sholland.org
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Powered by blists - more mailing lists