From: "Arnd Bergmann" <arnd@arndb.de> To: "Christoph Hellwig" <hch@lst.de> Cc: 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>, "open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org>, devicetree@vger.kernel.org, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>, "Philipp Tomsich" <philipp.tomsich@vrull.eu>, "Nathan Chancellor" <nathan@kernel.org>, "Atish Patra" <atishp@rivosinc.com>, "Anup Patel" <apatel@ventanamicro.com>, "Tsukasa OI" <research_trasio@irq.a4lg.com>, "Jisheng Zhang" <jszhang@kernel.org>, "Mayuresh Chitale" <mchitale@ventanamicro.com>, "Will Deacon" <will@kernel.org> Subject: Re: [RFC PATCH v6 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management Date: Sun, 22 Jan 2023 12:04:35 +0100 [thread overview] Message-ID: <7ad668ba-d6f3-4ef9-9335-e42bfe8d4cce@app.fastmail.com> (raw) In-Reply-To: <20230122072759.GA3703@lst.de> On Sun, Jan 22, 2023, at 08:27, Christoph Hellwig wrote: > On Sat, Jan 21, 2023 at 08:30:23PM +0100, Arnd Bergmann wrote: >> I was thinking of using STATIC_CALL() as an optimization here, which >> I find easier to read and understand than alternatives. One advantage >> here is that this allows the actual cache operations to be declared >> locally in the architecture without letting drivers call them, >> but still update the common code to work without indirect branches. >> >> The main downside is that this is currently only optimized on >> powerpc and x86, both of which don't actually need CPU specific >> callbacks. ARC, ARM, and MIPS on the other hand already >> have indirect function pointers, RISC-V would likely benefit the >> most from either alternatives or static_call, as it already >> uses alternatives and has one implementation that is clearly >> preferred over the others. > > For now I'd just keep doing direct calls into the arch code, just > for the lower level invalidate, writeback, invalidate+writeback > calls as that helps cementinc the logic of which of those to use > in well documented core code. Ok. > And I'm not really sure I'd like to go beyond that - making it too > easy pluggable will make people feel more comfortable doing stupid > things here. I fear the bigger risk is still making the functions callable from device driver code than it is to make the functions globally settable. You introduced the mips version in f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms"), which was clearly meant as an implementation detail, yet we already have a driver that slipped in with 3bdffa8ffb45 ("Input: Add N64 controller driver") that just calls this directly rather than using the dma-mapping interface. On the other hand, the indirect function pointers for per-cpu cache operations are not easily translated anyway: with the three architectures that multiplex between cpu specific operations, arc uses physical addresses, mips uses virtual addresses (because of highmem), and arm even uses both because of incompatible requirements between l1 and l2 cache operations. arm32 also seems to have the superset of all possible corner cases that one might see elsewhere (prefetching vs in-order, writethrough vs writeback, broken broadcast invalidation, ...). > And yes, maybe that's personal because I've warned > the RISC-V people years ago that they'll need architectural > cache management instructions yesterday and the answer was that > no one is going to use them on modern CPUs. *sigh* To be fair, from the ISA point of view, it really shouldn't be necessary as long as you have a sane SoC design. In practice there are always chips that are cutting corners, or use the new CPU core as a drop-in for an existing design. Arm SBSA tried to enforce the same thing and also failed for pretty much the same reason. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de> To: "Christoph Hellwig" <hch@lst.de> Cc: 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>, "open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org>, devicetree@vger.kernel.org, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>, "Philipp Tomsich" <philipp.tomsich@vrull.eu>, "Nathan Chancellor" <nathan@kernel.org>, "Atish Patra" <atishp@rivosinc.com>, "Anup Patel" <apatel@ventanamicro.com>, "Tsukasa OI" <research_trasio@irq.a4lg.com>, "Jisheng Zhang" <jszhang@kernel.org>, "Mayuresh Chitale" <mchitale@ventanamicro.com>, "Will Deacon" <will@kernel.org> Subject: Re: [RFC PATCH v6 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management Date: Sun, 22 Jan 2023 12:04:35 +0100 [thread overview] Message-ID: <7ad668ba-d6f3-4ef9-9335-e42bfe8d4cce@app.fastmail.com> (raw) In-Reply-To: <20230122072759.GA3703@lst.de> On Sun, Jan 22, 2023, at 08:27, Christoph Hellwig wrote: > On Sat, Jan 21, 2023 at 08:30:23PM +0100, Arnd Bergmann wrote: >> I was thinking of using STATIC_CALL() as an optimization here, which >> I find easier to read and understand than alternatives. One advantage >> here is that this allows the actual cache operations to be declared >> locally in the architecture without letting drivers call them, >> but still update the common code to work without indirect branches. >> >> The main downside is that this is currently only optimized on >> powerpc and x86, both of which don't actually need CPU specific >> callbacks. ARC, ARM, and MIPS on the other hand already >> have indirect function pointers, RISC-V would likely benefit the >> most from either alternatives or static_call, as it already >> uses alternatives and has one implementation that is clearly >> preferred over the others. > > For now I'd just keep doing direct calls into the arch code, just > for the lower level invalidate, writeback, invalidate+writeback > calls as that helps cementinc the logic of which of those to use > in well documented core code. Ok. > And I'm not really sure I'd like to go beyond that - making it too > easy pluggable will make people feel more comfortable doing stupid > things here. I fear the bigger risk is still making the functions callable from device driver code than it is to make the functions globally settable. You introduced the mips version in f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms"), which was clearly meant as an implementation detail, yet we already have a driver that slipped in with 3bdffa8ffb45 ("Input: Add N64 controller driver") that just calls this directly rather than using the dma-mapping interface. On the other hand, the indirect function pointers for per-cpu cache operations are not easily translated anyway: with the three architectures that multiplex between cpu specific operations, arc uses physical addresses, mips uses virtual addresses (because of highmem), and arm even uses both because of incompatible requirements between l1 and l2 cache operations. arm32 also seems to have the superset of all possible corner cases that one might see elsewhere (prefetching vs in-order, writethrough vs writeback, broken broadcast invalidation, ...). > And yes, maybe that's personal because I've warned > the RISC-V people years ago that they'll need architectural > cache management instructions yesterday and the answer was that > no one is going to use them on modern CPUs. *sigh* To be fair, from the ISA point of view, it really shouldn't be necessary as long as you have a sane SoC design. In practice there are always chips that are cutting corners, or use the new CPU core as a drop-in for an existing design. Arm SBSA tried to enforce the same thing and also failed for pretty much the same reason. Arnd _______________________________________________ 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-22 11:05 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-06 18:55 [PATCH v6 0/6] RISC-V non-coherent function pointer based cache management operations + non-coherent DMA support for AX45MP Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 18:55 ` [RFC PATCH v6 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 22:31 ` Arnd Bergmann 2023-01-06 23:29 ` Conor Dooley 2023-01-06 23:29 ` Conor Dooley 2023-01-07 21:52 ` Arnd Bergmann 2023-01-07 21:52 ` Arnd Bergmann 2023-01-07 22:21 ` Conor Dooley 2023-01-07 22:21 ` Conor Dooley 2023-01-08 16:37 ` Conor Dooley 2023-01-08 16:37 ` Conor Dooley 2023-01-07 22:10 ` Lad, Prabhakar 2023-01-07 22:10 ` Lad, Prabhakar 2023-01-08 0:07 ` Arnd Bergmann 2023-01-08 0:07 ` Arnd Bergmann 2023-01-09 12:03 ` Lad, Prabhakar 2023-01-09 12:03 ` Lad, Prabhakar 2023-01-09 12:59 ` Arnd Bergmann 2023-01-09 12:59 ` Arnd Bergmann 2023-01-09 13:27 ` Conor Dooley 2023-01-09 13:27 ` Conor Dooley 2023-01-10 7:01 ` Christoph Hellwig 2023-01-10 7:01 ` Christoph Hellwig 2023-01-10 15:03 ` Arnd Bergmann 2023-01-10 15:03 ` Arnd Bergmann 2023-01-10 15:11 ` Will Deacon 2023-01-10 15:11 ` Will Deacon 2023-01-13 5:48 ` Christoph Hellwig 2023-01-13 5:48 ` Christoph Hellwig 2023-01-20 17:04 ` Arnd Bergmann 2023-01-20 17:04 ` Arnd Bergmann 2023-01-21 14:37 ` Christoph Hellwig 2023-01-21 14:37 ` Christoph Hellwig 2023-01-21 19:30 ` Arnd Bergmann 2023-01-21 19:30 ` Arnd Bergmann 2023-01-22 7:27 ` Christoph Hellwig 2023-01-22 7:27 ` Christoph Hellwig 2023-01-22 11:04 ` Arnd Bergmann [this message] 2023-01-22 11:04 ` Arnd Bergmann 2023-01-23 14:46 ` Christoph Hellwig 2023-01-23 14:46 ` Christoph Hellwig 2023-01-06 23:47 ` Conor Dooley 2023-01-06 23:47 ` Conor Dooley 2023-01-07 22:36 ` Lad, Prabhakar 2023-01-07 22:36 ` Lad, Prabhakar 2023-01-06 18:55 ` [PATCH v6 2/6] riscv: asm: vendorid_list: Add Andes Technology to the vendors list Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 18:55 ` [PATCH v6 3/6] riscv: errata: Add Andes alternative ports Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 21:44 ` Conor Dooley 2023-01-06 21:44 ` Conor Dooley 2023-01-06 18:55 ` [PATCH v6 4/6] dt-bindings: cache: r9a07g043f-l2-cache: Add DT binding documentation for L2 cache controller Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 21:53 ` Conor Dooley 2023-01-06 21:53 ` Conor Dooley 2023-01-07 20:43 ` Lad, Prabhakar 2023-01-07 20:43 ` Lad, Prabhakar 2023-01-09 12:15 ` Geert Uytterhoeven 2023-01-09 12:15 ` Geert Uytterhoeven 2023-01-09 13:14 ` Lad, Prabhakar 2023-01-09 13:14 ` Lad, Prabhakar 2023-01-06 18:55 ` [PATCH v6 5/6] cache: Add L2 cache management for Andes AX45MP RISC-V core Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-07 0:09 ` Conor Dooley 2023-01-07 0:09 ` Conor Dooley 2023-01-07 20:49 ` Lad, Prabhakar 2023-01-07 20:49 ` Lad, Prabhakar 2023-01-06 18:55 ` [PATCH v6 6/6] soc: renesas: Kconfig: Select the required configs for RZ/Five SoC Prabhakar 2023-01-06 18:55 ` Prabhakar 2023-01-06 23:49 ` Conor Dooley 2023-01-06 23:49 ` Conor Dooley
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=7ad668ba-d6f3-4ef9-9335-e42bfe8d4cce@app.fastmail.com \ --to=arnd@arndb.de \ --cc=ajones@ventanamicro.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=atishp@rivosinc.com \ --cc=conor.dooley@microchip.com \ --cc=devicetree@vger.kernel.org \ --cc=geert+renesas@glider.be \ --cc=guoren@kernel.org \ --cc=hch@lst.de \ --cc=heiko@sntech.de \ --cc=jszhang@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mchitale@ventanamicro.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=research_trasio@irq.a4lg.com \ --cc=will@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.