Hello Francois,
in our last meeting you suggested to investigate deeper what meaning modularization in device trees could mean.
One example I have seen is the definition of memory mappings for PCIe.
If for you example you look in the device tree of the Raspberry Pi 4 you can find that there is an entry:
pcie@7d500000 { ranges = < 0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>; };
The ranges property defines the mapping MEM 0x600000000..0x603ffffff -> 0xf8000000 and thereby the address and size of the memory windows used for communication.
On some boards e.g. the MacchitoBin you have multiple platform devices each with its own ranges definitions. Here are the values in May 2019:
pcie@f2600000 { ranges = < 0x81000000 0x0 0xf9000000 0x0 0xf9000000 0x0 0x10000 0x82000000 0x0 0xf6000000 0x0 0xf6000000 0x0 0xf00000>; } pcie@f2620000 { ranges = < 0x81000000 0x0 0xf9010000 0x0 0xf9010000 0x0 0x10000 0x82000000 0x0 0xf7000000 0x0 0xf7000000 0x0 0xf00000>; } pcie@f2640000 { ranges = < 0x81000000 0x0 0xf9020000 0x0 0xf9020000 0x0 0x10000 0x82000000 0x0 0xf8000000 0x0 0xf8000000 0x0 0xf00000>; }
On my MacchitoBin the GPU card was not usable because the memory window was too small to create the required BARs. Changing the window size and location solved the problem, commit d3446b266a8c ("arm64: dts: marvell: mcbin: enlarge PCI memory window").
The problem with the current way in qhich PCI devices are declared is that they do not indicate requirements and capabilities and let the software figure out a good mapping. But instead fixed mappings are hard-coded into the device-tree.
So for me this would be one element of DT modularization:
The description of a device should provide capabilities and requirements and avoid fixed software settings.
Best regards
Heinrich