From: "Arnd Bergmann" <arnd@arndb.de>
To: Prabhakar <prabhakar.csengg@gmail.com>,
"Conor.Dooley" <conor.dooley@microchip.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Heiko Stübner" <heiko@sntech.de>, guoren <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 <linux-renesas-soc@vger.kernel.org>,
"Biju Das" <biju.das.jz@bp.renesas.com>,
"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH v7 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management
Date: Thu, 30 Mar 2023 23:34:02 +0200 [thread overview]
Message-ID: <6ca5941a-8803-477d-8b40-17292decc5af@app.fastmail.com> (raw)
In-Reply-To: <20230330204217.47666-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, Mar 30, 2023, at 22:42, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Currently, selecting which CMOs to use on a given platform is done using
> and ALTERNATIVE_X() macro. This was manageable when there were just two
> CMO implementations, but now that there are more and more platforms coming
> needing custom CMOs, the use of the ALTERNATIVE_X() macro is unmanageable.
>
> To avoid such issues this patch switches to use of function pointers
> instead of ALTERNATIVE_X() macro for cache management (the only drawback
> being performance over the previous approach).
>
> void (*clean_range)(unsigned long addr, unsigned long size);
> void (*inv_range)(unsigned long addr, unsigned long size);
> void (*flush_range)(unsigned long addr, unsigned long size);
>
> The above function pointers are provided to be overridden for platforms
> needing CMO.
>
> Convert ZICBOM and T-HEAD CMO to use function pointers.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
This is looking pretty good. There are a few things that I
still see sticking out, and I think I've mentioned some of
them before, but don't remember if there was a reason for
doing it like this:
> +#ifdef CONFIG_ERRATA_THEAD_CMO
I would rename this to not call this an 'ERRATA' but
just make it a driver. Not important though, and there
was probably a reason you did it like this.
> +extern struct riscv_cache_ops noncoherent_cache_ops;
> +
> +void riscv_noncoherent_register_cache_ops(const struct riscv_cache_ops
> *ops);
> +
> +static inline void riscv_dma_noncoherent_clean(void *vaddr, size_t
> size)
> +{
> + if (noncoherent_cache_ops.clean_range) {
> + unsigned long addr = (unsigned long)vaddr;
> +
> + noncoherent_cache_ops.clean_range(addr, size);
> + }
> +}
The type case should not be necessary here. Instead I would
make the callbacks use 'void *' as well, not 'unsigned long'.
It's possible that some future cache controller driver requires
passing physical addresses, as is common for last level cache,
but as long as all drivers pass virtual addresses, it's easier
to do the phys_to_virt() in common code.
It also seems wrong to have the fallback be to do nothing
when the pointer is NULL, since that cannot actually work
when a device is not cache coherent.
I would either initialize the function pointer to the
zicbom version and remove the NULL check, or keep the
pointer NULL and have an explicit
'else zicbom_clean_range()' fallback.
> +static void zicbom_register_cmo_ops(void)
> +{
> + riscv_noncoherent_register_cache_ops(&zicbom_cmo_ops);
> +}
> +#else
> +static void zicbom_register_cmo_ops(void) {}
> +#endif
As far as I recall, the #else path here was needed previously
to work around a binutils dependency, but with the current
code, it should be possible to just always enable
CONFIG_RISCV_ISA_ZICBOM when RISCV_DMA_NONCOHERENT is used.
Arnd
next prev parent reply other threads:[~2023-03-30 21:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 20:42 [PATCH v7 0/6] RISC-V non-coherent function pointer based CMO + non-coherent DMA support for AX45MP Prabhakar
2023-03-30 20:42 ` [PATCH v7 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management Prabhakar
2023-03-30 21:34 ` Arnd Bergmann [this message]
2023-03-31 7:54 ` Conor Dooley
2023-03-31 7:58 ` Arnd Bergmann
2023-03-31 10:37 ` Lad, Prabhakar
2023-03-31 10:44 ` Arnd Bergmann
2023-03-31 12:11 ` Lad, Prabhakar
2023-04-03 17:00 ` Lad, Prabhakar
2023-03-31 10:55 ` Conor Dooley
2023-03-31 11:36 ` Arnd Bergmann
2023-03-31 7:31 ` Geert Uytterhoeven
2023-03-31 10:45 ` Lad, Prabhakar
2023-03-31 12:24 ` Conor Dooley
2023-04-03 18:23 ` Lad, Prabhakar
2023-04-03 18:31 ` Conor Dooley
2023-04-04 5:29 ` Christoph Hellwig
2023-04-04 6:24 ` Biju Das
2023-04-04 15:42 ` Christoph Hellwig
2023-04-05 6:08 ` Biju Das
2023-04-07 0:03 ` Andrea Parri
2023-04-07 5:33 ` Christoph Hellwig
2023-04-04 6:50 ` Arnd Bergmann
2023-04-04 6:59 ` Conor Dooley
2023-04-06 18:59 ` Lad, Prabhakar
2023-03-30 20:42 ` [PATCH v7 2/6] riscv: asm: vendorid_list: Add Andes Technology to the vendors list Prabhakar
2023-03-30 20:42 ` [PATCH v7 3/6] riscv: errata: Add Andes alternative ports Prabhakar
2023-03-30 20:42 ` [PATCH v7 4/6] dt-bindings: cache: r9a07g043f-l2-cache: Add DT binding documentation for L2 cache controller Prabhakar
2023-03-31 10:21 ` Conor Dooley
2023-03-31 10:47 ` Lad, Prabhakar
2023-03-30 20:42 ` [PATCH v7 5/6] cache: Add L2 cache management for Andes AX45MP RISC-V core Prabhakar
2023-03-31 12:45 ` Conor Dooley
2023-03-31 20:17 ` Lad, Prabhakar
2023-03-30 20:42 ` [PATCH v7 6/6] soc: renesas: Kconfig: Select the required configs for RZ/Five SoC Prabhakar
2023-03-31 7:37 ` Geert Uytterhoeven
2023-03-31 7:37 ` Geert Uytterhoeven
2023-03-31 18:05 ` [PATCH v7 0/6] RISC-V non-coherent function pointer based CMO + non-coherent DMA support for AX45MP Conor Dooley
2023-03-31 20:09 ` Lad, Prabhakar
2023-03-31 20:15 ` Conor Dooley
2023-04-01 1:47 ` Icenowy Zheng
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=6ca5941a-8803-477d-8b40-17292decc5af@app.fastmail.com \
--to=arnd@arndb.de \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--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=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=prabhakar.csengg@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®