On Fri, Sep 9, 2022 at 9:10 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Fri, Sep 9, 2022 at 5:42 AM Samuel Holland <samuel@xxxxxxxxxxxx> wrote: > > On 8/22/22 10:29 AM, Jessica Clarke wrote: > > > On 22 Aug 2022, at 14:56, conor.dooley@xxxxxxxxxxxxx wrote: > > >> On 22/08/2022 13:31, Geert Uytterhoeven wrote: > > >>>> 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. > > >> > > >> Right, one level up but ~the same result. > > >> > > >>>>> 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(). > > >> > > >> Yup, in the same boat here. mayb I'll get bored enough to bite.. > > > > > > Note that GPL’ed dtc isn’t the only implementation. FreeBSD uses a > > > BSD-licensed implementation[1] and so adding new features like this to > > > GPL dtc that actually get used would require us to reimplement it too. > > > I don’t know how much effort it would be but please keep this in mind. > > > > I plan to go with the "SOC_PERIPHERAL_IRQ(na, nr)" implementation for v2. I like > > that it only affects the DT source, and does not leak into the DTB. We still > > have the freedom to switch to using arithmetic later when all of the tools > > support it. > > May I suggest an alternative solution, which would be more generic, > and can be extended to other/more CPU cores easily: > > Specify both interrupts in the .dtsi, but wrapped inside e.g. ARM() > resp. RISCV() macros: > > ARM(interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;) > RISCV(interrupts = <412 IRQ_TYPE_LEVEL_HIGH>;) > > The same construct can be used for e.g. interrupt-parent. > The ARM .dts would define: > > #define ARM(x...) x > #define RISCV(x....) > > before including the .dtsi. > The RISC-V DTS would define instead: > > #define ARM(x...) > #define RISCV(x...) x > > Cfr. the AR_CLASS(), M_CLASS(), ARM(), and THUMB() macros in > arch/arm/include/asm/unified.h. I brought it up with the DT people in a separate thread[1]. Please continue the discussion there. Thanks! [1] https://lore.kernel.org/r/CAMuHMdUPm36RsxHdVwspR3NCAR3C507AyB6R65W42N2gXWq0ag@xxxxxxxxxxxxxx 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
