Message-ID: <6ca5d863-8382-0b13-97f8-a69c3271e3ac@ti.com>
Date:   Mon, 13 Feb 2023 19:36:55 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: K3 AM62x SoC dts/dtsi include hierarchy and naming scheme
Content-Language: en-US
To:     Francesco Dolcini <francesco@dolcini.it>,
        Nishanth Menon <nm@ti.com>
CC:     Dave Gerlach <d-gerlach@ti.com>, Tero Kristo <kristo@kernel.org>,
        "Rob Herring" <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <francesco.dolcini@toradex.com>
References: <Y+KcJdvgDw9EqFCz@francesco-nb.int.toradex.com>
 <20230209153352.5tgkqe3xbby7pmju@polio>
 <Y+aHh7B73mkAjR7Q@francesco-nb.int.toradex.com>
From:   "Raghavendra, Vignesh" <vigneshr@ti.com>
In-Reply-To: <Y+aHh7B73mkAjR7Q@francesco-nb.int.toradex.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


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