From: Palmer Dabbelt <palmer@dabbelt.com> To: geert@linux-m68k.org, Christoph Hellwig <hch@infradead.org>, soc@kernel.org Cc: Conor Dooley <conor@kernel.org>, prabhakar.csengg@gmail.com, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, magnus.damm@gmail.com, heiko@sntech.de, Conor Dooley <conor.dooley@microchip.com>, samuel@sholland.org, guoren@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, jszhang@kernel.org, Atish Patra <atishp@rivosinc.com>, apatel@ventanamicro.com, ajones@ventanamicro.com, nathan@kernel.org, philipp.tomsich@vrull.eu, devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, biju.das.jz@bp.renesas.com, prabhakar.mahadev-lad.rj@bp.renesas.com Subject: Re: [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC Date: Thu, 15 Dec 2022 13:40:30 -0800 (PST) [thread overview] Message-ID: <mhng-6160c058-408a-4ff5-8a7d-4fb2886d3d95@palmer-ri-x1c9a> (raw) In-Reply-To: <CAMuHMdUO7iFvh73u+m=EXYyxyePXHahJ=OVwQHdt0ap4vWDG4A@mail.gmail.com> On Thu, 15 Dec 2022 12:17:38 PST (-0800), geert@linux-m68k.org wrote: > Hi Conor, > > On Thu, Dec 15, 2022 at 8:54 PM Conor Dooley <conor@kernel.org> wrote: >> On Thu, Dec 15, 2022 at 05:46:42PM +0000, Lad, Prabhakar wrote: >> > On Thu, Dec 15, 2022 at 11:10 AM Geert Uytterhoeven >> > <geert@linux-m68k.org> wrote: >> > > On Thu, Dec 15, 2022 at 12:06 PM Lad, Prabhakar >> > > <prabhakar.csengg@gmail.com> wrote: >> > > > On Thu, Dec 15, 2022 at 10:36 AM Geert Uytterhoeven >> > > > <geert@linux-m68k.org> wrote: >> > > > > On Mon, Dec 12, 2022 at 12:58 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: >> > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> > > > > > >> > > > > > I/O Coherence Port (IOCP) provides an AXI interface for connecting >> > > > > > external non-caching masters, such as DMA controllers. The accesses >> > > > > > from IOCP are coherent with D-Caches and L2 Cache. >> > > > > > >> > > > > > IOCP is a specification option and is disabled on the Renesas RZ/Five >> > > > > > SoC due to this reason IP blocks using DMA will fail. >> > > > > > >> > > > > > 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 >> > > > > > >> > > > > > More info about PMA (section 10.3): >> > > > > > Link: http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf >> > > > > > >> > > > > > As a workaround for SoCs with IOCP disabled CMO needs to be handled by >> > > > > > software. Firstly OpenSBI configures the memory region as >> > > > > > "Memory, Non-cacheable, Bufferable" and passes this region as a global >> > > > > > shared dma pool as a DT node. With DMA_GLOBAL_POOL enabled all DMA >> > > > > > allocations happen from this region and synchronization callbacks are >> > > > > > implemented to synchronize when doing DMA transactions. >> > > > > > >> > > > > > Example PMA region passes as a DT node from OpenSBI: >> > > > > > reserved-memory { >> > > > > > #address-cells = <2>; >> > > > > > #size-cells = <2>; >> > > > > > ranges; >> > > > > > >> > > > > > pma_resv0@58000000 { >> > > > > > compatible = "shared-dma-pool"; >> > > > > > reg = <0x0 0x58000000 0x0 0x08000000>; >> > > > > > no-map; >> > > > > > linux,dma-default; >> > > > > > }; >> > > > > > }; >> > > > > > >> > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> > > > > >> > > > > Thanks for your patch! >> > > > > >> > > > > > arch/riscv/include/asm/cacheflush.h | 8 + >> > > > > > arch/riscv/include/asm/errata_list.h | 28 ++- >> > > > > > drivers/soc/renesas/Kconfig | 6 + >> > > > > > drivers/soc/renesas/Makefile | 2 + >> > > > > > drivers/soc/renesas/rzfive/Kconfig | 6 + >> > > > > > drivers/soc/renesas/rzfive/Makefile | 3 + >> > > > > > drivers/soc/renesas/rzfive/ax45mp_cache.c | 256 ++++++++++++++++++++++ >> > > > > >> > > > > Given this touches arch/riscv/include/asm/, I don't think the >> > > > > code belongs under drivers/soc/renesas/. >> > > > > >> > > > Ok. Do you have any suggestions on where you want me to put this code? >> > > >> > > As it plugs into core riscv functionality, I think it should be under >> > > arch/riscv/. >> > > if the RISC-V maintainers object to that, another option is >> > > drivers/soc/andestech/ or (new) drivers/cache/ >> > > >> > RISC-V maintainers had already made it clear to not to include vendor >> > specific stuff in the arch/riscv folder, so I'll consider putting this We have vendor-specific behavior in arch/riscv now, and it's even in the policies (the behavior has been there for a while, the policy is new). There's probably a bunch of posts saying otherwise because we used to not take vendor-specific behavior, but that's not the case any more. >> > into drivers/cache/ folder to sync with the bindings. >> > >> > Conor/Palmer - do you have any objections/suggestions? >> >> I'm not its maintainer so sorta moot what I say, but having drivers in >> arch/riscv makes little sense to me.. Some drivers are pretty tightly coupled to an ISA, I'm thinking of things like interrupts/timers where we're writing CSRs. I could see how cache controllers would fall into that category, doubly so as they get integrated to the memory model. That leaves us in sort of a grey area and there's certainly ports that have way more drivers in arch so it's not an uncommon way to do things. I generally lean pretty heavily towards keeping things that could at all be considered out of arch/riscv and instead have them in some sort of driver folder. That probably results in more total work to do, as we've got to have arch/riscv interfaces with one use case and sync up between multiple trees sometimes to get stuff merged. I think it also results in better code: being closer to the other drivers makes us more likely to get reviewed by folks who understand the space, and it's generally easier to share code in the subsystems. >> Putting stuff in drivers/cache does sound like a good idea since the >> binding is going there too. >> >> The SiFive ccache driver is in drivers/soc and it was suggested to me >> this week that there's likely going to be a second SiFive cache driver >> at some point in the near future. Plus Microchip are going to have to >> add cache management stuff to the existing SiFive ccache driver. >> Having them be their own thing makes sense in my mind - especially since >> they're not tied to SoCs sold by Andes or SiFive. >> >> I had a quick, and I mean *quick* look through other soc drivers to see >> if there were any other cache controller drivers but nothing stood out >> to me. Maybe someone else has more of a clue there. Ditto for misc, had >> a look but nothing seemed obvious. > > Usually they're under arch/: > $ git ls-files -- "arch/*cache*" | wc -l > 148 > $ git ls-files -- "drivers/*cache*" | wc -l > 63 > > E.g. arch/arm/mm/cache-l2x0.c. Above all I like to do things as normally as possible, so if most cache drivers are in arch then I'm OK with. Looks like we originally had it arch/riscv, though, until 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc") moved it out. I don't really remember this history/rationale here, at the time the SiFive cache driver wasn't really doing anything all that exciting: it was just way enable and some statistics, we hadn't really planned on using it for the non-coherent stuff that folks are now trying to retrofit it to handle. That sort of thing makes it a lot more coupled to the ISA. Given that we already moved the SiFive one out it seems sane to just start with the rest in drivers/soc/$VENDOR. Looks like it was Christoph's idea to do the move, so I'm adding him in case he's got an opinion (and also the SOC alias, as that seems generally relevant). > Gr{oetje,eeting}s, > > Geert
WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com> To: geert@linux-m68k.org, Christoph Hellwig <hch@infradead.org>, soc@kernel.org Cc: Conor Dooley <conor@kernel.org>, prabhakar.csengg@gmail.com, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, magnus.damm@gmail.com, heiko@sntech.de, Conor Dooley <conor.dooley@microchip.com>, samuel@sholland.org, guoren@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, jszhang@kernel.org, Atish Patra <atishp@rivosinc.com>, apatel@ventanamicro.com, ajones@ventanamicro.com, nathan@kernel.org, philipp.tomsich@vrull.eu, devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, biju.das.jz@bp.renesas.com, prabhakar.mahadev-lad.rj@bp.renesas.com Subject: Re: [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC Date: Thu, 15 Dec 2022 13:40:30 -0800 (PST) [thread overview] Message-ID: <mhng-6160c058-408a-4ff5-8a7d-4fb2886d3d95@palmer-ri-x1c9a> (raw) In-Reply-To: <CAMuHMdUO7iFvh73u+m=EXYyxyePXHahJ=OVwQHdt0ap4vWDG4A@mail.gmail.com> On Thu, 15 Dec 2022 12:17:38 PST (-0800), geert@linux-m68k.org wrote: > Hi Conor, > > On Thu, Dec 15, 2022 at 8:54 PM Conor Dooley <conor@kernel.org> wrote: >> On Thu, Dec 15, 2022 at 05:46:42PM +0000, Lad, Prabhakar wrote: >> > On Thu, Dec 15, 2022 at 11:10 AM Geert Uytterhoeven >> > <geert@linux-m68k.org> wrote: >> > > On Thu, Dec 15, 2022 at 12:06 PM Lad, Prabhakar >> > > <prabhakar.csengg@gmail.com> wrote: >> > > > On Thu, Dec 15, 2022 at 10:36 AM Geert Uytterhoeven >> > > > <geert@linux-m68k.org> wrote: >> > > > > On Mon, Dec 12, 2022 at 12:58 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: >> > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> > > > > > >> > > > > > I/O Coherence Port (IOCP) provides an AXI interface for connecting >> > > > > > external non-caching masters, such as DMA controllers. The accesses >> > > > > > from IOCP are coherent with D-Caches and L2 Cache. >> > > > > > >> > > > > > IOCP is a specification option and is disabled on the Renesas RZ/Five >> > > > > > SoC due to this reason IP blocks using DMA will fail. >> > > > > > >> > > > > > 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 >> > > > > > >> > > > > > More info about PMA (section 10.3): >> > > > > > Link: http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf >> > > > > > >> > > > > > As a workaround for SoCs with IOCP disabled CMO needs to be handled by >> > > > > > software. Firstly OpenSBI configures the memory region as >> > > > > > "Memory, Non-cacheable, Bufferable" and passes this region as a global >> > > > > > shared dma pool as a DT node. With DMA_GLOBAL_POOL enabled all DMA >> > > > > > allocations happen from this region and synchronization callbacks are >> > > > > > implemented to synchronize when doing DMA transactions. >> > > > > > >> > > > > > Example PMA region passes as a DT node from OpenSBI: >> > > > > > reserved-memory { >> > > > > > #address-cells = <2>; >> > > > > > #size-cells = <2>; >> > > > > > ranges; >> > > > > > >> > > > > > pma_resv0@58000000 { >> > > > > > compatible = "shared-dma-pool"; >> > > > > > reg = <0x0 0x58000000 0x0 0x08000000>; >> > > > > > no-map; >> > > > > > linux,dma-default; >> > > > > > }; >> > > > > > }; >> > > > > > >> > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> > > > > >> > > > > Thanks for your patch! >> > > > > >> > > > > > arch/riscv/include/asm/cacheflush.h | 8 + >> > > > > > arch/riscv/include/asm/errata_list.h | 28 ++- >> > > > > > drivers/soc/renesas/Kconfig | 6 + >> > > > > > drivers/soc/renesas/Makefile | 2 + >> > > > > > drivers/soc/renesas/rzfive/Kconfig | 6 + >> > > > > > drivers/soc/renesas/rzfive/Makefile | 3 + >> > > > > > drivers/soc/renesas/rzfive/ax45mp_cache.c | 256 ++++++++++++++++++++++ >> > > > > >> > > > > Given this touches arch/riscv/include/asm/, I don't think the >> > > > > code belongs under drivers/soc/renesas/. >> > > > > >> > > > Ok. Do you have any suggestions on where you want me to put this code? >> > > >> > > As it plugs into core riscv functionality, I think it should be under >> > > arch/riscv/. >> > > if the RISC-V maintainers object to that, another option is >> > > drivers/soc/andestech/ or (new) drivers/cache/ >> > > >> > RISC-V maintainers had already made it clear to not to include vendor >> > specific stuff in the arch/riscv folder, so I'll consider putting this We have vendor-specific behavior in arch/riscv now, and it's even in the policies (the behavior has been there for a while, the policy is new). There's probably a bunch of posts saying otherwise because we used to not take vendor-specific behavior, but that's not the case any more. >> > into drivers/cache/ folder to sync with the bindings. >> > >> > Conor/Palmer - do you have any objections/suggestions? >> >> I'm not its maintainer so sorta moot what I say, but having drivers in >> arch/riscv makes little sense to me.. Some drivers are pretty tightly coupled to an ISA, I'm thinking of things like interrupts/timers where we're writing CSRs. I could see how cache controllers would fall into that category, doubly so as they get integrated to the memory model. That leaves us in sort of a grey area and there's certainly ports that have way more drivers in arch so it's not an uncommon way to do things. I generally lean pretty heavily towards keeping things that could at all be considered out of arch/riscv and instead have them in some sort of driver folder. That probably results in more total work to do, as we've got to have arch/riscv interfaces with one use case and sync up between multiple trees sometimes to get stuff merged. I think it also results in better code: being closer to the other drivers makes us more likely to get reviewed by folks who understand the space, and it's generally easier to share code in the subsystems. >> Putting stuff in drivers/cache does sound like a good idea since the >> binding is going there too. >> >> The SiFive ccache driver is in drivers/soc and it was suggested to me >> this week that there's likely going to be a second SiFive cache driver >> at some point in the near future. Plus Microchip are going to have to >> add cache management stuff to the existing SiFive ccache driver. >> Having them be their own thing makes sense in my mind - especially since >> they're not tied to SoCs sold by Andes or SiFive. >> >> I had a quick, and I mean *quick* look through other soc drivers to see >> if there were any other cache controller drivers but nothing stood out >> to me. Maybe someone else has more of a clue there. Ditto for misc, had >> a look but nothing seemed obvious. > > Usually they're under arch/: > $ git ls-files -- "arch/*cache*" | wc -l > 148 > $ git ls-files -- "drivers/*cache*" | wc -l > 63 > > E.g. arch/arm/mm/cache-l2x0.c. Above all I like to do things as normally as possible, so if most cache drivers are in arch then I'm OK with. Looks like we originally had it arch/riscv, though, until 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc") moved it out. I don't really remember this history/rationale here, at the time the SiFive cache driver wasn't really doing anything all that exciting: it was just way enable and some statistics, we hadn't really planned on using it for the non-coherent stuff that folks are now trying to retrofit it to handle. That sort of thing makes it a lot more coupled to the ISA. Given that we already moved the SiFive one out it seems sane to just start with the rest in drivers/soc/$VENDOR. Looks like it was Christoph's idea to do the move, so I'm adding him in case he's got an opinion (and also the SOC alias, as that seems generally relevant). > Gr{oetje,eeting}s, > > Geert _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-12-15 21:40 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 [this message] 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 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=mhng-6160c058-408a-4ff5-8a7d-4fb2886d3d95@palmer-ri-x1c9a \ --to=palmer@dabbelt.com \ --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=conor@kernel.org \ --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=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.