From: Conor Dooley <conor@kernel.org>
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Magnus Damm <magnus.damm@gmail.com>,
Heiko Stuebner <heiko@sntech.de>, Guo Ren <guoren@kernel.org>,
Conor Dooley <conor.dooley@microchip.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Nathan Chancellor <nathan@kernel.org>,
Atish Patra <atishp@rivosinc.com>,
Anup Patel <apatel@ventanamicro.com>,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Biju Das <biju.das.jz@bp.renesas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [RFC PATCH v2 2/2] soc: renesas: Add L2 cache management for RZ/Five SoC
Date: Tue, 4 Oct 2022 18:42:56 +0100 [thread overview]
Message-ID: <YzxwoELNBctbhjJb@spud> (raw)
In-Reply-To: <20221003223222.448551-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Oct 03, 2022 at 11:32:22PM +0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> On the AX45MP core, cache coherency is a specification option so it may
> not be supported. In this case DMA will fail. As a workaround, firstly we
> allocate a global dma coherent pool from which DMA allocations are taken
> and marked as non-cacheable + bufferable using the PMA region as specified
> in the device tree. Synchronization callbacks are implemented to
> synchronize when doing DMA transactions.
>
> The 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.
>
> Below are the memory attributes supported:
> * Device, Non-bufferable
> * Device, bufferable
> * Memory, Non-cacheable, Non-bufferable
> * Memory, Non-cacheable, Bufferable
> * Memory, Write-back, No-allocate
> * Memory, Write-back, Read-allocate
> * Memory, Write-back, Write-allocate
> * Memory, Write-back, Read and Write-allocate
>
> This patch adds support to configure the memory attributes of the memory
> regions as passed from the l2 cache node and exposes the cache management
> ops. Currently the OpenSBI code implements support for "Memory,
> Non-cacheable, Non-bufferable" option with SBI_EXT_ANDES_SET_PMA.
>
> More info about PMA (section 10.3):
> http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf
>
> This feature is based on the work posted [0] by Vincent Chen
> <vincentc@andestech.com> for the Andes AndeStart RISC-V CPU.
>
> [0] https://lore.kernel.org/lkml/1540982130-28248-1-git-send-email-vincentc@andestech.com/
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> arch/riscv/include/asm/cacheflush.h | 8 +
> arch/riscv/include/asm/errata_list.h | 2 +
> arch/riscv/include/asm/sbi.h | 1 +
> arch/riscv/mm/dma-noncoherent.c | 20 ++
Stupid question maybe, but I assume you mixed the driver addition and
the changes to arch/riscv for the sake of easily creating the RFC?
> drivers/soc/renesas/Makefile | 4 +
> drivers/soc/renesas/rzf/Makefile | 3 +
> drivers/soc/renesas/rzf/ax45mp_cache.c | 365 +++++++++++++++++++++++++
> drivers/soc/renesas/rzf/rzf_sbi.h | 27 ++
> 8 files changed, 430 insertions(+)
> create mode 100644 drivers/soc/renesas/rzf/Makefile
> create mode 100644 drivers/soc/renesas/rzf/ax45mp_cache.c
> create mode 100644 drivers/soc/renesas/rzf/rzf_sbi.h
>
I won't make any comments on the ALTERNATIVES usage & leave that to the
likes of Heiko rather than make a fool of myself! But to my untrained
eye, having to use #defines looks like you've strayed pretty far from
the light.. My understanding was that the whole point was to avoid
having any ifdef-ery!
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 2a0ef738695e..10a7c855d125 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -37,6 +37,7 @@ enum sbi_ext_id {
>
> /* Vendor extensions must lie within this range */
> SBI_EXT_VENDOR_START = 0x09000000,
> + SBI_EXT_ANDES = 0x0900031E,
> SBI_EXT_VENDOR_END = 0x09FFFFFF,
> };
Hmm, does this belong there? It certainly makes the comment look a
little odd! /If/ it goes into this file, I think it should be in a
separate section "heading" - but could it not be put into rzf_sbi.h?
> diff --git a/drivers/soc/renesas/rzf/ax45mp_cache.c b/drivers/soc/renesas/rzf/ax45mp_cache.c
> new file mode 100644
> index 000000000000..6eca32aef33e
> --- /dev/null
> +++ b/drivers/soc/renesas/rzf/ax45mp_cache.c
> @@ -0,0 +1,365 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PMA setup and non-coherent cache functions for AX45MP
> + *
Given your comment in the commit message, should this also be carrying a
copyright from Andestech?
> + * Copyright (C) 2022 Renesas Electronics Corp.
> + */
> +
> +#include <linux/cacheinfo.h>
> +#include <linux/of_address.h>
> +
> +static void __iomem *l2c_base;
> +
> +/* -----------------------------------------------------------------------------
I'll (mostly) keep my nose out of style for soc/renesas, but this /* ---
style looks unusual!
> + * PMA setup
> + */
> +static long sbi_set_pma(void *arg)
> +static void ax45mp_configure_pma_regions(struct device_node *np, int count)
> +static void cpu_dcache_inval_range(unsigned long start,
> +void rzfive_cpu_dma_inval_range(void *vaddr, size_t size)
There's a real mix of function name prefixes in here, sbi_ aside is
there a reason you didn't just stick to ax45mp_foo()? Apologies if
I missed something that should've been obvious
> +static void cpu_dcache_wb_range(unsigned long start,
> + unsigned long end,
> + int line_size)
> +{
> + bool ucctl_ok = false;
> + unsigned long pa;
> + int mhartid = 0;
> +#ifdef CONFIG_SMP
> + mhartid = smp_processor_id();
> +#endif
Won't this produce complaints from your if you compile with CONFIG_SMP
set?
> +
> + ucctl_ok = cpu_cache_controlable();
> +
> + while (end > start) {
> + if (ucctl_ok) {
> + csr_write(CCTL_REG_UCCTLBEGINADDR_NUM, start);
> + csr_write(CCTL_REG_UCCTLCOMMAND_NUM, CCTL_L1D_VA_WB);
> + }
> +
> + if (l2c_base && (cpu_l2c_ctl_status() & L2_CACHE_CTL_CEN_MASK)) {
> + pa = virt_to_phys((void *)start);
> + writel(pa, (void *)(l2c_base + L2C_REG_CN_ACC_OFFSET(mhartid)));
> + writel(CCTL_L2_PA_WB, (void *)(l2c_base + L2C_REG_CN_CMD_OFFSET(mhartid)));
> + while ((cpu_l2c_get_cctl_status() &
> + CCTL_L2_STATUS_CN_MASK(mhartid)) != CCTL_L2_STATUS_IDLE)
> + ;
> + }
> +
> + start += line_size;
> + }
> +}
Thanks,
Conor.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Prabhakar <prabhakar.csengg@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Magnus Damm <magnus.damm@gmail.com>,
Heiko Stuebner <heiko@sntech.de>, Guo Ren <guoren@kernel.org>,
Conor Dooley <conor.dooley@microchip.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Nathan Chancellor <nathan@kernel.org>,
Atish Patra <atishp@rivosinc.com>,
Anup Patel <apatel@ventanamicro.com>,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Biju Das <biju.das.jz@bp.renesas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [RFC PATCH v2 2/2] soc: renesas: Add L2 cache management for RZ/Five SoC
Date: Tue, 4 Oct 2022 18:42:56 +0100 [thread overview]
Message-ID: <YzxwoELNBctbhjJb@spud> (raw)
In-Reply-To: <20221003223222.448551-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Oct 03, 2022 at 11:32:22PM +0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> On the AX45MP core, cache coherency is a specification option so it may
> not be supported. In this case DMA will fail. As a workaround, firstly we
> allocate a global dma coherent pool from which DMA allocations are taken
> and marked as non-cacheable + bufferable using the PMA region as specified
> in the device tree. Synchronization callbacks are implemented to
> synchronize when doing DMA transactions.
>
> The 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.
>
> Below are the memory attributes supported:
> * Device, Non-bufferable
> * Device, bufferable
> * Memory, Non-cacheable, Non-bufferable
> * Memory, Non-cacheable, Bufferable
> * Memory, Write-back, No-allocate
> * Memory, Write-back, Read-allocate
> * Memory, Write-back, Write-allocate
> * Memory, Write-back, Read and Write-allocate
>
> This patch adds support to configure the memory attributes of the memory
> regions as passed from the l2 cache node and exposes the cache management
> ops. Currently the OpenSBI code implements support for "Memory,
> Non-cacheable, Non-bufferable" option with SBI_EXT_ANDES_SET_PMA.
>
> More info about PMA (section 10.3):
> http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf
>
> This feature is based on the work posted [0] by Vincent Chen
> <vincentc@andestech.com> for the Andes AndeStart RISC-V CPU.
>
> [0] https://lore.kernel.org/lkml/1540982130-28248-1-git-send-email-vincentc@andestech.com/
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> arch/riscv/include/asm/cacheflush.h | 8 +
> arch/riscv/include/asm/errata_list.h | 2 +
> arch/riscv/include/asm/sbi.h | 1 +
> arch/riscv/mm/dma-noncoherent.c | 20 ++
Stupid question maybe, but I assume you mixed the driver addition and
the changes to arch/riscv for the sake of easily creating the RFC?
> drivers/soc/renesas/Makefile | 4 +
> drivers/soc/renesas/rzf/Makefile | 3 +
> drivers/soc/renesas/rzf/ax45mp_cache.c | 365 +++++++++++++++++++++++++
> drivers/soc/renesas/rzf/rzf_sbi.h | 27 ++
> 8 files changed, 430 insertions(+)
> create mode 100644 drivers/soc/renesas/rzf/Makefile
> create mode 100644 drivers/soc/renesas/rzf/ax45mp_cache.c
> create mode 100644 drivers/soc/renesas/rzf/rzf_sbi.h
>
I won't make any comments on the ALTERNATIVES usage & leave that to the
likes of Heiko rather than make a fool of myself! But to my untrained
eye, having to use #defines looks like you've strayed pretty far from
the light.. My understanding was that the whole point was to avoid
having any ifdef-ery!
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 2a0ef738695e..10a7c855d125 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -37,6 +37,7 @@ enum sbi_ext_id {
>
> /* Vendor extensions must lie within this range */
> SBI_EXT_VENDOR_START = 0x09000000,
> + SBI_EXT_ANDES = 0x0900031E,
> SBI_EXT_VENDOR_END = 0x09FFFFFF,
> };
Hmm, does this belong there? It certainly makes the comment look a
little odd! /If/ it goes into this file, I think it should be in a
separate section "heading" - but could it not be put into rzf_sbi.h?
> diff --git a/drivers/soc/renesas/rzf/ax45mp_cache.c b/drivers/soc/renesas/rzf/ax45mp_cache.c
> new file mode 100644
> index 000000000000..6eca32aef33e
> --- /dev/null
> +++ b/drivers/soc/renesas/rzf/ax45mp_cache.c
> @@ -0,0 +1,365 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PMA setup and non-coherent cache functions for AX45MP
> + *
Given your comment in the commit message, should this also be carrying a
copyright from Andestech?
> + * Copyright (C) 2022 Renesas Electronics Corp.
> + */
> +
> +#include <linux/cacheinfo.h>
> +#include <linux/of_address.h>
> +
> +static void __iomem *l2c_base;
> +
> +/* -----------------------------------------------------------------------------
I'll (mostly) keep my nose out of style for soc/renesas, but this /* ---
style looks unusual!
> + * PMA setup
> + */
> +static long sbi_set_pma(void *arg)
> +static void ax45mp_configure_pma_regions(struct device_node *np, int count)
> +static void cpu_dcache_inval_range(unsigned long start,
> +void rzfive_cpu_dma_inval_range(void *vaddr, size_t size)
There's a real mix of function name prefixes in here, sbi_ aside is
there a reason you didn't just stick to ax45mp_foo()? Apologies if
I missed something that should've been obvious
> +static void cpu_dcache_wb_range(unsigned long start,
> + unsigned long end,
> + int line_size)
> +{
> + bool ucctl_ok = false;
> + unsigned long pa;
> + int mhartid = 0;
> +#ifdef CONFIG_SMP
> + mhartid = smp_processor_id();
> +#endif
Won't this produce complaints from your if you compile with CONFIG_SMP
set?
> +
> + ucctl_ok = cpu_cache_controlable();
> +
> + while (end > start) {
> + if (ucctl_ok) {
> + csr_write(CCTL_REG_UCCTLBEGINADDR_NUM, start);
> + csr_write(CCTL_REG_UCCTLCOMMAND_NUM, CCTL_L1D_VA_WB);
> + }
> +
> + if (l2c_base && (cpu_l2c_ctl_status() & L2_CACHE_CTL_CEN_MASK)) {
> + pa = virt_to_phys((void *)start);
> + writel(pa, (void *)(l2c_base + L2C_REG_CN_ACC_OFFSET(mhartid)));
> + writel(CCTL_L2_PA_WB, (void *)(l2c_base + L2C_REG_CN_CMD_OFFSET(mhartid)));
> + while ((cpu_l2c_get_cctl_status() &
> + CCTL_L2_STATUS_CN_MASK(mhartid)) != CCTL_L2_STATUS_IDLE)
> + ;
> + }
> +
> + start += line_size;
> + }
> +}
Thanks,
Conor.
next prev parent reply other threads:[~2022-10-04 17:43 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 22:32 [RFC PATCH v2 0/2] AX45MP: Add support to non-coherent DMA Prabhakar
2022-10-03 22:32 ` Prabhakar
2022-10-03 22:32 ` [RFC PATCH v2 1/2] dt-bindings: soc: renesas: r9a07g043f-l2-cache: Add DT binding documentation for L2 cache controller Prabhakar
2022-10-03 22:32 ` Prabhakar
2022-10-04 0:37 ` Rob Herring
2022-10-04 6:41 ` Geert Uytterhoeven
2022-10-04 6:41 ` Geert Uytterhoeven
2022-10-04 7:26 ` Lad, Prabhakar
2022-10-04 7:26 ` Lad, Prabhakar
2022-10-04 7:31 ` Conor Dooley
2022-10-04 7:31 ` Conor Dooley
2022-10-04 7:59 ` Lad, Prabhakar
2022-10-04 7:59 ` Lad, Prabhakar
2022-10-04 9:12 ` Geert Uytterhoeven
2022-10-04 9:12 ` Geert Uytterhoeven
2022-10-04 9:31 ` Lad, Prabhakar
2022-10-04 9:31 ` Lad, Prabhakar
2022-10-04 7:33 ` Conor Dooley
2022-10-04 7:33 ` Conor Dooley
2022-10-03 22:32 ` [RFC PATCH v2 2/2] soc: renesas: Add L2 cache management for RZ/Five SoC Prabhakar
2022-10-03 22:32 ` Prabhakar
2022-10-04 17:42 ` Conor Dooley [this message]
2022-10-04 17:42 ` Conor Dooley
2022-10-05 8:44 ` Lad, Prabhakar
2022-10-05 8:44 ` Lad, Prabhakar
2022-10-05 8:58 ` Conor Dooley
2022-10-05 8:58 ` Conor Dooley
2022-10-05 9:17 ` Conor.Dooley
2022-10-05 9:17 ` Conor.Dooley
2022-10-05 10:20 ` Lad, Prabhakar
2022-10-05 10:20 ` Lad, Prabhakar
2022-10-05 10:29 ` Conor Dooley
2022-10-05 10:29 ` Conor Dooley
2022-10-05 9:57 ` Arnd Bergmann
2022-10-05 9:57 ` Arnd Bergmann
2022-10-05 10:14 ` Lad, Prabhakar
2022-10-05 10:14 ` Lad, Prabhakar
2022-10-05 1:28 ` Guo Ren
2022-10-05 1:28 ` Guo Ren
2022-10-05 12:53 ` Lad, Prabhakar
2022-10-05 12:53 ` Lad, Prabhakar
2022-10-05 14:23 ` Guo Ren
2022-10-05 14:23 ` Guo Ren
2022-10-05 15:02 ` Lad, Prabhakar
2022-10-05 15:02 ` Lad, Prabhakar
2022-10-06 0:59 ` Guo Ren
2022-10-06 0:59 ` Guo Ren
2022-10-06 15:36 ` Lad, Prabhakar
2022-10-06 15:36 ` Lad, Prabhakar
2022-10-11 9:38 ` Lad, Prabhakar
2022-10-11 9:38 ` Lad, Prabhakar
2022-10-11 13:10 ` Guo Ren
2022-10-11 13:10 ` Guo Ren
2022-10-17 9:39 ` Lad, Prabhakar
2022-10-17 9:39 ` Lad, Prabhakar
2022-10-17 12:36 ` Guo Ren
2022-10-17 12:36 ` Guo Ren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzxwoELNBctbhjJb@spud \
--to=conor@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=magnus.damm@gmail.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=philipp.tomsich@vrull.eu \
--cc=prabhakar.csengg@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.