From: Conor Dooley <conor@kernel.org> To: Arnd Bergmann <arnd@arndb.de> Cc: "Palmer Dabbelt" <palmer@dabbelt.com>, Prabhakar <prabhakar.csengg@gmail.com>, "Conor.Dooley" <conor.dooley@microchip.com>, "Andrew Jones" <ajones@ventanamicro.com>, "Albert Ou" <aou@eecs.berkeley.edu>, "Anup Patel" <apatel@ventanamicro.com>, "Atish Patra" <atishp@rivosinc.com>, "Biju Das" <biju.das.jz@bp.renesas.com>, devicetree@vger.kernel.org, "Geert Uytterhoeven" <geert@linux-m68k.org>, guoren <guoren@kernel.org>, "Christoph Hellwig" <hch@infradead.org>, "Heiko Stübner" <heiko@sntech.de>, "Jisheng Zhang" <jszhang@kernel.org>, krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, linux-riscv@lists.infradead.org, "Magnus Damm" <magnus.damm@gmail.com>, "Nathan Chancellor" <nathan@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Philipp Tomsich" <philipp.tomsich@vrull.eu>, "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>, "Rob Herring" <robh+dt@kernel.org>, "Samuel Holland" <samuel@sholland.org>, soc@kernel.org, "Daire McNamara" <daire.mcnamara@microchip.com> Subject: Re: [RFC v5.1 9/9] [DON'T APPLY] cache: sifive-ccache: add cache flushing capability Date: Wed, 4 Jan 2023 11:56:40 +0000 [thread overview] Message-ID: <Y7VpeK48nslxklkF@spud> (raw) In-Reply-To: <43aee000-5b89-4d94-98d2-b37b1a18a83e@app.fastmail.com> [-- Attachment #1: Type: text/plain, Size: 3151 bytes --] Hey Arnd, On Wed, Jan 04, 2023 at 11:19:44AM +0100, Arnd Bergmann wrote: > On Wed, Jan 4, 2023, at 10:23, Conor Dooley wrote: > >>Right, no need to touch the existing file as part of this series, > >>it probably just gets in the way of defining a good interface here. > > > > Sure. Can leave it where it was & I'll sort it out later when it's > > errata etc get added. > > > > Btw, would you mind pointing out where you wanted to have that if/else > > you mentioned on IRC? > > I meant replacing both of the runtime patching indirections in > arch_sync_dma_for_device(). At the moment, this function calls > ALT_CMO_OP(), which is patched to either call the ZICBOM or the > THEAD variant, and if I read this right you add a third case > there with another level of indirection using static_branch. Yah, pretty much. > I would try to replace both of these indirections and instead > handle it all from C code in arch_sync_dma_for_device() directly, > for the purpose of readability and maintainability. > static inline void dma_cache_clean(void *vaddr, size_t size) > { > if (!cache_maint_ops.clean) > zicbom_cache_clean(vaddr, size, riscv_cbom_block_size); And I figure that this function is effectively a wrapper around ALT_CMO_OP()? > else > cache_maint_ops.clean(vaddr, size, riscv_cbom_block_size); And this one gets registered by the driver using an interface like the one I already proposed, just with the cache_maint_ops struct expanded? Extrapolating, with these changes having an errata would not even be needed in order to do cache maintenance. Since the ALT_CMO_OP() version would only be used inside zicbom_cache_clean(), assuming I understood correctly, a driver could just register cache_maint_ops for a given platform without having to muck around with errata. If so, that seems like a distinct improvement over my suggestion & gets around the thing I mentioned in 0/9 about a shared case in the alternative application code. Again, assuming I understood correctly, I like this a lot. > } > > void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, > enum dma_data_direction dir) > { > void *vaddr = phys_to_virt(paddr); > > switch (dir) { > case DMA_TO_DEVICE: > case DMA_FROM_DEVICE: > dma_cache_clean(vaddr, size); > break; > case DMA_BIDIRECTIONAL: > dma_cache_flush(vaddr, size); > break; > default: > break; > } > } > > which then makes it very clear what the actual code path > is, while leaving the zicbom case free of indirect function > calls. You can still use a static_branch() to optimize the > conditional, but I would try to avoid any extra indirection > levels or errata checks. The other thing that I like about this is we can then remove the various calls to ALT_CMO_OP() that are scattered around arch/riscv now & replace them with functions that have more understandable names. Thanks Arnd! Conor. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org> To: Arnd Bergmann <arnd@arndb.de> Cc: "Palmer Dabbelt" <palmer@dabbelt.com>, Prabhakar <prabhakar.csengg@gmail.com>, "Conor.Dooley" <conor.dooley@microchip.com>, "Andrew Jones" <ajones@ventanamicro.com>, "Albert Ou" <aou@eecs.berkeley.edu>, "Anup Patel" <apatel@ventanamicro.com>, "Atish Patra" <atishp@rivosinc.com>, "Biju Das" <biju.das.jz@bp.renesas.com>, devicetree@vger.kernel.org, "Geert Uytterhoeven" <geert@linux-m68k.org>, guoren <guoren@kernel.org>, "Christoph Hellwig" <hch@infradead.org>, "Heiko Stübner" <heiko@sntech.de>, "Jisheng Zhang" <jszhang@kernel.org>, krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, linux-riscv@lists.infradead.org, "Magnus Damm" <magnus.damm@gmail.com>, "Nathan Chancellor" <nathan@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Philipp Tomsich" <philipp.tomsich@vrull.eu>, "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>, "Rob Herring" <robh+dt@kernel.org>, "Samuel Holland" <samuel@sholland.org>, soc@kernel.org, "Daire McNamara" <daire.mcnamara@microchip.com> Subject: Re: [RFC v5.1 9/9] [DON'T APPLY] cache: sifive-ccache: add cache flushing capability Date: Wed, 4 Jan 2023 11:56:40 +0000 [thread overview] Message-ID: <Y7VpeK48nslxklkF@spud> (raw) In-Reply-To: <43aee000-5b89-4d94-98d2-b37b1a18a83e@app.fastmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3151 bytes --] Hey Arnd, On Wed, Jan 04, 2023 at 11:19:44AM +0100, Arnd Bergmann wrote: > On Wed, Jan 4, 2023, at 10:23, Conor Dooley wrote: > >>Right, no need to touch the existing file as part of this series, > >>it probably just gets in the way of defining a good interface here. > > > > Sure. Can leave it where it was & I'll sort it out later when it's > > errata etc get added. > > > > Btw, would you mind pointing out where you wanted to have that if/else > > you mentioned on IRC? > > I meant replacing both of the runtime patching indirections in > arch_sync_dma_for_device(). At the moment, this function calls > ALT_CMO_OP(), which is patched to either call the ZICBOM or the > THEAD variant, and if I read this right you add a third case > there with another level of indirection using static_branch. Yah, pretty much. > I would try to replace both of these indirections and instead > handle it all from C code in arch_sync_dma_for_device() directly, > for the purpose of readability and maintainability. > static inline void dma_cache_clean(void *vaddr, size_t size) > { > if (!cache_maint_ops.clean) > zicbom_cache_clean(vaddr, size, riscv_cbom_block_size); And I figure that this function is effectively a wrapper around ALT_CMO_OP()? > else > cache_maint_ops.clean(vaddr, size, riscv_cbom_block_size); And this one gets registered by the driver using an interface like the one I already proposed, just with the cache_maint_ops struct expanded? Extrapolating, with these changes having an errata would not even be needed in order to do cache maintenance. Since the ALT_CMO_OP() version would only be used inside zicbom_cache_clean(), assuming I understood correctly, a driver could just register cache_maint_ops for a given platform without having to muck around with errata. If so, that seems like a distinct improvement over my suggestion & gets around the thing I mentioned in 0/9 about a shared case in the alternative application code. Again, assuming I understood correctly, I like this a lot. > } > > void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, > enum dma_data_direction dir) > { > void *vaddr = phys_to_virt(paddr); > > switch (dir) { > case DMA_TO_DEVICE: > case DMA_FROM_DEVICE: > dma_cache_clean(vaddr, size); > break; > case DMA_BIDIRECTIONAL: > dma_cache_flush(vaddr, size); > break; > default: > break; > } > } > > which then makes it very clear what the actual code path > is, while leaving the zicbom case free of indirect function > calls. You can still use a static_branch() to optimize the > conditional, but I would try to avoid any extra indirection > levels or errata checks. The other thing that I like about this is we can then remove the various calls to ALT_CMO_OP() that are scattered around arch/riscv now & replace them with functions that have more understandable names. Thanks Arnd! Conor. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-01-04 11:56 UTC|newest] Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-12 11:54 [PATCH v5 0/6] AX45MP: Add support to non-coherent DMA Prabhakar 2022-12-12 11:54 ` Prabhakar 2022-12-12 11:55 ` [PATCH v5 1/6] riscv: asm: alternative-macros: Introduce ALTERNATIVE_3() macro Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-12 12:32 ` Heiko Stuebner 2022-12-12 12:32 ` Heiko Stuebner 2022-12-13 17:21 ` Geert Uytterhoeven 2022-12-13 17:21 ` Geert Uytterhoeven 2022-12-13 17:49 ` Lad, Prabhakar 2022-12-13 17:49 ` Lad, Prabhakar 2022-12-14 14:34 ` Andrew Jones 2022-12-14 14:34 ` Andrew Jones 2022-12-17 21:41 ` Conor Dooley 2022-12-17 21:41 ` Conor Dooley 2022-12-19 11:15 ` Lad, Prabhakar 2022-12-19 11:15 ` Lad, Prabhakar 2022-12-19 16:22 ` Conor Dooley 2022-12-19 16:22 ` Conor Dooley 2022-12-19 16:24 ` Lad, Prabhakar 2022-12-19 16:24 ` Lad, Prabhakar 2022-12-12 11:55 ` [PATCH v5 2/6] riscv: asm: vendorid_list: Add Andes Technology to the vendors list Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-12 11:55 ` [PATCH v5 3/6] riscv: errata: Add Andes alternative ports Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-17 21:19 ` Conor Dooley 2022-12-17 21:19 ` Conor Dooley 2022-12-19 11:19 ` Lad, Prabhakar 2022-12-19 11:19 ` Lad, Prabhakar 2022-12-19 16:20 ` Conor Dooley 2022-12-19 16:20 ` Conor Dooley 2022-12-21 0:31 ` Lad, Prabhakar 2022-12-21 0:31 ` Lad, Prabhakar 2022-12-12 11:55 ` [PATCH v5 4/6] riscv: mm: dma-noncoherent: Pass direction and operation to ALT_CMO_OP() Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-13 17:14 ` Geert Uytterhoeven 2022-12-13 17:14 ` Geert Uytterhoeven 2022-12-13 17:57 ` Lad, Prabhakar 2022-12-13 17:57 ` Lad, Prabhakar 2022-12-17 20:52 ` Conor Dooley 2022-12-17 20:52 ` Conor Dooley 2022-12-19 11:21 ` Lad, Prabhakar 2022-12-19 11:21 ` Lad, Prabhakar 2022-12-12 11:55 ` [PATCH v5 5/6] dt-bindings: cache: r9a07g043f-l2-cache: Add DT binding documentation for L2 cache controller Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-12 17:28 ` Rob Herring 2022-12-12 17:28 ` Rob Herring 2022-12-12 11:55 ` [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC Prabhakar 2022-12-12 11:55 ` Prabhakar 2022-12-15 10:34 ` Geert Uytterhoeven 2022-12-15 10:34 ` Geert Uytterhoeven 2022-12-15 11:03 ` Lad, Prabhakar 2022-12-15 11:03 ` Lad, Prabhakar 2022-12-15 11:10 ` Geert Uytterhoeven 2022-12-15 11:10 ` Geert Uytterhoeven 2022-12-15 17:46 ` Lad, Prabhakar 2022-12-15 17:46 ` Lad, Prabhakar 2022-12-15 19:54 ` Conor Dooley 2022-12-15 19:54 ` Conor Dooley 2022-12-15 20:17 ` Geert Uytterhoeven 2022-12-15 20:17 ` Geert Uytterhoeven 2022-12-15 20:32 ` Conor Dooley 2022-12-15 20:32 ` Conor Dooley 2022-12-15 21:40 ` Palmer Dabbelt 2022-12-15 21:40 ` Palmer Dabbelt 2022-12-16 7:02 ` Christoph Hellwig 2022-12-16 7:02 ` Christoph Hellwig 2022-12-16 16:32 ` Palmer Dabbelt 2022-12-16 16:32 ` Palmer Dabbelt 2022-12-16 20:04 ` Arnd Bergmann 2022-12-16 20:04 ` Arnd Bergmann 2022-12-17 22:52 ` Conor Dooley 2022-12-17 22:52 ` Conor Dooley 2022-12-19 12:43 ` Lad, Prabhakar 2022-12-19 12:43 ` Lad, Prabhakar 2022-12-19 16:08 ` Conor Dooley 2022-12-19 16:08 ` Conor Dooley 2022-12-29 14:05 ` Arnd Bergmann 2022-12-29 14:05 ` Arnd Bergmann 2022-12-29 14:42 ` Conor Dooley 2022-12-29 14:42 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 0/9] Generic function based cache management operations (was Re: [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC) Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 1/9] riscv: asm: alternative-macros: Introduce ALTERNATIVE_3() macro Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 2/9] riscv: asm: vendorid_list: Add Andes Technology to the vendors list Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 3/9] riscv: errata: Add Andes alternative ports Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 4/9] riscv: mm: dma-noncoherent: Pass direction and operation to ALT_CMO_OP() Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 5/9] dt-bindings: cache: r9a07g043f-l2-cache: Add DT binding documentation for L2 cache controller Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 6/9] cache,soc: Move SiFive CCache driver & create drivers/cache Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-04 9:50 ` Ben Dooks 2023-01-04 9:50 ` Ben Dooks 2023-01-04 10:18 ` Conor Dooley 2023-01-04 10:18 ` Conor Dooley 2023-01-03 21:03 ` [RFC v5.1 7/9] RISC-V: create a function based cache management interface Conor Dooley 2023-01-03 21:03 ` Conor Dooley 2023-01-03 21:04 ` [RFC v5.1 8/9] soc: renesas: Add L2 cache management for RZ/Five SoC Conor Dooley 2023-01-03 21:04 ` Conor Dooley 2023-01-03 21:04 ` [RFC v5.1 9/9] [DON'T APPLY] cache: sifive-ccache: add cache flushing capability Conor Dooley 2023-01-03 21:04 ` Conor Dooley 2023-01-03 21:25 ` Palmer Dabbelt 2023-01-03 21:25 ` Palmer Dabbelt 2023-01-03 21:28 ` Arnd Bergmann 2023-01-03 21:28 ` Arnd Bergmann 2023-01-04 0:00 ` Conor Dooley 2023-01-04 0:00 ` Conor Dooley 2023-01-04 8:17 ` Arnd Bergmann 2023-01-04 8:17 ` Arnd Bergmann 2023-01-04 9:23 ` Conor Dooley 2023-01-04 9:23 ` Conor Dooley 2023-01-04 10:19 ` Arnd Bergmann 2023-01-04 10:19 ` Arnd Bergmann 2023-01-04 11:56 ` Conor Dooley [this message] 2023-01-04 11:56 ` Conor Dooley 2023-01-04 12:18 ` Arnd Bergmann 2023-01-04 12:18 ` Arnd Bergmann 2023-01-04 13:20 ` Conor Dooley 2023-01-04 13:20 ` Conor Dooley 2023-01-04 14:15 ` Arnd Bergmann 2023-01-04 14:15 ` Arnd Bergmann 2023-01-04 9:45 ` Ben Dooks 2023-01-04 9:45 ` Ben Dooks 2023-01-04 9:57 ` Conor Dooley 2023-01-04 9:57 ` Conor Dooley 2022-12-17 21:35 ` [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC Conor Dooley 2022-12-17 21:35 ` Conor Dooley 2022-12-28 3:16 ` Samuel Holland 2022-12-28 3:16 ` Samuel Holland
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=Y7VpeK48nslxklkF@spud \ --to=conor@kernel.org \ --cc=ajones@ventanamicro.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=arnd@arndb.de \ --cc=atishp@rivosinc.com \ --cc=biju.das.jz@bp.renesas.com \ --cc=conor.dooley@microchip.com \ --cc=daire.mcnamara@microchip.com \ --cc=devicetree@vger.kernel.org \ --cc=geert@linux-m68k.org \ --cc=guoren@kernel.org \ --cc=hch@infradead.org \ --cc=heiko@sntech.de \ --cc=jszhang@kernel.org \ --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 \ --cc=samuel@sholland.org \ --cc=soc@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: linkBe 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.