Re: [PATCH 2/2] arm64: dts: rockchip: Add CM3588 NAS board

[Dragan Simic]

Hello Sebastian,

On 2024-05-28 19:22, Sebastian Kropatsch wrote:
> Am 27.05.2024 um 21:02 schrieb Jonas Karlman:
> > On 2024-05-26 23:48, Sebastian Kropatsch wrote:
> > > The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based 
> > > on
> > > the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.
> > >
> > > [...]
> > >
> > > PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 
> > > x1
> > > speed. Data lane mapping in the DT is done like described in commit
> > > f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588").
> > >
> > > This device tree includes support for eMMC, SD card, ethernet, all 
> > > USB2
> > > and USB3 ports, all four M.2 slots, GPU, RTC, buzzer, UART debugging 
> > > as
> > > well as the buttons and LEDs.
> > > The GPIOs are labeled according to the schematics.
> > >
> > > Signed-off-by: Sebastian Kropatsch <seb-dev@xxxxxx>
> > > ---
> > >   arch/arm64/boot/dts/rockchip/Makefile         |    1 +
> > >   .../boot/dts/rockchip/rk3588-cm3588-nas.dts   | 1269 
> > > +++++++++++++++++
> > >   2 files changed, 1270 insertions(+)
> > >   create mode 100644 
> > > arch/arm64/boot/dts/rockchip/rk3588-cm3588-nas.dts
> >
> > Because the CM3588 is a SoM and the NAS is a carrier board this should
> > probably be split in two, cm3588.dtsi and cm3588-nas.dts.
>
> I thought about this before submitting. My reason for not splitting 
> this
> into two files for now was that as far as I know this board is the only
> combination for the CM, maybe no other daughter board will ever get
> released. If another carrier board compatible with the CM3588 is
> released, the splitting could be done at that point in time.
>
> But since both you and Heiko prefer to have it split, I will figure out
> a way how and which parts will have to split up to the CM so we can
> have two files in the end. I guess most things will go into the NAS dts
> anyway.
>
> I'll have a look how other Rockchip compute modules with split device
> trees were done in the past and orient myself by that.

I also support the DT split between the SoM and the carrier board,
even if there are currently no more carrier boards available for
the particular SoM.  That may seem redundant, but it reflects the
nature of the hardware setup, in which the SoM plugs into the carrier
board.  This follows the principle of the DT describing hardware.