K3 AM62x SoC dts/dtsi include hierarchy and naming scheme

[Francesco Dolcini]

On Thu, Feb 09, 2023 at 09:33:52AM -0600, Nishanth Menon wrote:
> On 19:44-20230207, Francesco Dolcini wrote:
> > Hello Vignesh and all,
> > I am writing you to get some clarification on the way the dts/dtsi
> > naming and include hierarchy is designed for the TI K3 AM62x SOC family.
> > 
> > I read commit f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC").
> > 
> > I plan to send in the next few weeks some device tree files for
> > inclusion in the kernel for SOM (or computer on module) based on the
> > AM62x SOC.
> > 
> > I do envision to have the same dts file for different machine that are
> > going to use different variant of the AM62x SOC, e.g. AM623 vs AM625 or
> > just a different number of CPU cores, handling the differences at
> > runtime (patching the .dtb in U-Boot?) to limit the maintenance effort and
> > limit the amount of very similar dts files.
> > 
> > Said that we would prefer to stay close with what is considered/agreed
> > to be the best approach.
> > 
> > Would something like that work or you would have a completely different
> > expectation?
> > 
> > What would be the expected naming scheme? k3-am62-${board_name}.dts ?
> > Something else?
> > 
> > k3-am625.dtsi defines the CPU nodes, why are these in a AM625 specific
> > file? To me this looks like something that would be just the same with
> > AM623, and at the same time AM6251 has only one core (see [0] Table 5-1).
> > Am I missing something?
> > 
> > Thanks for your help,
> > Francesco
> > 
> > [0] https://www.ti.com/lit/ds/symlink/am625.pdf 
> > 
> 
> 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.

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