Message ID | 20230412110900.69738-1-prabhakar.mahadev-lad.rj@bp.renesas.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp239596vqo; Wed, 12 Apr 2023 04:11:51 -0700 (PDT) X-Google-Smtp-Source: AKy350aa4PXlH5f2FfyO+ihXKHfQVDI7ZypSyYFOZ7iEA18oKyni03xoB0Te4kyrgeJ+/0dpkev8 X-Received: by 2002:a05:6a20:4c84:b0:d6:d41e:87ee with SMTP id fq4-20020a056a204c8400b000d6d41e87eemr2525363pzb.12.1681297911549; Wed, 12 Apr 2023 04:11:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681297911; cv=none; d=google.com; s=arc-20160816; b=sA9KEUOJueIF96nLgGB817rAsI2MtVonykuvStFv77CiYLD8FjxpkkNoYlzrmHQ/45 YjG/yMyjknLJXAmGDAj5hTCuiXXqIayD64poLrgXXQAmieJaabs2PbQSQz/ibff9AVbC t2xz1Ttk0Z8OYcoKPU3XkaNjzcAuzSRqs7K4zDzIeGOktUqORSm8B5jdbOOLHCSz776K mGAgq/U32d6MgaSSqkuE2h/cCCG2hM38/iCxsTMUpTHD4UupuA8J9tl+K1QB6c16i4gQ rZr9hW8m24KEkAkGVvfSwt0P+PKYDbpoS3MEfIoDdwdbl3bEJu05bwAmu3pnVBEa0eT4 sGuA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=tiY5HH5pvk7NfR3NaORSyudCIOkd+3EzmyX8mORwPrY=; b=XAlJgsIE6RhhOm8n/cydwDpSEEKAbaMRDJpJsSzTfmFobTjjxGNgLSoog0tXehCVdj j+t2UF1O/I+JdFmklj50cSQA42qvG/I5D/fZB8/NTPUK5lcZwJpSSvmVdLx8Ifa3+Nca Q6XfPihHTkG18e/xvkoZHW7N0vPwmDJpR9fU2Ob+qt4S8+WXuuzSGWCdAjSWECqV7SHI PEK3ZjQTNUDYguw8Axvh4F+PJe4qjLO5cgF4c+6mr1ra4H4uivLaKrFsW8zWPGxWhuII n4YRCWMjfeWrqChkmGM0MlqadoEX3Xdo1B2aoeQy3CPjgdkBqTdbqthWYQwtQ/Efl/x+ 7CFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=qbXbQTAt; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020a656944000000b00502ed95c83bsi10960894pgq.362.2023.04.12.04.11.39; Wed, 12 Apr 2023 04:11:51 -0700 (PDT) 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=@gmail.com header.s=20221208 header.b=qbXbQTAt; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229876AbjDLLJ3 (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Wed, 12 Apr 2023 07:09:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbjDLLJ0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 12 Apr 2023 07:09:26 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F63DB7; Wed, 12 Apr 2023 04:09:25 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id he13so11283330wmb.2; Wed, 12 Apr 2023 04:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681297763; x=1683889763; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=tiY5HH5pvk7NfR3NaORSyudCIOkd+3EzmyX8mORwPrY=; b=qbXbQTAtHcQtR34PMT2Nny68+mNZ/uQF0AGiRCoPc9bS8vfdbkn8+n/pgOjolVQjTz 4jJu2LtX2PyaoFctvlMcr2UAyfunREFRrDamfyN1OZyKdB5NgF0tovr4xGsNyGn+TQf9 NP0TQmbhGIHXrDeXfLuYKOqNgrAC7yCgKgQXsJjXR+v29DEaN6fJiTLA4QTmSaF7HTtG cmdAyxbLdP4WfjADy2f940OnSQB+325L+t1K9moDIBKB8AmszoP2wAHav6zPFBVJ0ISz W6QuUNCSv4taWj07R7pOfkIkhWa7tQXks7r3xZM8WzpUwkLQR53dAaNmYdDW5b3bnrx6 tnnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681297763; x=1683889763; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tiY5HH5pvk7NfR3NaORSyudCIOkd+3EzmyX8mORwPrY=; b=BJLFsGd53XzTLvCbLOTB0HNCOl0PcBdc1dTDca0+3bu9CFG2FltyZnAxxOqcyj7T73 ATuG4MB9nIcCpiqX4AUwySpS809aTCxUeG2zvdgNnD69jHxajFTNTjJsuZAHCJtnO2sp aGf/n5UCkSotGSr3yGFYcP/96WJzrYHpO0B/zEH+poVamuO0P32ONsTf4JHiAclBpjuC +hX09S9cpjeqldcQW5N/xrBOIqN7qItD2M1/Dl1X+LphXn27J0eoitzcEGbQpWi2vX7U uYDdmjCHEcJdDg5rSaoMwttZgiX9A93K2LPFhEzYQmT/w588nrZtVdb2Hbw3NuHFMjX9 L1Hg== X-Gm-Message-State: AAQBX9dC8TDRjSB9vNbujXA6amXhxri2B2HcwoyHeueLNtKyKkpcvb1V bvIGy6G8EEqlk/Mt3PDiklc= X-Received: by 2002:a1c:7410:0:b0:3ea:ed4d:38f6 with SMTP id p16-20020a1c7410000000b003eaed4d38f6mr11751696wmc.4.1681297763280; Wed, 12 Apr 2023 04:09:23 -0700 (PDT) Received: from prasmi.home ([2a00:23c8:2501:c701:783d:9280:20c4:db22]) by smtp.gmail.com with ESMTPSA id l13-20020a5d668d000000b002e61e002943sm16863582wru.116.2023.04.12.04.09.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Apr 2023 04:09:22 -0700 (PDT) From: Prabhakar <prabhakar.csengg@gmail.com> X-Google-Original-From: Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> To: Arnd Bergmann <arnd@arndb.de>, Conor Dooley <conor.dooley@microchip.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Heiko Stuebner <heiko@sntech.de>, Guo Ren <guoren@kernel.org>, Andrew Jones <ajones@ventanamicro.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Samuel Holland <samuel@sholland.org>, linux-riscv@lists.infradead.org Cc: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Prabhakar <prabhakar.csengg@gmail.com>, Biju Das <biju.das.jz@bp.renesas.com>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Subject: [PATCH v8 0/7] Add non-coherent DMA support for AX45MP Date: Wed, 12 Apr 2023 12:08:53 +0100 Message-Id: <20230412110900.69738-1-prabhakar.mahadev-lad.rj@bp.renesas.com> X-Mailer: git-send-email 2.25.1 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,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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?1762968639117266523?= X-GMAIL-MSGID: =?utf-8?q?1762968639117266523?= |
Series |
Add non-coherent DMA support for AX45MP
|
|
Message
Lad, Prabhakar
April 12, 2023, 11:08 a.m. UTC
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi All,
non-coherent DMA support for AX45MP
====================================
On the Andes AX45MP core, cache coherency is a specification option so it
may not be supported. In this case DMA will fail. To get around with this
issue this patch series does the below:
1] Andes alternative ports is implemented as errata which checks if the IOCP
is missing and only then applies to CMO errata. One vendor specific SBI EXT
(ANDES_SBI_EXT_IOCP_SW_WORKAROUND) is implemented as part of errata.
Below are the configs which Andes port provides (and are selected by RZ/Five):
- ERRATA_ANDES
- ERRATA_ANDES_CMO
OpenSBI patch supporting ANDES_SBI_EXT_IOCP_SW_WORKAROUND SBI can be found here,
https://patchwork.ozlabs.org/project/opensbi/patch/20230317140357.14819-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
2] Andes AX45MP core has a Programmable Physical Memory Attributes (PMA)
block that allows dynamic adjustment of memory attributes in the runtime.
It contains a configurable amount of PMA entries implemented as CSR
registers to control the attributes of memory locations in interest.
OpenSBI configures the PMA regions as required and creates a reserve memory
node and propagates it to the higher boot stack.
Currently OpenSBI (upstream) configures the required PMA region and passes
this a shared DMA pool to Linux.
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
pma_resv0@58000000 {
compatible = "shared-dma-pool";
reg = <0x0 0x58000000 0x0 0x08000000>;
no-map;
linux,dma-default;
};
};
The above shared DMA pool gets appended to Linux DTB so the DMA memory
requests go through this region.
3] We provide callbacks to synchronize specific content between memory and
cache.
4] RZ/Five SoC selects the below configs
- AX45MP_L2_CACHE
- DMA_GLOBAL_POOL
- ERRATA_ANDES
- ERRATA_ANDES_CMO
----------x---------------------x--------------------x---------------x--------------
Note,
- This series requires testing on Cores with zicbom and T-Head SoCs
- Ive used GCC 12.2.0 for compilation
- Tested all the IP blocks on RZ/Five which use DMA
- Patch series is dependent on the series from Arnd,
https://patchwork.kernel.org/project/linux-riscv/cover/20230327121317.4081816-1-arnd@kernel.org/
- Patches applies on top of palmer/for-next (d34a6b715a23)
v7 -> v8
* Dropped using function pointers and switched to ALTERNATIVE_X()
* Added new patches (#1, #2)
v6 -> v7
* Reworked the code based on Arnd's work
* Fixed review comments pointed by Arnd
* Fixed review comments pointed by Conor
v5.1 -> v6
* Dropped use of ALTERNATIVE_x() macro
* Now switched to used function pointers for CMO
* Moved driver to drivers/cache folder
v5 -> v5.1
* https://patchwork.kernel.org/project/linux-riscv/list/?series=708610&state=%2A&archive=both
v4 -> v5
* Rebased ALTERNATIVE_3() macro on top of Andrew's patches
* Rebased the changes on top of Heiko's alternative call patches
* Dropped configuring the PMA from Linux
* Dropped configuring the L2 cache from Linux and dropped the binding for same
* Now using runtime patching mechanism instead of compile time config
RFC v3 -> v4
* Implemented ALTERNATIVE_3() macro
* Now using runtime patching mechanism instead of compile time config
* Added Andes CMO as and errata
* Fixed comments pointed by Geert
RFC v2-> RFC v3
* Fixed review comments pointed by Conor
* Move DT binding into cache folder
* Fixed DT binding check issue
* Added andestech,ax45mp-cache.h header file
* Now passing the flags for the PMA setup as part of andestech,pma-regions
property.
* Added andestech,inst/data-prefetch and andestech,tag/data-ram-ctl
properties to configure the L2 cache.
* Registered the cache driver as platform driver
RFC v1-> RFC v2
* Moved out the code from arc/riscv to drivers/soc/renesas
* Now handling the PMA setup as part of the L2 cache
* Now making use of dma-noncoherent.c instead SoC specific implementation.
* Dropped arch_dma_alloc() and arch_dma_free()
* Switched to RISCV_DMA_NONCOHERENT
* Included DT binding doc
RFC v2: https://patchwork.kernel.org/project/linux-renesas-soc/cover/20221003223222.448551-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
RFC v1: https://patchwork.kernel.org/project/linux-renesas-soc/cover/20220906102154.32526-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
Lad Prabhakar (7):
riscv: asm: alternative-macros: Introduce ALTERNATIVE_3() macro
riscv: asm: vendorid_list: Add Andes Technology to the vendors list
riscv: errata: Add Andes alternative ports
dt-bindings: cache: andestech,ax45mp-cache: Add DT binding
documentation for L2 cache controller
cache: Add L2 cache management for Andes AX45MP RISC-V core
riscv: errata: Hookup the Andes AX45MP non-coherent handling
soc: renesas: Kconfig: Select the required configs for RZ/Five SoC
.../cache/andestech,ax45mp-cache.yaml | 81 +++++++
MAINTAINERS | 7 +
arch/riscv/Kconfig.errata | 21 ++
arch/riscv/errata/Makefile | 1 +
arch/riscv/errata/andes/Makefile | 1 +
arch/riscv/errata/andes/errata.c | 104 ++++++++
arch/riscv/include/asm/alternative-macros.h | 51 +++-
arch/riscv/include/asm/alternative.h | 3 +
arch/riscv/include/asm/cacheflush.h | 9 +
arch/riscv/include/asm/errata_list.h | 38 ++-
arch/riscv/include/asm/vendorid_list.h | 1 +
arch/riscv/kernel/alternative.c | 5 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/cache/Kconfig | 10 +
drivers/cache/Makefile | 3 +
drivers/cache/ax45mp_cache.c | 222 ++++++++++++++++++
drivers/soc/renesas/Kconfig | 4 +
18 files changed, 552 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml
create mode 100644 arch/riscv/errata/andes/Makefile
create mode 100644 arch/riscv/errata/andes/errata.c
create mode 100644 drivers/cache/Kconfig
create mode 100644 drivers/cache/Makefile
create mode 100644 drivers/cache/ax45mp_cache.c
Comments
On Wed, Apr 12, 2023 at 12:08:53PM +0100, Prabhakar wrote: > Note, > - This series requires testing on Cores with zicbom and T-Head SoCs As I said last time, I dunno what actual Zicbom stuff exists, other than perhaps the Ventana lads having something. I did some tyre kicking on my D1 and it was fine, although nothing has actually changed materially for either of them with this series in v8.. Cheers, Conor.
On Wed, Apr 12, 2023 at 09:32:30PM +0100, Conor Dooley wrote: > On Wed, Apr 12, 2023 at 12:08:53PM +0100, Prabhakar wrote: > > > Note, > > - This series requires testing on Cores with zicbom and T-Head SoCs > > As I said last time, I dunno what actual Zicbom stuff exists, other than > perhaps the Ventana lads having something. I did some tyre kicking on my > D1 and it was fine, although nothing has actually changed materially for > either of them with this series in v8.. And as saying before, there is absolutely no reason to add non-standard non-coherent DMA support and let this cancer creep. If you want Linux support implement Zicbom, be that in hardware or the SBI.
On Sun, 16 Apr 2023 23:53:17 PDT (-0700), Christoph Hellwig wrote: > On Wed, Apr 12, 2023 at 09:32:30PM +0100, Conor Dooley wrote: >> On Wed, Apr 12, 2023 at 12:08:53PM +0100, Prabhakar wrote: >> >> > Note, >> > - This series requires testing on Cores with zicbom and T-Head SoCs >> >> As I said last time, I dunno what actual Zicbom stuff exists, other than >> perhaps the Ventana lads having something. I did some tyre kicking on my >> D1 and it was fine, although nothing has actually changed materially for >> either of them with this series in v8.. > > And as saying before, there is absolutely no reason to add non-standard > non-coherent DMA support and let this cancer creep. If you want Linux > support implement Zicbom, be that in hardware or the SBI. IMO we should just take the support in Linux: trying to hide stuff behind the SBI leads to more more headaches than it's worth, we end up with a bunch of broken firmware to try and work around. We've already got a mess here because of the D1 support, we might as well just live with it. In practice there's just going to be a ton of mess in arch/riscv, as the ISA has been missing many core features for many years and hardware vendors are allowed to do whatever they want. That's obviously a huge headache, but I think there's nothing we can really do about it.
On Wed, Apr 19, 2023 at 08:59:03AM -0700, Palmer Dabbelt wrote: > IMO we should just take the support in Linux: trying to hide stuff behind the > SBI leads to more more headaches than it's worth, we end up with a bunch of > broken firmware to try and work around. We've already got a mess here because > of the D1 support, we might as well just live with it. I strongly disagree. Adding more and more per-vendor ops simply does not scale. We're getting us into a giant long-time mess that will be unfixable.