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 86A61C83F33 for ; Tue, 5 Sep 2023 12:23:30 +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=4K5zL5d9ae/P0YTjKvL8iTXjHKnuMVhDXAf8LPIQXpU=; b=JK56V9HdR2x3/b fKCizvBTLpoxsaWfyb/UMWLm9RYuNAULsWsPkQy05yUb9kELQyonWrjVhkdyMeJIhsK7QCdS7Tnu+ AxdXfHCB0QRT96WOiEkQI4vSvWVxQOwRy8GECGDrTrvN/s8vKSPz5TWuqhxeWxz2RPMsTbiWlv3OP AcQs3paPt9xPbAvqJpiRndVz5uuNXvWhFUCP/VTU6vEGcsm+0udV7ezyIUXH97KG0Gm9kPeNVQKg2 2Th9Bjnkh9Z+5EBOxsy5hRMNro64Q0HU4QFil+z8mzB6cOiEavZI7iSDwDwyy9Eralg8FonBoxATG FI8hUIVKeaIeC5Q+2U4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qdV56-005zvm-2A; Tue, 05 Sep 2023 12:22:56 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qdV51-005zuz-0s for linux-arm-kernel@lists.infradead.org; Tue, 05 Sep 2023 12:22:55 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 279A4CE10E7; Tue, 5 Sep 2023 12:22:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB9ADC433C7; Tue, 5 Sep 2023 12:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693916567; bh=SoNW2HIc86v/ID8fpk0tLx5Hbits5RDiuL3Og0Y11Fs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M91M2qjYeHxPHsS+sEAzDLTaa25Cp66UkgL/p5L0b9ufh1drfgHSzZ6FQ/1DZr+ey QbnrPvUeEWQSguEWNg34rKqKqxxwyhvXBoaqCpTG3gCIswqLR5FBuVcoWljYaYanH3 E7TNBDkAUXzzO8UrTLUyfPtOhGGLU5LF7iwD68oQJRHKMkB1cnYpdmcgHLsTFsFPWb +9e28y1UXEINMQpTxiEiRvky+cuwmElTZiLARmV85SmDdB6MME8Ng3y1U0sIsAu63E y1zb0CAGseuP4pD8O0h8Fmce62dW+rcL3ps/qri/EYYyjZnycN9wgPQIGFtaKRzBL1 zg2uEle1EpS4g== Date: Tue, 5 Sep 2023 14:22:42 +0200 From: Lorenzo Pieralisi To: Robin Murphy Cc: linux-kernel@vger.kernel.org, Rob Herring , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Mark Rutland , Rob Herring , Fang Xiang , Marc Zyngier Subject: Re: [PATCH 1/2] dt-bindings: interrupt-controller: arm,gic-v3: Add dma-noncoherent property Message-ID: References: <20230905104721.52199-1-lpieralisi@kernel.org> <20230905104721.52199-2-lpieralisi@kernel.org> <932355b4-7d43-a465-a2da-8dded8e2d069@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <932355b4-7d43-a465-a2da-8dded8e2d069@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230905_052254_164965_203A49D3 X-CRM114-Status: GOOD ( 32.20 ) 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 Tue, Sep 05, 2023 at 12:17:51PM +0100, Robin Murphy wrote: > On 05/09/2023 11:47 am, Lorenzo Pieralisi wrote: > > The GIC v3 specifications allow redistributors and ITSes interconnect > > ports used to access memory to be wired up in a way that makes the > > respective initiators/memory observers non-coherent. > > > > Add the standard dma-noncoherent property to the GICv3 bindings to > > allow firmware to describe the redistributors/ITSes components and > > interconnect ports behaviour in system designs where the redistributors > > and ITSes are not coherent with the CPU. > > > > Signed-off-by: Lorenzo Pieralisi > > Cc: Rob Herring > > --- > > .../bindings/interrupt-controller/arm,gic-v3.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > > index 39e64c7f6360..0a81ae4519a6 100644 > > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml > > @@ -106,6 +106,10 @@ properties: > > $ref: /schemas/types.yaml#/definitions/uint32 > > maximum: 4096 > > + dma-noncoherent: > > + description: | > > + Present if the GIC redistributors are not cache coherent with the CPU. > > I wonder if it's worth being a bit more specific here, e.g. "if the GIC > {redistributors,ITS} permit programming cacheable inner-shareable memory > attributes, but are connected to a non-coherent downstream interconnect." In my opinion it is and I wanted to elaborate on what I wrote but then I thought that this is a standard DT property, I wasn't sure whether we really need to explain what it is there for. We are using the property to plug a hole so I agree with you, we should be as clear as possible in the property definition but I will rely on Rob/Marc's opinion, I don't know what's the DT policy for this. > That might help clarify why the negative property, which could seem a bit > backwards at first glance, and that it's not so important in the cases where > the GIC itself is fundamentally non-coherent anyway (which *is* > software-discoverable). Is it ? Again, see above, are we defining "dma-noncoherent" to fix a bug or to fix the specs ? The shareability bits are writeable and even a fundamentally non-coherent GIC design could allow writing them, AFAIU. I would avoid putting ourselves into a corner where we can't use this property because the binding itself is too strict on what it is solving. > Otherwise, this is the same approach that I like and have previously lobbied > for, so obviously I approve :) > > (plus I do think it's the right shape to be able to slot an equivalent field > into ACPI MADT entries without *too* much bother) We are in agreement, let's see what others think. Thanks, Lorenzo > > Thanks, > Robin. > > > + > > msi-controller: > > description: > > Only present if the Message Based Interrupt functionality is > > @@ -193,6 +197,10 @@ patternProperties: > > compatible: > > const: arm,gic-v3-its > > + dma-noncoherent: > > + description: | > > + Present if the GIC ITS is not cache coherent with the CPU. > > + > > msi-controller: true > > "#msi-cells": > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel