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 9BFF9C04FDE for ; Fri, 9 Dec 2022 11:10:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229876AbiLILKm (ORCPT ); Fri, 9 Dec 2022 06:10:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbiLILKj (ORCPT ); Fri, 9 Dec 2022 06:10:39 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71EC55CD0F for ; Fri, 9 Dec 2022 03:10:38 -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 2A7E5B827DF for ; Fri, 9 Dec 2022 11:10:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3391C433F1; Fri, 9 Dec 2022 11:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670584235; bh=z1OsDMJijOCYrhgJGhu5dQBX348sBitwoOZBuhZ/5TU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VHa1/Sl8BbLlQPF2KpMrX+1NkqZHsoZMdB3zqd1+4kSnYI4dhElX+eOl5V0r4MRLN v8Pax9tTIw693gXh6aPLcFaXEeNfHinGmSU7TXOl7ZKIrSxHpZ8NMpYGg276qVtRD1 UUuKh+kORu631xV/ap375aIbhCyCoefyozHNXG3z88RULplhEQNPtUnZU5YSWfUiGi xPiDLIzKXdMUCmhefGeDt6AHemAcYvcpWeubQDt9QbVeRUkfVfmRv5kHdgt36mlkIO Q1J5AJ8ky3JciRdlTaTl9rCWh7PHUb3Tss0pLY8kO0X8rIRiVgtkzuYB2BaDoxRRY7 LtAdY3TnJJILg== 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 1p3bGy-00BZVV-Ud; Fri, 09 Dec 2022 11:10:33 +0000 Date: Fri, 09 Dec 2022 11:10:32 +0000 Message-ID: <86h6y4rfx3.wl-maz@kernel.org> From: Marc Zyngier To: Harry Song Cc: 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> 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/27.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: jundongsong1@gmail.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 Thu, 08 Dec 2022 02:28:29 +0000, Harry Song wrote: > > On Wed, Dec 7, 2022 at 11:19 PM Marc Zyngier wrote: > > > > On Wed, 07 Dec 2022 13:52:23 +0000, > > Harry Song wrote: > > > > > > I know this is a very wrong patch, but my platform > > > has an abnormal ITS problem caused by data consistency: > > > My chip does not support Cache Coherent Interconnect (CCI). > > > > That doesn't mean much. Nothing mandates to have a CCI, and plenty of > > systems have other ways to maintain coherency. > > > > > By default, ITS driver is the inner memory attribute. > > > gits_write_cbaser() is used to write the inner memory > > > attribute. But hw doesn't return the hardware's non-shareable > > > property,so I don't think reading GITS_CBASER and GICR_PROPBASER > > > here will get the real property of the current hardware: inner > > > or outer shareable is not supported, so I would like to know > > > whether ITS driver cannot be used on chips without CCI, or > > > what method can be used to use ITS driver on chips without CCI? > > > > It's not about CCI or not CCI. It is about which shareability domain > > your ITS is in. > > > > And it doesn't only affect the ITS. It also affects the > > redistributors, and anything that accesses memory. > > > > Yes, my current chip is Rockchip platform (rk3588), so is it because the chip > is not designed as a proper shared domain for ITS, so the exception of > ITS is caused? This Rockchip platforms have two problems: - The GIC doesn't report whether is is in a shareable domain or not - The GIC relies on memory allocation being under 4GB In both cases, this needs to be quirked. Last time the subject came up, Rockchip didn't want to do this properly, so the ITS is unsupported on these systems until someone writes a decent patch. > > > The current patch is designed to make ITS think that the current > > > chip has no inner or outer memory properties, and then use > > > its by flushing dcache. > > > > > > This is the log for bug reports without patches: > > > > > > [ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000003460000 > > > [ 0.000000] ITS [mem 0x03440000-0x0345ffff] > > > [ 0.000000] ITS@0x0000000003440000: allocated 8192 Devices @41850000 (indirect, esz 8, psz 64K, shr 0) > > > [ 0.000000] ITS@0x0000000003440000: allocated 32768 Interrupt Collections @41860000 (flat, esz 2, psz 64K, shr 0) > > > [ 0.000000] GICv3: using LPI property table @0x0000000041870000 > > > [ 0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000041880000 > > > [ 0.000000] ITS queue timeout (64 1) > > > [ 0.000000] ITS cmd its_build_mapc_cmd failed > > > [ 0.000000] ITS queue timeout (128 1) > > > [ 0.000000] ITS cmd its_build_invall_cmd failed > > > > Ah, this suspiciously looks like a Rockchip machine... > > > > > > > > Signed-off-by: Harry Song > > > --- > > > > > > I am very sorry to bother you. This problem has been bothering me > > > for several weeks. I am looking forward to your reply. > > > > If you have such issue, this needs to be handled as per-platform > > quirk. I'm not putting such generic hacks in the driver. > > > > M. > > > > -- > > Without deviation from the norm, progress is not possible. > > Are there currently other chip platforms that have this problem, and then ITS > is already compatible with the problem? No. Only the RK35xx systems are affected. Other systems with the exact same GIC600 are working just fine. > Please tell me how to submit hacks patch for rk3588 platform? If > the hacks patch cannot be submitted, please tell me whether it > requires the next generation chip to have any design requirements > for ITS? A patch *can* be submitted. What I want to see is described as part of https://lore.kernel.org/lkml/878s5i2qyw.wl-maz@kernel.org/ If you write such a patch, I'll gladly merge it. > Design ITS and CPU to be the same inner memory property? No, you need to integrate it so that the attribute are *discoverable*, and all the memory reachable from the GIC. M. -- Without deviation from the norm, progress is not possible.