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@xxxxxx> --- 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>;
