Message ID | 20230802205309.257392-5-afd@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f41:0:b0:3e4:2afc:c1 with SMTP id v1csp737730vqx; Wed, 2 Aug 2023 14:29:58 -0700 (PDT) X-Google-Smtp-Source: APBJJlFcIKKxhJDrW538qeEjjTsztp65eiDlyDEXgpTiKAX7ywQ2cfYsc50ELviZ8uaBky07yB1d X-Received: by 2002:a17:907:1ca7:b0:978:2b56:d76e with SMTP id nb39-20020a1709071ca700b009782b56d76emr8747554ejc.12.1691011798537; Wed, 02 Aug 2023 14:29:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691011798; cv=none; d=google.com; s=arc-20160816; b=TC8IJisVX2TPBxdWWI386hQBV07mT8oMnurFiOg4LekOtRFxpw6qgBkjBljr6KW3Da pGlGLB0MoyPB3IMT/eUqrMnP7mQ7/8ATGaIFT8+QPEp/KAQ0PCqk/QNNkruoDMiykjPm YxFvsT53oFCRds8TjRpu2BSF6DVokKhaiuBa5nYD8kutLX324O9jOajXy1gTZyVkXD6x uDyGwbfsPgg1v4oj0d8RdeXP2xWjqEKp9Zv5KTNHTLQfRIYlhQIsehbKhyjnHVk7fMtD uktDhEg481h0ICzplR5btUB05DfpsGvyCJEpTxMAvGR4SFwPCVu+u3vFFTLuvrpEAMeK 0JGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=znWex16Y60PCPpX3wNxyCdSXP099wFwmM+Z6mxV+hwc=; fh=878OLI05L9osNW8108hv37bieiY2kkkgXUhCMqaYoVQ=; b=TEMHwxTLaropgXeWKZUb64jR0N8FfqCXuAEOvIcETuxVyUUxUbAr/lI4PMicsThwzJ fjzp5sHSn5+PZu0921ibg+0WnlL1XlCwWRa+xDXQt2nwkSswTKU2kF2WXzhqAX2TYcLQ n5dwyD5fozAs5cILIPgx44BMqnnjcdK1QvcFtG627GuDcMYpf/fJESQm9hd80PsaF2qo IrbcEZtV3jv9zZvLoMPrHqs0BfLZzIxfaY4vQLHOWYm23e2nw1NB4N0GIekV0JKcGHPX RtO74GXJ3iggA28RsY/22WxSBtcVpi0/+k3MFbjc355WgFQZTyDhjhLRDvxHtIuFOfgF x0ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=y71zSxG7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k22-20020a17090627d600b00992d8355decsi11158235ejc.249.2023.08.02.14.29.34; Wed, 02 Aug 2023 14:29:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=y71zSxG7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231886AbjHBUyO (ORCPT <rfc822;maxi.paulin@gmail.com> + 99 others); Wed, 2 Aug 2023 16:54:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232736AbjHBUxd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 2 Aug 2023 16:53:33 -0400 Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E74102D42; Wed, 2 Aug 2023 13:53:27 -0700 (PDT) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 372KrE3d098036; Wed, 2 Aug 2023 15:53:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1691009594; bh=znWex16Y60PCPpX3wNxyCdSXP099wFwmM+Z6mxV+hwc=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=y71zSxG7EfDlqDqiMAPb+LN2m5Q0y8/rveEN1j37+uFrYdZMQAokBLgZHpHrSGZzh oMEVl/Oq6wwrttmpJtLDsIol2aQ+rUAPOFaPD+RS3NU+Oh9uytV2mZxlx/8pjJrz0X tqACw2d22lbMS7CabDyHKubiwptUDLnHiouCYl/g= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 372KrDkh071657 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 2 Aug 2023 15:53:13 -0500 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 2 Aug 2023 15:53:13 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 2 Aug 2023 15:53:13 -0500 Received: from lelv0326.itg.ti.com (ileaxei01-snat.itg.ti.com [10.180.69.5]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 372KrASB090834; Wed, 2 Aug 2023 15:53:13 -0500 From: Andrew Davis <afd@ti.com> To: Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tero Kristo <kristo@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org> CC: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Andrew Davis <afd@ti.com> Subject: [PATCH 04/13] arm64: dts: ti: k3-am65: Enable OSPI nodes at the board level Date: Wed, 2 Aug 2023 15:53:00 -0500 Message-ID: <20230802205309.257392-5-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230802205309.257392-1-afd@ti.com> References: <20230802205309.257392-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773154387463410798 X-GMAIL-MSGID: 1773154387463410798 |
Series |
Another round of K3 DTSI disables
|
|
Commit Message
Andrew Davis
Aug. 2, 2023, 8:53 p.m. UTC
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(+)
Comments
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. > 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>; >
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>; >
On 07.08.23 17:18, Andrew Davis wrote: > 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. > Ack, this file is the right place to enable OSPI because all our boards have OSPI in use, and therefore it is configured at this common level already. And the reasons for delete-node is obviously that there is no dtsi file that describes the AM6528 with its two cores only. If you consider that bad layering, you should change your dtsi files ;). But I see no real problem here, that pattern is not uncommon. Jan
On 8/8/23 12:27 AM, Jan Kiszka wrote: > On 07.08.23 17:18, Andrew Davis wrote: >> 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. >> > > Ack, this file is the right place to enable OSPI because all our boards > have OSPI in use, and therefore it is configured at this common level > already. > > And the reasons for delete-node is obviously that there is no dtsi file > that describes the AM6528 with its two cores only. If you consider that > bad layering, you should change your dtsi files ;). But I see no real > problem here, that pattern is not uncommon. Yup, wasn't finger pointing, that is our layering problem. It actually looks like an easy fix to add an k3-am652.dtsi with only two cores, I'll go do that for next cycle. Andrew > > Jan >
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"; 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>;