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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22490C433EF for ; Fri, 11 Feb 2022 23:57:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xl/3m51hY92iF1R4vcd5WM/KGpN4Zza9+ZJ4NjkkojA=; b=LWBAwt/KqmsuoX GbekAemIGap3spdsQu7ghHWqKx1LHUvZtrCAAR85pwGTIMEfFXD37aU4HUSbV66ho5yeJx+cNDT53 aw0DhNp0JMkmQBXLsXPlOUZJWtBBjID9cMZrl8EZD46Ueu+brLwHgg01jeBQTL4TY95UHhwZ3H0Kw 04SqaqWGUc2GhxHcVc1atGap/s7LTvSIkVv9PunMZOJ08B0vS/9MwM/lWXP8kSM7FwlnxOxx5oogn wxuCcYdYF6XGkXr82x9/EX3SFAKsx+oFSM/2+nNEj4jX758pBk4JFqha/R3XdxTy0iOi2XuZf87d3 XaTadUwPd7HZbzlAtlNQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIflC-0096i7-JY; Fri, 11 Feb 2022 23:55:30 +0000 Received: from lelv0142.ext.ti.com ([198.47.23.249]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIfl8-0096hi-Gl for linux-arm-kernel@lists.infradead.org; Fri, 11 Feb 2022 23:55:28 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 21BNtDX9100106; Fri, 11 Feb 2022 17:55:13 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1644623713; bh=1vHM54CwcHIN0I3vPq+6F3y9c45xrEOak2ZCfgkFXns=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ArVGPduCVXYbNZVR72h4nSVLYRdr6R13CzR6BaEjc10JNQyOCKWsateCyzJI7dF73 VCqfqdFr9d6kMltvGzx5lJi+5Y95mIdlcmf8Csf1Bod1zrSjPmGpjxTq0xFd7wMzpN gLveCS8kr76w0irvB+aPgBiT9P98zLQxK08d3iaw= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 21BNtDBq014636 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 11 Feb 2022 17:55:13 -0600 Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Fri, 11 Feb 2022 17:55:13 -0600 Received: from lelv0327.itg.ti.com (10.180.67.183) 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.2308.14 via Frontend Transport; Fri, 11 Feb 2022 17:55:13 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 21BNtDaZ016680; Fri, 11 Feb 2022 17:55:13 -0600 Date: Fri, 11 Feb 2022 17:55:13 -0600 From: Nishanth Menon To: Marc Zyngier CC: Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , Santosh Shilimkar , , , Subject: Re: [PATCH 4/5] arm64: dts: ti: Introduce base support for AM62x SoC Message-ID: <20220211235513.cplmvgfuwe3dhzbs@nearby> References: <20220208131827.1430086-1-vigneshr@ti.com> <20220208131827.1430086-5-vigneshr@ti.com> <20220210193459.nl6baranvmqs46bi@coastal> <87bkzdljt1.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87bkzdljt1.wl-maz@kernel.org> User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220211_155526_712432_4DE07C7B X-CRM114-Status: GOOD ( 34.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11:33-20220211, Marc Zyngier wrote: > On Thu, 10 Feb 2022 19:34:59 +0000, > Nishanth Menon wrote: > > > > On 19:10-20220209, Marc Zyngier wrote: > > [...] > > > > > > +&cbass_main { > > > > + gic500: interrupt-controller@1800000 { > > > > + compatible = "arm,gic-v3"; > > > > + #address-cells = <2>; > > > > + #size-cells = <2>; > > > > + ranges; > > > > + #interrupt-cells = <3>; > > > > + interrupt-controller; > > > > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ > > > > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */ > > > > > > Usual rant: you are missing the GICC, GICH and GICV regions > > > that are implemented by the CPU. Cortex-A53 implements them > > > (they are not optional), so please describe them. > > > > > > > > > -ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1]. > > And I'm not talking about the GIC, but of the CPU interface. The fact > that we describe both in the GIC binding doesn't mean they are > implemented by the same IP block (and the architecture is quite clear > about that). > > > Same thing is indicated by Generic Interrupt Controller Architecture > > Specification[2] See table 1-1 (page 23). > > > > I think you are expecting GICV3's backward compatibility mode (Table 1-2 > > in page 24), But in K3 architecture, are_option meant for backward > > compatibility is set to true (aka no backward compatibility). I think > > this did popup sometime back as well (first k3 SoC)[3]. I think the more > > clearer description is available in [4]. > > No, this description is for the architecture as a whole. ARE being > disabled *int the GIC* doesn't mean it is disabled overall, and the > CPU is free to implement the CPU interface by any mean it wants as > long as it communicates with the GIC using the Stream Protocol. > Cortex-A32, A34, 35, A53, A57, A72 and A73 all implement both the > sysreg and MMIO CPU interfaces. Later ARM CPUs don't. Both can work > with GIC500. > > > I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500 > > is used is not accurate. Please correct me if I am mistaken. > > GIC500 is not involved at all, and A53 always implements both the > system register and MMIO interfaces. See the A53 TRM, chapter 9. The > only way to disable this interface is to assert GICCDISABLE, which > disables the whole of the CPU interface. Given that you have a (more > or less) functional system, it probably isn't the case. > > See Table 9-1, which tells you where these registers are as an offset > from PERIPHBASE. Dumping these registers should show you that they are > indeed implemented and not solely a figment of my own imagination. Thanks for explaining.. I don't see this is working in practise.. Let me know if I am making a mistake in my interpretation. Quote from our internal integration spec (yep it leaves it to ARM cluster's use): "" Note: GIC periphery base tieoff to ARM corepacs for GIC v2 compatibility requires a dedicated unallocated space to be passed as input to ARM corepac. The CC internal region 0F00_0000-0x0F03_FFFF is assigned as GIC periphery base tieoff to the corepac. When GIC-500 is in v3 mode, and A72 with GICCDISABLE=0 and PERIPHBASE set: - the CPU interface registers are accessed via ICC* system register. - the GICC* regions (PERIPHBASE - PERIPHBASE+0x3FFFF) are reserved and access will be Read as Zero / Write Ignored. So any writes/reads to this region would be trapped by ARM corepacs. "" Anyways, Here is my report. I checked across all K3 devices (a72 and a53) AM65x: PERIPH_BASE = 0x6f000000 (a53) j721e: PERIPH_BASE = 0x6f000000 (a72) J7200: PERIPH_BASE = 0x6f000000 (a72) j721s2: PERIPH_BASE = 0x6f000000 (a72) AM64: PERIPH_BASE = 0x100000000 (a53) AM62: PERIPH_BASE = 0x100000000 (a53) (side note: am64/62 needed the 0x6f.. address space for PCIe stuff.. but the address chosen has nothing in SoC fabric) Tested at u-boot shell prompt (running at EL2): If I understood the expectation correctly..I should be seeing offsets off [1]. Taking 'CPU Interface'/GICC as an example, [2] should be the registers I should be seeing. aka, at offset 0xfc from PERIPHBASE, i should see 0x0034443B. Note: on K3 devices (in the 32bit address space), as in the description above, we have a null endpoint handler in the bus fabric that responds with 0x0 for read requests for invalid/reserved addresses. What I see is 0x0 (and not IIDR) in all the address ranges - which matches ARM sending that region requests straight down to SoC level and SoC returning "ignore".. On AM62, I attached Lauterbach. and tried to look at the addresses: [3] from cpu view and from bus view. I also checked from kernel side with devmem to make sure to dump while kernel GICV3 is active.. I see the same thing as well.. Is there something TFA or someone has to do to "enable" this? I tried re-reading porting-guide.rst yet again to make sure we have'nt missed anything. [1] https://developer.arm.com/documentation/ddi0500/j/Generic-Interrupt-Controller-CPU-Interface/GIC-programmers-model/Memory-map?lang=en [2] https://developer.arm.com/documentation/ddi0500/j/Generic-Interrupt-Controller-CPU-Interface/GIC-programmers-model/CPU-interface-register-summary [3] https://pasteboard.co/3O44PAwLeAXz.png -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel