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

[Sebastian Kropatsch]

Hi Dragan,

Am 29.05.2024 um 02:10 schrieb 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 at web.de>
>>>> ---
>>>>   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.

Following the principle of the DT describing the hardware does make
sense, that's a very good explanation!
I'll try to follow up with this in a v2 in the next few days.

Thank you,
Sebastian