Re: [PATCH 04/13] arm64: dts: ti: k3-am65: Enable OSPI nodes at the board level

[Andrew Davis <afd@ti.com>]

On 8/7/23 1:16 AM, Dhruva Gole wrote:
> Hi Andrew,
> 
> On 03/08/23 02:23, Andrew Davis wrote:
>> OSPI nodes defined in the top-level AM65x SoC dtsi files are incomplete
>> and may not be functional unless they are extended with pinmux and
>> device information.
>>
>> As the attached OSPI device is only known about at the board integration
>> level, these nodes should only be enabled when provided with this
>> information.
>>
>> Disable the OSPI nodes in the dtsi files and only enable the ones that
>> are actually pinned out on a given board.
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 1 +
>>   arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi            | 2 ++
>>   arch/arm64/boot/dts/ti/k3-am654-base-board.dts     | 1 +
>>   3 files changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
>> index e26bd988e5224..6041862d5aa75 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
>> @@ -593,6 +593,7 @@ adc {
>>   };
>>   &ospi0 {
>> +    status = "okay";
> 
> Ok, so this k3-am65-iot2050 series of DT files seem to be structured in
> a bit different manner than our SKs and EVMs?
> 
> The terminologies like advanced, advanced-m2, basic, etc. are a little
> confusing to me. However, I am wondering if we don't do any status = ..
> here, and rather make ospi status okays from the iot2050 dts files?
> 
> Pardon me if I am making an invalid suggestion, I don't have much
> background on these boards.
> 

This is a valid question, and yes the IOT2050 DTS organization is
slightly different than the one we use with our SK/EVMs.

The way these DT files tend to work is layering more functionality
or information in each file, starting with the core/most common
in the base .dtsi, and ending with .dts that is specific to a given
board. (In that way I would consider instances of "/delete-node/"
to be an indicator of bad layering, but that is a different topic..)

Any node that is only partially defined in a layer should be marked
disabled, and then only enabled in the layer that finally completes
the node. That is often the pinmux info at the board level.

In this case, the OSPI nodes are complete after this point, there
is no additional information given in the DTS files, so we can
enable it here in this .dtsi file.

Andrew

>>       pinctrl-names = "default";
>>       pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> index 7b1f94a89eca8..2c9c20a9d9179 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> @@ -295,6 +295,7 @@ ospi0: spi@47040000 {
>>               power-domains = <&k3_pds 248 TI_SCI_PD_EXCLUSIVE>;
>>               #address-cells = <1>;
>>               #size-cells = <0>;
>> +            status = "disabled";
>>           };
>>           ospi1: spi@47050000 {
>> @@ -309,6 +310,7 @@ ospi1: spi@47050000 {
>>               power-domains = <&k3_pds 249 TI_SCI_PD_EXCLUSIVE>;
>>               #address-cells = <1>;
>>               #size-cells = <0>;
>> +            status = "disabled";
>>           };
>>       };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>> index 973a89b04a22f..43de7c132d343 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>> @@ -530,6 +530,7 @@ &mcu_r5fss0_core1 {
>>   };
>>   &ospi0 {
>> +    status = "okay";
>>       pinctrl-names = "default";
>>       pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
>