From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F0A8C77B7C for ; Wed, 10 May 2023 15:30:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237377AbjEJPaV (ORCPT ); Wed, 10 May 2023 11:30:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231941AbjEJPaT (ORCPT ); Wed, 10 May 2023 11:30:19 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 331D530D5; Wed, 10 May 2023 08:30:18 -0700 (PDT) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 34AFU9ft025437; Wed, 10 May 2023 10:30:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1683732609; bh=DzRXX0V8EZhaDFBcLK4Yf1y6yB+z6JFJVVMC+sc6RgE=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=lU2yp0OkVPSmg0087E2xrevo17EROtc46ogpaePyz2Y98SrmHPDvHK91xX0FU4cjv 6LcjZHFrw+PdWYueKXBnqBnN9Rh2vDO1Zp/Th275ZUx8KS9iFHi0gvmazY9rZYzjlP zCGZSSF8C5ZmgS1cipo8ztW4FMmKph9NdrRLTiog= Received: from DLEE107.ent.ti.com (dlee107.ent.ti.com [157.170.170.37]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 34AFU91c002952 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 10 May 2023 10:30:09 -0500 Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 10 May 2023 10:30:09 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE113.ent.ti.com (157.170.170.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, 10 May 2023 10:30:09 -0500 Received: from [10.250.221.249] (ileaxei01-snat.itg.ti.com [10.180.69.5]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 34AFU8Kc040535; Wed, 10 May 2023 10:30:08 -0500 Message-ID: Date: Wed, 10 May 2023 08:30:08 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-mcu-wakeup: Update fss node and hbmc_mux Content-Language: en-US To: Vignesh Raghavendra , Vaishnav Achath , , , , CC: , , , References: <20230505115858.7391-1-vaishnav.a@ti.com> <20230505115858.7391-4-vaishnav.a@ti.com> From: Andrew Davis In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/9/23 5:41 AM, Vignesh Raghavendra wrote: > > > On 05/05/23 17:28, Vaishnav Achath wrote: >> From: Nishanth Menon >> >> 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 >> Signed-off-by: Vaishnav Achath >> --- >> >> 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>; >