From: Conor Dooley <conor@kernel.org> To: Arnd Bergmann <arnd@arndb.de>, palmer@dabbelt.com 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 13:20:13 +0000 [thread overview] Message-ID: <Y7V9Debcc9lqWBmT@spud> (raw) In-Reply-To: <1b7d4caa-2c9c-4aef-81ac-47288d3a652c@app.fastmail.com> [-- Attachment #1: Type: text/plain, Size: 3018 bytes --] On Wed, Jan 04, 2023 at 01:18:45PM +0100, Arnd Bergmann wrote: > On Wed, Jan 4, 2023, at 12:56, Conor Dooley wrote: > > On Wed, Jan 04, 2023 at 11:19:44AM +0100, Arnd Bergmann wrote: > >> On Wed, Jan 4, 2023, at 10:23, Conor Dooley wrote: > >> 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? > > Yes, exactly. > > > 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. > > That is the idea, and ALT_CMO_OP() itself can just go away > as by just putting the inline asm without the alternative into > the zicbom_cache_clean() version, making the THEAD branch yet > another cache_maint_ops instance. Perhaps more of a question for Palmer than you, but how about leaving ALT_CMO_OP as-is in riscv/for-next at the moment, wrapping it in zicbom_cache_foo() & leaving that extraction for a follow-on work? There's another conversation going on about expanding the THEAD stuff, so that could be done on top of Prabhakar's v6. That series is here: https://lore.kernel.org/linux-riscv/CAJF2gTQp1bOp9kfoOkbvNnSXQhzrCpG3rn8C+LPPoJtMCCDOdA@mail.gmail.com/T/#t Although unfortunately Icenowy is having issues getting their patches to the lists so I assume it'll get let through at some point today. > >> 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. > > I only see them in arch/riscv/mm/dma-noncoherent.c and arch/riscv/mm/pmem.c, > but yes, both of these should just call the new functions, whatever the > calling conventions end up being. Dunno why I had it in my head there was a third place. Seeing ghosts maybe! Thanks, 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>, palmer@dabbelt.com 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 13:20:13 +0000 [thread overview] Message-ID: <Y7V9Debcc9lqWBmT@spud> (raw) In-Reply-To: <1b7d4caa-2c9c-4aef-81ac-47288d3a652c@app.fastmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3018 bytes --] On Wed, Jan 04, 2023 at 01:18:45PM +0100, Arnd Bergmann wrote: > On Wed, Jan 4, 2023, at 12:56, Conor Dooley wrote: > > On Wed, Jan 04, 2023 at 11:19:44AM +0100, Arnd Bergmann wrote: > >> On Wed, Jan 4, 2023, at 10:23, Conor Dooley wrote: > >> 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? > > Yes, exactly. > > > 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. > > That is the idea, and ALT_CMO_OP() itself can just go away > as by just putting the inline asm without the alternative into > the zicbom_cache_clean() version, making the THEAD branch yet > another cache_maint_ops instance. Perhaps more of a question for Palmer than you, but how about leaving ALT_CMO_OP as-is in riscv/for-next at the moment, wrapping it in zicbom_cache_foo() & leaving that extraction for a follow-on work? There's another conversation going on about expanding the THEAD stuff, so that could be done on top of Prabhakar's v6. That series is here: https://lore.kernel.org/linux-riscv/CAJF2gTQp1bOp9kfoOkbvNnSXQhzrCpG3rn8C+LPPoJtMCCDOdA@mail.gmail.com/T/#t Although unfortunately Icenowy is having issues getting their patches to the lists so I assume it'll get let through at some point today. > >> 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. > > I only see them in arch/riscv/mm/dma-noncoherent.c and arch/riscv/mm/pmem.c, > but yes, both of these should just call the new functions, whatever the > calling conventions end up being. Dunno why I had it in my head there was a third place. Seeing ghosts maybe! Thanks, 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 13:20 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 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 [this message] 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=Y7V9Debcc9lqWBmT@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.