Hi Conor, On Mon, Aug 22, 2022 at 2:13 PM <Conor.Dooley@xxxxxxxxxxxxx> wrote: > On 22/08/2022 12:46, Geert Uytterhoeven wrote: > > On Sun, Aug 21, 2022 at 12:07 PM <Conor.Dooley@xxxxxxxxxxxxx> wrote: > >> On 21/08/2022 07:45, Icenowy Zheng wrote: > >>> 在 2022-08-20星期六的 17:29 +0000，Conor.Dooley@xxxxxxxxxxxxx写道： > >>>> On 20/08/2022 18:24, Samuel Holland wrote: > > >>>>> This is not feasible, due to the different #interrupt-cells. See > >>>>> https://lore.kernel.org/linux-riscv/CAMuHMdXHSMcrVOH+vcrdRRF+i2TkMcFisGxHMBPUEa8nTMFpzw@xxxxxxxxxxxxxx/ > >>>>> > >>>>> Even if we share some file across architectures, you still have to > >>>>> update files > >>>>> in both places to get the interrupts properties correct. > >>>>> > >>>>> I get the desire to deduplicate things, but we already deal with > >>>>> updating the > >>>>> same/similar nodes across several SoCs, so that is nothing new. I > >>>>> think it would > >>>>> be more confusing/complicated to have all of the interrupts > >>>>> properties > >>>>> overridden in a separate file. > >>>> > >>>> Yeah, should maybe have circled back after that conversation, would > >>>> have been > >>>> nice but if the DTC can't do it nicely then w/e. > >>> > >>> Well, maybe we can overuse the facility of C preprocessor? > >>> > >>> e.g. > >>> > >>> ``` > >>> // For ARM > >>> #define SOC_PERIPHERAL_IRQ(n) GIC_SPI n > >>> // For RISC-V > >>> #define SOC_PERIPHERAL_IRQ(n) n > >>> ``` > >>> > >> > >> Geert pointed out that this is not possible (at least on the Renesas > >> stuff) because the GIC interrupt numbers are not the same as the > >> PLIC's & the DTC is not able to handle the addition: > >> https://lore.kernel.org/linux-riscv/CAMuHMdXHSMcrVOH+vcrdRRF+i2TkMcFisGxHMBPUEa8nTMFpzw@xxxxxxxxxxxxxx/ > > > > Without the ability to do additions in DTC, we could e.g. list both > > interrupts in the macro, like: > > > > // For ARM > > #define SOC_PERIPHERAL_IRQ(na, nr) GIC_SPI na > > // For RISC-V > > #define SOC_PERIPHERAL_IRQ(na, nr) nr > > Do you think this is worth doing? Or are you just providing an > example of what could be done? Just some brainstorming... > Where would you envisage putting these macros? I forget the order > of the CPP operations that are done, can they be put in the dts? The SOC_PERIPHERAL_IRQ() macro should be defined in the ARM-based SoC.dtsi file and the RISC-V-based SoC.dtsi file. > > On Mon, Aug 22, 2022 at 12:52 PM Andre Przywara <andre.przywara@xxxxxxx> wrote: > >> There are interrupt-maps for that: > >> sun8i-r528.dtsi: > >> soc { > >> #interrupt-cells = <1>; > >> interrupt-map = <0 18 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, > >> <0 19 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, > >> .... > >> > >> sun20i-d1.dtsi: > >> soc { > >> #interrupt-cells = <1>; > >> interrupt-map = <0 18 &plic 18 IRQ_TYPE_LEVEL_HIGH>, > >> <0 19 &plic 19 IRQ_TYPE_LEVEL_HIGH>, > >> > >> then, in the shared .dtsi: > >> uart0: serial@2500000 { > >> compatible = "snps,dw-apb-uart"; > >> ... > >> interrupts = <18>; > > > > Nice! But it's gonna be a very large interrupt-map. > > I quite like the idea of not duplicating files across the archs > if it can be helped, but not at the expense of making them hard to > understand & I feel like unfortunately the large interrupt map is > in that territory. I feel the same. Even listing both interrupt numbers in SOC_PERIPHERAL_IRQ(na, nr) is a risk for making mistakes. So personally, I'm in favor of teaching dtc arithmetic, so we can handle the offset in SOC_PERIPHERAL_IRQ(). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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
