Message ID | 20230505115858.7391-4-vaishnav.a@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp350530vqo; Fri, 5 May 2023 05:09:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5RY7hUjHnt5f6lxRpo+jZ7t4rfv12TiY3JbdQFhV5/L/1qrLb5HdM2h3wXx3gcLx/pGAsO X-Received: by 2002:a17:90b:120d:b0:24d:f1b1:4bea with SMTP id gl13-20020a17090b120d00b0024df1b14beamr6608867pjb.0.1683288543532; Fri, 05 May 2023 05:09:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683288543; cv=none; d=google.com; s=arc-20160816; b=H1r2Qi/cTcFhe4UxFz838vF2V1blqVHb4y96XClVBJaHl6QGztMSGAf9egsZsn2gpf FPcWmttMHAewUzKY+LjfJP7O0dwC+vvBKjJX8ZgfBjtfXsxVGK/nZgqmhgzRqYAKRh2D URHHRY3nX8XTrhg44SrO+GaeQ62BxpvDJo9fF14nCGo/77YpWfIMVYn5b1kJQW03+EZm knnOP3P/jyCGwjMKcdDe30jBFBrY0iQusBswYh+fZtRGUuWOhl6dlJUo1eqcs4MrlXtz GIznO3uExxuIpYt4qp7osDu0TVGlaRiSXwxcvbtdxs4dFoHcjsEM6PYpeT5VHzezlTnK SuxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=mWCCYMK6drSmveVnuahFRASrK8ntgKM85dBE7RuKDO0=; b=E7eKHxcKW+3+ZwT1tlV+c11V4r9KERudxue8PRzUozAz86vkyIfTIFflRifiFZt/Co oj2A//YjF01pqzGwPNCzqTmjh+3vyB3fdT2q450JHLeh5ubNGNYQ+qfOb6YUTeeSp+xh q+IDLH+AwsqZ72fZ7peH+fwmJPcaX7hCqMo8ZhdzPfTmGaXlYkN6yPa3rW/qEVoGvvKI odMyWsz4RxDbu5pLWg169khPKdf6XSyvjBF0+aBWU/6dyawmu16YrXOwCNyKzP0dYnKH OjlU0KikwFqjWL7gj5OmOmtSyNoA3BPKWm9+2XO/OjQJYs6odyIOUHI3OjcoK7VOAtnT qAog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b="vAYCE2/g"; 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 oo2-20020a17090b1c8200b0024b27e48a27si7022219pjb.74.2023.05.05.05.08.48; Fri, 05 May 2023 05:09:03 -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="vAYCE2/g"; 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 S231971AbjEEL7Q (ORCPT <rfc822;foxyelen666@gmail.com> + 99 others); Fri, 5 May 2023 07:59:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229568AbjEEL7O (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 5 May 2023 07:59:14 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6538B30F7; Fri, 5 May 2023 04:59:12 -0700 (PDT) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 345Bx5As119261; Fri, 5 May 2023 06:59:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1683287945; bh=mWCCYMK6drSmveVnuahFRASrK8ntgKM85dBE7RuKDO0=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=vAYCE2/gdcm3qecFP7RtcSW59eo9f5hY5xrReMbVEPtiX/b/RsAu76IVywlOOM5ol v28UQ6weaq+azaT3L/ORoyGycG/DeIq3rqZFPnJBCXljLWz1PLCY0ZWzVI6wA83wni HZKUTW8jo/Awc4D9UCdD7MRlX18fhOKADwQq2S+s= Received: from DFLE105.ent.ti.com (dfle105.ent.ti.com [10.64.6.26]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 345Bx5Vc123195 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 May 2023 06:59:05 -0500 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Fri, 5 May 2023 06:59:05 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE114.ent.ti.com (10.64.6.35) 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; Fri, 5 May 2023 06:59:05 -0500 Received: from localhost (ileaxei01-snat.itg.ti.com [10.180.69.5]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 345Bx4NT100001; Fri, 5 May 2023 06:59:05 -0500 From: Vaishnav Achath <vaishnav.a@ti.com> To: <nm@ti.com>, <afd@ti.com>, <vigneshr@ti.com>, <kristo@kernel.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org> CC: <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <u-kumar1@ti.com>, <vaishnav.a@ti.com> Subject: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-mcu-wakeup: Update fss node and hbmc_mux Date: Fri, 5 May 2023 17:28:58 +0530 Message-ID: <20230505115858.7391-4-vaishnav.a@ti.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230505115858.7391-1-vaishnav.a@ti.com> References: <20230505115858.7391-1-vaishnav.a@ti.com> MIME-Version: 1.0 Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765055967980657225?= X-GMAIL-MSGID: =?utf-8?q?1765055967980657225?= |
Series |
arm64: dts: ti: k3-j7200: Fixes for various dtbs_checks warnings
|
|
Commit Message
Vaishnav Achath
May 5, 2023, 11:58 a.m. UTC
From: Nishanth Menon <nm@ti.com> fss node claims to be a syscon node, while it actually is a simple bus where ospi, hbmc peripherals are located and a mux for path select between OSPI and Hyperbus which can be modelled as a reg-mux. So model it accordingly and use reg-mux to describe the hbmc-mux. Also update the region size to the correct values as per the TRM. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> --- V1->V2: * Address feedback from Udit to limit the FSS register region size as per TRM. * Use reg-mux changes to simplify the hbmc-mux modelling. * Update commit message to reflect changes. Depends on: https://lore.kernel.org/all/20230424184810.29453-1-afd@ti.com/ arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
Comments
On 05/05/23 17:28, Vaishnav Achath wrote: > From: Nishanth Menon <nm@ti.com> > > fss node claims to be a syscon node, while it actually is a simple bus FSS > where ospi, hbmc peripherals are located and a mux for path select OSPI, HBMC > between OSPI and Hyperbus which can be modelled as a reg-mux. So model > it accordingly and use reg-mux to describe the hbmc-mux. Also update > the region size to the correct values as per the TRM. > > Signed-off-by: Nishanth Menon <nm@ti.com> > Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> > --- > > V1->V2: > * Address feedback from Udit to limit the FSS register region size as > per TRM. > * Use reg-mux changes to simplify the hbmc-mux modelling. > * Update commit message to reflect changes. > > Depends on: > https://lore.kernel.org/all/20230424184810.29453-1-afd@ti.com/ > > arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi > index b58a31371bf3..333564ca9c91 100644 > --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi > @@ -338,22 +338,23 @@ > status = "disabled"; > }; > > - fss: syscon@47000000 { > - compatible = "syscon", "simple-mfd"; > - reg = <0x00 0x47000000 0x00 0x100>; > + fss: bus@47000000 { > + compatible = "simple-bus"; > + reg = <0x00 0x47000000 0x0 0x7c>; ^^^^ 0x00 I know the registers only go up to 0x7c, but its convention to map entire region that is reserved for the IP irrespective of how many registers are actually valid (I see this across arm64 SoC Vendors). Eg as per TRM, Table 203 MCU Domain map: MCU_FSS0_CFG 0x0047000000 - 0x00470000FF (256B) > #address-cells = <2>; > #size-cells = <2>; > ranges; > > - hbmc_mux: hbmc-mux { > - compatible = "mmio-mux"; > + hbmc_mux: mux-controller@47000004 { > + compatible = "reg-mux"; > + reg = <0x00 0x47000004 0x00 0x2>; > #mux-control-cells = <1>; > mux-reg-masks = <0x4 0x2>; /* HBMC select */ > }; > > hbmc: hyperbus@47034000 { > compatible = "ti,am654-hbmc"; > - reg = <0x00 0x47034000 0x00 0x100>, > + reg = <0x00 0x47034000 0x00 0x0c>, Hmm, doesn't look correct? I see register addresses up to 0x47034048h in TRM? I prefer to map entire region reserved in the SoC memory map: MCU_FSS0_HPB_CTRL 0x0047034000 - 0x00470340FF (256B) > <0x05 0x00000000 0x01 0x0000000>; > power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>; > clocks = <&k3_clks 102 0>;
On 5/9/23 5:41 AM, Vignesh Raghavendra wrote: > > > On 05/05/23 17:28, Vaishnav Achath wrote: >> From: Nishanth Menon <nm@ti.com> >> >> fss node claims to be a syscon node, while it actually is a simple bus > > FSS > >> where ospi, hbmc peripherals are located and a mux for path select > > OSPI, HBMC > >> between OSPI and Hyperbus which can be modelled as a reg-mux. So model >> it accordingly and use reg-mux to describe the hbmc-mux. Also update >> the region size to the correct values as per the TRM. >> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> >> --- >> >> V1->V2: >> * Address feedback from Udit to limit the FSS register region size as >> per TRM. >> * Use reg-mux changes to simplify the hbmc-mux modelling. >> * Update commit message to reflect changes. >> >> Depends on: >> https://lore.kernel.org/all/20230424184810.29453-1-afd@ti.com/ >> >> arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 13 +++++++------ >> 1 file changed, 7 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi >> index b58a31371bf3..333564ca9c91 100644 >> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi >> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi >> @@ -338,22 +338,23 @@ >> status = "disabled"; >> }; >> >> - fss: syscon@47000000 { >> - compatible = "syscon", "simple-mfd"; >> - reg = <0x00 0x47000000 0x00 0x100>; >> + fss: bus@47000000 { >> + compatible = "simple-bus"; >> + reg = <0x00 0x47000000 0x0 0x7c>; > > ^^^^ 0x00 > > I know the registers only go up to 0x7c, but its convention to map > entire region that is reserved for the IP irrespective of how many > registers are actually valid (I see this across arm64 SoC Vendors). > Eg as per TRM, Table 203 MCU Domain map: > > MCU_FSS0_CFG 0x0047000000 - 0x00470000FF (256B) > > > > >> #address-cells = <2>; >> #size-cells = <2>; >> ranges; >> >> - hbmc_mux: hbmc-mux { >> - compatible = "mmio-mux"; >> + hbmc_mux: mux-controller@47000004 { >> + compatible = "reg-mux"; >> + reg = <0x00 0x47000004 0x00 0x2>; >> #mux-control-cells = <1>; >> mux-reg-masks = <0x4 0x2>; /* HBMC select */ >> }; >> >> hbmc: hyperbus@47034000 { >> compatible = "ti,am654-hbmc"; >> - reg = <0x00 0x47034000 0x00 0x100>, >> + reg = <0x00 0x47034000 0x00 0x0c>, > > Hmm, doesn't look correct? I see register addresses up to 0x47034048h in > TRM? > > I prefer to map entire region reserved in the SoC memory map: > MCU_FSS0_HPB_CTRL 0x0047034000 - 0x00470340FF (256B) > I do agree here 0x100 is more clean, but we do have to watch for the holes we have in memory right after some register spaces which cause SErrors on access.. Either way this reg change should have been its own patch, not squashed into this otherwise correct s/mmio-mux/reg-mux patch. Andrew > >> <0x05 0x00000000 0x01 0x0000000>; >> power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>; >> clocks = <&k3_clks 102 0>; >
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi index b58a31371bf3..333564ca9c91 100644 --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi @@ -338,22 +338,23 @@ status = "disabled"; }; - fss: syscon@47000000 { - compatible = "syscon", "simple-mfd"; - reg = <0x00 0x47000000 0x00 0x100>; + fss: bus@47000000 { + compatible = "simple-bus"; + reg = <0x00 0x47000000 0x0 0x7c>; #address-cells = <2>; #size-cells = <2>; ranges; - hbmc_mux: hbmc-mux { - compatible = "mmio-mux"; + hbmc_mux: mux-controller@47000004 { + compatible = "reg-mux"; + reg = <0x00 0x47000004 0x00 0x2>; #mux-control-cells = <1>; mux-reg-masks = <0x4 0x2>; /* HBMC select */ }; hbmc: hyperbus@47034000 { compatible = "ti,am654-hbmc"; - reg = <0x00 0x47034000 0x00 0x100>, + reg = <0x00 0x47034000 0x00 0x0c>, <0x05 0x00000000 0x01 0x0000000>; power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>; clocks = <&k3_clks 102 0>;