Message ID | 20230211031821.976408-3-cristian.ciocaltea@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1308752wrn; Fri, 10 Feb 2023 19:19:44 -0800 (PST) X-Google-Smtp-Source: AK7set9ZkjsfcXHzc4Lku3R3Zk1opUJUdA4jCNZGXtTMisL2V0HPmOZ7Mxi2eWyfEqvg5BVqgPRC X-Received: by 2002:a17:906:3487:b0:870:d15a:c2dc with SMTP id g7-20020a170906348700b00870d15ac2dcmr15645270ejb.74.1676085583895; Fri, 10 Feb 2023 19:19:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676085583; cv=none; d=google.com; s=arc-20160816; b=r1Zi+Z7woJWWSHb8Z0D9RcC0Ds9nt++VNT72xahekeLyk+WDWKqAMfovCjNRXVpHzX Up1OcPjmtBaeEblLKJUTmx4LD1rnQt8qyFREbr+yDvSMt+YKi132zQSEDCnB85vJa3Iw Ofw3eCO8Yml5FcKFsF4TNKymzG/h3vrBJlNgn2Ge9vv7KGUwRMiYWehyzYn6Q7nkl1mo 4M0fErrWlC2926XF2xJmICFJwX/NRtzAQpm8+S5fAvBO29M8t6ocf2neJzIrJOW4QwrX 66L2l37pU5RRzJ15PPiFOV1l12PSe4SL5kCw71xnd+hfCCsVlLsJ4JlaEnffTkBxEe8/ L9Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=gzCKDuGGqRG42TDsjED78dN9dgfr5qgZyyeLcksYfD8=; b=uRI1JGxLyQUV5P4j6AshXr64LhC7ZOZ8F+dgPC2I9Dc4iXW2tTroP9SqkufhWcHJ7p B/rTdDJeXGwLTrT9RyyZdyiwMsqoVaO32kzQB4UddCQH1Gm8V7ca4LJeLz5S65Q2AvOi nOStLgdIwGxzPbFla87NKQ0FxZ0HE9hoZQU2Na1VrZt2GmZyLHLGX4wvWaGuIv0shgwK OOBfHS9WbQWV9pzjEURKGNBztE8/klNLPEy6Ys4iGeAee5TfHjHCdMMGBRWJaWPAMcGB DU1CWbaURaLw+6hdsnyc+ea19OOL2hssLo4pSMNnih3vfavufxO3LLtutq85qbuNYRJj i8pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=GHzfI5rd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s20-20020a170906221400b0088965b1b479si7039773ejs.394.2023.02.10.19.19.20; Fri, 10 Feb 2023 19:19:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=GHzfI5rd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229696AbjBKDTB (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Fri, 10 Feb 2023 22:19:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229698AbjBKDSk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Feb 2023 22:18:40 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16A0323113; Fri, 10 Feb 2023 19:18:39 -0800 (PST) Received: from localhost (unknown [86.120.32.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by madras.collabora.co.uk (Postfix) with ESMTPSA id 5630F6602114; Sat, 11 Feb 2023 03:18:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1676085518; bh=Qz2BvAFfeR2pDH8idXft8j3/6B8ejfNa6vswzgvImNI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GHzfI5rdTu9/UZQWhAxLUwT9InbdtWjYgD9KO+/XqXr3fY4lXHlyWhChStvUQR01m xRLs4k3bnjFo8PWBFh51vKusUx9xj/uvL1FNUKDZXF6f9TCCX2LQ3ULqnJT1TZ0Tyo Rz2D4/dDd9ddU/gHRWbfF5cH8VA38de5O2pTkRwv9EqmpIRkh9frNe8X/026R1N8V4 Tq9vVpS9hVB1I6Osa42muP8FW4Evlh11PlZ2njTaino7d+ojKQlCzS8vR7PsyWDO92 Wss6o1LNqXIDWpvrF/z0PG5pbHmgejn/aF+Ufr5DMyRRDfMUSQF2ud2JT48tfS+Qgu v1uC6CLBuhwsQ== From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> To: Lee Jones <lee@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Emil Renner Berthing <kernel@esmil.dk>, Conor Dooley <conor@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu>, Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Richard Cochran <richardcochran@gmail.com>, Sagar Kadam <sagar.kadam@sifive.com>, Yanhong Wang <yanhong.wang@starfivetech.com> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, kernel@collabora.com Subject: [PATCH 02/12] dt-bindings: riscv: sifive-ccache: Add 'uncached-offset' property Date: Sat, 11 Feb 2023 05:18:11 +0200 Message-Id: <20230211031821.976408-3-cristian.ciocaltea@collabora.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230211031821.976408-1-cristian.ciocaltea@collabora.com> References: <20230211031821.976408-1-cristian.ciocaltea@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757503117499688868?= X-GMAIL-MSGID: =?utf-8?q?1757503117499688868?= |
Series |
Enable networking support for StarFive JH7100 SoC
|
|
Commit Message
Cristian Ciocaltea
Feb. 11, 2023, 3:18 a.m. UTC
Add the 'uncached-offset' property to be used for specifying the
uncached memory offset required for handling non-coherent DMA
transactions.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml | 5 +++++
1 file changed, 5 insertions(+)
Comments
On 11/02/2023 04:18, Cristian Ciocaltea wrote: > Add the 'uncached-offset' property to be used for specifying the > uncached memory offset required for handling non-coherent DMA > transactions. Only one offset can be non-coherent? If this is for DMA, why dma-noncoherent cannot be used? Best regards, Krzysztof
On 2/13/23 11:23, Krzysztof Kozlowski wrote: > On 11/02/2023 04:18, Cristian Ciocaltea wrote: >> Add the 'uncached-offset' property to be used for specifying the >> uncached memory offset required for handling non-coherent DMA >> transactions. > > Only one offset can be non-coherent? If this is for DMA, why > dma-noncoherent cannot be used? As Conor already mentioned in [1], the handling of non-coherent DMA on RISC-V is currently being worked on, so I expect this patch will be dropped. [1] https://lore.kernel.org/lkml/Y+d36nz0xdfXmDI1@spud/ Thanks for reviewing, Cristian > > Best regards, > Krzysztof >
Hey all, On Sat, Feb 11, 2023 at 05:18:11AM +0200, Cristian Ciocaltea wrote: > Add the 'uncached-offset' property to be used for specifying the > uncached memory offset required for handling non-coherent DMA > transactions. > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> > --- > Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml > index 2b864b2f12c9..60cd87a2810a 100644 > --- a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml > +++ b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml > @@ -82,6 +82,11 @@ properties: > > next-level-cache: true > > + uncached-offset: > + $ref: /schemas/types.yaml#/definitions/uint64 > + description: | > + Uncached memory offset for handling non-coherent DMA transactions. Firstly, this pretty tied to the StarFive stuff, where there is only one "bank" of memory that neatly maps to one bank of non-cached memory. On PolarFire SoC, where we would also like to make use of non-coherent DMA for some transfers using the FPGA fabric, things are a bit more complex. Instead of a region & a non-cached alias, we have 2 regions and 2 non-cached regions. These regions lie at 0x8000_0000 & 0x10_0000_0000 and the non-cached regions are at 0xc000_0000 & 0x14_0000_0000. As you can tell, one fixed offset isn't going to work there! The other bit of a problem is that there is no fixed concept of aliases, as seems to be the case on the jh7100. Instead, where the regions "point" to in physical DDR is something that is configurable at runtime. Practically speaking, it is set by firmware very early on in boot & is fixed from there out, but will vary between boards and FPGA fabric configuration. Effectively that means that from the PoV of a Devicetree it is constant, but a good bit of flexibility is going to be needed. What we have been doing on PolarFire SoC (although mostly internally at this point) is, rather than creating a property like uncached-offset, we instead are using the dma-ranges properties to induce the same affect. In an example configuration with memory at: reg = <0x0 0x80000000 0x0 0x4000000>; reg = <0x0 0x8a000000 0x0 0x8000000>; reg = <0x0 0xc4000000 0x0 0x6000000>; reg = <0x10 0x22000000 0x0 0x5e000000>; reg = <0x14 0x12000000 0x0 0x10000000>; a reserved memory section then covering the non-cached region at 0x14_0000_0000: dma_non_cached_high: non-cached-high-buffer { compatible = "shared-dma-pool"; size = <0x0 0x10000000>; no-map; linux,dma-default; alloc-ranges = <0x14 0x12000000 0x0 0x10000000>; }; and dma-ranges: dma-ranges = <0x14 0x0 0x0 0x80000000 0x0 0x4000000>, <0x14 0x4000000 0x0 0xc4000000 0x0 0x6000000>, <0x14 0xa000000 0x0 0x8a000000 0x0 0x8000000>, In this configuration, 0x8000_0000, 0x10_0000_0000, 0xc000_0000 & 0x14_0000_0000 are all aliases of the same address. With this setup, we're able to do non-coherent DMA to the FPGA fabric, to the PCI for example. The DTS does grow a bit of complexity, with reserved memory regions and dma-ranges - but at least they're standard properties! Emil, if you want to take a look at that it is here: https://github.com/linux4microchip/linux linux-5.15-mchp I think I said to you before that it was based on one of Atish's early approaches, the one from the 5.15 development cycle IIRC since we're using that LTS. Obviously it'll need changes to be upstreamable so we're not wedded to this approach. For instance, it's being controlled by a compile time option at the moment, so that clearly needs to become runtime for upstream (and realistically needs to be one in our vendor tree too...) I'll try to hack that approach into the visionfive v1 soonTM and see how it goes, but it'll not be this side of March before I have time to do that. Cheers, Conor.
diff --git a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml index 2b864b2f12c9..60cd87a2810a 100644 --- a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml @@ -82,6 +82,11 @@ properties: next-level-cache: true + uncached-offset: + $ref: /schemas/types.yaml#/definitions/uint64 + description: | + Uncached memory offset for handling non-coherent DMA transactions. + memory-region: maxItems: 1 description: |