Hi Conor, Andre,

On Sun, Aug 21, 2022 at 12:07 PM [off-list ref] wrote:

On 21/08/2022 07:45, Icenowy Zheng wrote:

quoted

在 2022-08-20星期六的 17:29 +0000，Conor.Dooley@microchip.com写道：

quoted

On 20/08/2022 18:24, Samuel Holland wrote:

quoted

On 8/15/22 12:01 PM, Conor.Dooley@microchip.com wrote:

quoted

On 15/08/2022 14:11, Andre Przywara wrote:

quoted

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 [off-list ref] wrote:

Hi,

thanks for all the efforts in getting those SoC peripherals
supported!

quoted

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:

quoted

/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/ (local)

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/ (local)

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 [off-list ref] 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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