Message-ID: <CAMuHMdUHVpj9ikE2NxpBSBtTG8K6v92vGdbw3GLmEYUoVzatvg@mail.gmail.com>
Date:   Mon, 22 Aug 2022 13:46:47 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Conor Dooley <Conor.Dooley@...rochip.com>
Cc:     uwu@...nowy.me, Samuel Holland <samuel@...lland.org>,
        Andre Przywara <andre.przywara@....com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        linux-sunxi@...ts.linux.dev, Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 06/12] riscv: dts: allwinner: Add the D1 SoC base devicetree

Hi Conor, Andre,

On Sun, Aug 21, 2022 at 12:07 PM <Conor.Dooley@...rochip.com> wrote:
> On 21/08/2022 07:45, Icenowy Zheng wrote:
> > 在 2022-08-20星期六的 17:29 +0000，Conor.Dooley@...rochip.com写道：
> >> On 20/08/2022 18:24, Samuel Holland wrote:
> >>> On 8/15/22 12:01 PM, Conor.Dooley@...rochip.com wrote:
> >>>> On 15/08/2022 14:11, Andre Przywara wrote:
> >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless
> >>>>> you know the content is safe
> >>>>>
> >>>>> On Mon, 15 Aug 2022 00:08:09 -0500
> >>>>> Samuel Holland <samuel@...lland.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> thanks for all the efforts in getting those SoC peripherals
> >>>>> supported!
> >>>>>
> >>>>>> D1 is a SoC containing a single-core T-HEAD Xuantie C906 CPU,
> >>>>>> as well as
> >>>>>> one HiFi 4 DSP. The SoC is based on a design that
> >>>>>> additionally contained
> >>>>>> a pair of Cortex A7's. For that reason, some peripherals are
> >>>>>> duplicated.
> >>>>>
> >>>>> So because of this, the Allwinner R528 and T113 SoCs would
> >>>>> share almost
> >>>>> everything in this file. Would it be useful to already split
> >>>>> this DT up?
> >>>>> To have a base .dtsi, basically this file without /cpus and
> >>>>> /soc/plic,
> >>>>> then have a RISC-V specific file with just those, including the
> >>>>> base?
> >>>>> There is precedence for this across-arch(-directories) sharing
> >>>>> with the
> >>>>> Raspberry Pi and Allwinner H3/H5 SoCs.
> >>>>
> >>>> For those playing along at home, one example is the arm64
> >>>> bananapi m2
> >>>> dts which looks like:
> >>>>> /dts-v1/;
> >>>>> #include "sun50i-h5.dtsi"
> >>>>> #include "sun50i-h5-cpu-opp.dtsi"
> >>>>> #include <arm/sunxi-bananapi-m2-plus-v1.2.dtsi>
> >>>>>
> >>>>> / {
> >>>>>         model = "Banana Pi BPI-M2-Plus v1.2 H5";
> >>>>>         compatible = "bananapi,bpi-m2-plus-v1.2",
> >>>>> "allwinner,sun50i-h5";
> >>>>> };
> >>>>
> >>>> I think this is a pretty good idea, and putting in the modularity
> >>>> up
> >>>> front seems logical to me, so when the arm one does eventually
> >>>> get
> >>>> added it can be done by only touching a single arch.
> >>>
> >>> This is not feasible, due to the different #interrupt-cells. See
> >>> https://lore.kernel.org/linux-riscv/CAMuHMdXHSMcrVOH+vcrdRRF+i2TkMcFisGxHMBPUEa8nTMFpzw@mail.gmail.com/
> >>>
> >>> 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@mail.gmail.com/

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

On Mon, Aug 22, 2022 at 12:52 PM Andre Przywara <andre.przywara@....com> 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@...0000 {
>                         compatible = "snps,dw-apb-uart";
>                         ...
>                         interrupts = <18>;

Nice! But it's gonna be a very large interrupt-map.

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

Powered by blists - more mailing lists