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 9328BC636D4 for ; Mon, 13 Feb 2023 08:35:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230036AbjBMIfe (ORCPT ); Mon, 13 Feb 2023 03:35:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229902AbjBMIfa (ORCPT ); Mon, 13 Feb 2023 03:35:30 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B61C9A25D for ; Mon, 13 Feb 2023 00:35:29 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 708BBB80E65 for ; Mon, 13 Feb 2023 08:35:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32A5DC433D2; Mon, 13 Feb 2023 08:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676277327; bh=7P1js0XW8d28XSm8A7ZyRMA5jXBPNKrzJ/lvhmEmNgI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=R3hSglsy04v/rF/3O8oOlf65f4F8A0cLbQ/aE62YahK64iXVoKoJnwsiQnOiGpILt 7LVWfsPAtpQGe0OekSeTkgrcNtEEZLK/dua9I/kregG++z4rt9HcpqD4mQr7c4NtVJ lYuZAh5cqyrPgotqSowiG2GbWjLo591M2vIhHwIis0uas6qHvrAM13n5gfFYLoIxBv Hvk0nQesG3qfWYEDEgbBaCePI/loDegAS5YRAfWCzWBShCs7vBml+kGZJs8+CwOAdF com6xYvlxLHzgBQIl6DuKDOjsMJobC9p29L5TSPRTlWhBRI4aNSGZWPoiCztWo2Ox4 7h8yB6CeUfoww== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1pRUJ2-009tTX-TK; Mon, 13 Feb 2023 08:35:25 +0000 Date: Mon, 13 Feb 2023 08:35:24 +0000 Message-ID: <86357ayncj.wl-maz@kernel.org> From: Marc Zyngier To: Harry Song Cc: Sebastian Reichel , tglx@linutronix.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip/gic-v3-its: remove the shareability of ITS In-Reply-To: References: <20221207135223.3938-1-jundongsong1@gmail.com> <86a63zkzru.wl-maz@kernel.org> <20221208165820.5maej4we3mfdeprm@mercury.elektranox.org> <86fsdorfs9.wl-maz@kernel.org> 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/28.2 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jundongsong1@gmail.com, sebastian.reichel@collabora.com, tglx@linutronix.de, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Feb 2023 07:30:08 +0000, Harry Song wrote: >=20 > On Fri, Dec 9, 2022 at 9:37 PM Harry Song wrote: > > > > Thank you again. > > > > Harry > > > > On Fri, Dec 9, 2022 at 7:13 PM Marc Zyngier wrote: > > > > > > On Fri, 09 Dec 2022 03:34:21 +0000, > > > Harry Song wrote: > > > > > > > > Thank you for your reply. I know these two links. > > > > My email is to ask about the root cause of this bug. > > > > > > > > I would like to know whether the driver design of ITS requires that > > > > the CPU and ITS must be in a shared domain. Such as using CCI in > > > > chips; > > > > > > This problem has nothing to do with CCI or coherency. It has to do > > > with how the GIC is plugged in the interconnect and what attributes it > > > advertises. >=20 > This problem has nothing to do with CCI or coherency ?? > > Now , I have a question about this sentence=EF=BC=9A > If CCI is not used, how does the hardware realize the interconnection > between GIC-600 and cache? > If CCI is not used, our hardware colleagues said that the internal ITS > of the GIC-600 sends out operations with cache attributes (Inner/Outer > Shareable), > and there is no way to be captured by the cache and directly enter the > DDR. How does arm realize the interconnection between GIC-600 and > cache without CCI? This is becoming tedious. Why do you need things to be cacheable/shareable? The HW doesn't need it, and the SW doesn't need it either. All that SW needs is to be told *how* the HW behaves, and it relies on the GIC to tell it by not accepting configurations it cannot support. That's all. This is all described in the thread I pointed you to last year. If your HW is accepting configurations it cannot deal with, then it is a bug. You can work around it (again see the thread I pointed you to), or you can continue to moan about it. But I'm not interested in arguing further about this. Also, for ARM integration problems, please contact the ARM technical support. I'm here for Linux, and nothing else. M. --=20 Without deviation from the norm, progress is not possible.