K3 AM62x SoC dts/dtsi include hierarchy and naming scheme

[Raghavendra, Vignesh]

On 2/10/2023 11:35 PM, Francesco Dolcini wrote:
[...]

>>>
>>
>> Typically, our strategy has been to introduce the superset device,
>> primarily because the device variants are quite a few, and without
>> actual users, it makes no sense to introduce a dtsi in kernel
>> in-anticipation of a potential board. Now that said, also keep in mind
>> the part number definitions do change depending on the market demands
>> over time (qualification requirements etc..), The initial device tree
>> was based on the definition we had at the time, as usual, over time,
>> definitions are changing :(.
> 	
> ... and from my point of view this is normal and fine. All good :-)
> 
>> Considering the potential combinatorial explosion if we are trying
>> to constantly catching up with variations of chip configurations as
>> market definitions change over time, we need to be a bit pragmatic in
>> the various dtsi files we introduce. With that in mind, If we have
>> just one board using the part variant, we should reduce the churn in
>> the tree by keeping the processor variation isolated to the board
>> (See arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi as an
>> example), on the other hand, the AM6251 (Single A53 variant) promises
>> to be a variant that will probably get used in multiple boards, I'd
>> suggest introducing a dtsi that is reused across the boards.
> 
> Our current plan is to have multiple SKUs that will differentiate by the
> specific SoC SKU, not sure if this was clear to you, as an example we
> will have.
> 
> for board in variant1 variant2 variant3
>   k3-am6251-${board}.dts
>   k3-am6252-${board}.dts
>   k3-am6254-${board}.dts
>   k3-am6231-${board}.dts
>   k3-am6232-${board}.dts
>   k3-am6234-${board}.dts
> 
> that are just the same apart the AM62x SKU.
> Do you expect something like that (18 .dts files, in this example) ?
> 
> To me this is absolutely fine, I just want to be sure this is what you
> expect.

I am not sure if we need 18 files, IMO having dts for superset SoC per
board variant for each SoC variant is sufficient:

for board in variant1 variant2 variant3
   k3-am625-${board}.dts (assume k3-am6254-${board}.dts)
   k3-am623-${board}.dts (assume k3-am6234-${board}.dts)

And then fixup num CPUs from U-Boot as per SoC detection as long as
board remains **exactly same** as super set.

This will limit .dts files to 6. Also limits bootloader's role to just
disabling CPU cores instead of fiddling around with too many non
transparent DT fixups.

Nishanth: feel free to chime in if you have different opinion.


> 
> For example we do have these dts boards file here
> 
> arch/arm64/boot/dts/freescale/imx8mm-verdin-*.dts
> 
> and the FDT is patched in U-Boot in
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/soc.c#L1245
> 
> with the this approach we have 4 dts files instead of the 16 if we would
> use the exact SOC SKU variant [0].
> 
> Francesco
> 
> [0] https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
> 


Regards
Vignesh