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 89A77C36010 for ; Fri, 4 Apr 2025 13:56:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=veAAjhN8B8C375cofq5bLFa8Mijl3Mmtk8CJoYwn80k=; b=1hC3U5nukWVw+Og0cPlP+8N5My cZqmsJJ2aK5MGLyYnn/zmyW4XGfU9ing28BYfzSMWPp2ZYKo2YmOIhug88UgjCTjcgX4r4ljlXxk+ 2P2ij1y9Nq2IbulK26TSNaxUUYo56lqXv65BmOsFP0Cnf5uVyjJJv0D0XaDoPAjVg2uidhChi7B/T NQtx4Ywpahij6w9Kv3aXHqATqHbusNnF9Pd9zsOL6dKjemHNMDUs6n7RhsjIkGZGpz0BPfvnWia48 11RO22mPIdZWU73MfHSzhJHMupBwBoU1ERljpOJ44dHwUbpjGnd1QCO6T7RDZHi97J8bt92j0CWRE +9v5mY7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0hWQ-0000000BuFP-40N7; Fri, 04 Apr 2025 13:55:50 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0hDR-0000000Bqi6-1GuA for linux-arm-kernel@lists.infradead.org; Fri, 04 Apr 2025 13:36:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2CD0744E74; Fri, 4 Apr 2025 13:36:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8456CC4CEE8; Fri, 4 Apr 2025 13:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743773772; bh=nB8hhdyLpxbnHmC76tdnlII8bmXVnl4tnHoovM2c5PY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DhepgBwwFIvXZHbUMKM6Z7vGdvaQmPijJDmhV19O+I1M0ZdFEu2fueSyoE8kTsVlq QB7na3fopG9hU3MLcBAsuBQ1yb5RDdQ6K2w0u2PTq+UWKGVwofVOaT+4OTS2Se0GwN K1SYCPhlHXaKToLzvai9weta93C65b4IOdxe+sd3xL/PpqgfTKvXttTFDX17BEqBjL WbiR/01P9QCvdCu6d1Sqgm8xbzqM6SFUAWzbLfm7pMvehEOMQlGTb/FCYuhiAfjrkS 3EbxVGnguxBB447dXDYSUflq0TIyRJ97nJ8y7ura9MScmqtCFS6YZ0n/x4IVNcE9C4 mi7/60ib4Jwtg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1u0hDO-002MP1-Hr; Fri, 04 Apr 2025 14:36:10 +0100 Date: Fri, 04 Apr 2025 14:36:12 +0100 Message-ID: <87y0wgxd4j.wl-maz@kernel.org> From: Marc Zyngier To: Christian Bruel Cc: , , , , , , , , , Subject: Re: [PATCH 2/3] irqchip/gic: Use 0x10000 offset to access GICC_DIR on STM32MP2 In-Reply-To: <1213dbfb-821a-4534-947b-acc4eac9da81@foss.st.com> References: <20250403122805.1574086-1-christian.bruel@foss.st.com> <20250403122805.1574086-3-christian.bruel@foss.st.com> <8734epyw17.wl-maz@kernel.org> <1213dbfb-821a-4534-947b-acc4eac9da81@foss.st.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: christian.bruel@foss.st.com, tglx@linutronix.de, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250404_063613_380351_D02D6007 X-CRM114-Status: GOOD ( 32.16 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 04 Apr 2025 13:15:05 +0100, Christian Bruel wrote: > > > > On 4/3/25 19:50, Marc Zyngier wrote: > > On Thu, 03 Apr 2025 13:28:04 +0100, > > Christian Bruel wrote: > >> > >> When GIC_4KNOT64K bit in the GIC configuration register is > >> 0 (64KB), address block is modified in such a way than only the > >> first 4KB of the GIC cpu interface are accessible with default > >> offsets. > >> With this bit mapping GICC_DIR register is accessible at > >> offset 0x10000 instead of 0x1000, thus remap accordingly > > > > And I'm pretty sure the whole of the GICC range is correctly > > accessible at offset 0xF000, giving you the full 8kB you need. That's > > because each page of the GIC is aliased over two 64kB blocks, as per > > the integration guidelines so that MMU isolation can be provided on a > > 64kB boundary. > > Thanks a lot for this explanation, indeed this works like a charm. > > > > > Funnily enough, all it takes is to adjust GICC region. You can either: > > > > - make it 128kB wide, and the driver will take care of it (details in > > gic_check_eoimode()). On one of my boxes that is similarly > > configured, I get: > > > > [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 > > [ 0.000000] GIC: Adjusting CPU interface base to 0x00000000780af000 > > [ 0.000000] Root IRQ handler: gic_handle_irq > > [ 0.000000] GIC: Using split EOI/Deactivate mode > > > > See below for what I expect to be the correct fix. > > - make it 8kB wide from offset 0xF000. > > I checked both and they work. I will go for the former to show real > 8kB size to be exposed in the DT. And there are a few other > platforms that use this alias I think 8kB the wrong option. The GIC *is* supposed to be integrated over 128kB on arm64 platforms (there was some documentation about that back in the days, but it has become impossible to search anything on ARM's stupidly broken website. My recollection is that it was bundled with the GICv2m "specification" (only half a page!). Furthermore, you are supposed to describe the HW. Not your interpretation of it. Correctly written SW targeting arm64 know about this anyway. > > Unless the ST HW folks have been even more creative, none of this > > overly complicated stuff should be necessary. Just describe the HW > > correctly. > > I was unable to find this information in the GIC-400 trm > (https://developer.arm.com/documentation/ddi0471/b/programmers-model/gic-400-register-map). Now > I also prefer to use GICC alias at > offset 0xf000 as suggested rather than the quirk solution Again, this isn't a quirk. It's the one true way for 64bit platforms that can use pages bigger than 4kB. That's the purpose of the 4Kn64K parameter in the integration, dropping bits [15:12] from the PA presented to the CPU interface. M. -- Jazz isn't dead. It just smells funny.