On 8/8/23 8:34 AM, Andrew Davis wrote:
> OSPI nodes defined in the top-level AM64 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 <[email protected]>
> Reviewed-by: Dhruva Gole <[email protected]>
> ---
Oops, I see we have a new AM64 board in -next (tqma64xxl), I can either
rebase this again and enable the nodes in there. Or you can skip this
and the other AM64 patch in this series and I'll resend them next cycle
when that new board is settled.
Andrew
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 1 +
> arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 1 +
> arch/arm64/boot/dts/ti/k3-am642-evm.dts | 1 +
> arch/arm64/boot/dts/ti/k3-am642-sk.dts | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index 4e3e450e4e4c8..ed1b63b9c1c5f 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -794,6 +794,7 @@ ospi0: spi@fc40000 {
> assigned-clock-parents = <&k3_clks 75 7>;
> assigned-clock-rates = <166666666>;
> power-domains = <&k3_pds 75 TI_SCI_PD_EXCLUSIVE>;
> + status = "disabled";
> };
> };
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> index 5606d775153d4..1c2c8f0daca9f 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> @@ -181,6 +181,7 @@ i2c_som_rtc: rtc@52 {
> };
>
> &ospi0 {
> + status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&ospi0_pins_default>;
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index d84e7ee160328..b4a1f73d4fb17 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -520,6 +520,7 @@ &tscadc0 {
> };
>
> &ospi0 {
> + status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&ospi0_pins_default>;
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> index 963d796a3a970..af06ccd466802 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> @@ -518,6 +518,7 @@ &tscadc0 {
> };
>
> &ospi0 {
> + status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&ospi0_pins_default>;
>
On 09:13-20230808, Andrew Davis wrote:
> On 8/8/23 8:34 AM, Andrew Davis wrote:
> > OSPI nodes defined in the top-level AM64 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 <[email protected]>
> > Reviewed-by: Dhruva Gole <[email protected]>
> > ---
>
> Oops, I see we have a new AM64 board in -next (tqma64xxl), I can either
> rebase this again and enable the nodes in there. Or you can skip this
> and the other AM64 patch in this series and I'll resend them next cycle
> when that new board is settled.
we should respin this series taking the new boards into consideration -
am64 and am62 both have new boards.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D