* [PATCH v2 0/4] Add PMEM support for RISC-V @ 2022-08-30 4:46 Anup Patel 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel ` (3 more replies) 0 siblings, 4 replies; 20+ messages in thread From: Anup Patel @ 2022-08-30 4:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Anup Patel The Linux NVDIMM PEM drivers require arch support to map and access the persistent memory device. This series adds RISC-V PMEM support using recently added Svpbmt and Zicbom support. These patches can also be found in riscv_pmem_v2 branch at: https://github.com/avpatel/linux.git Changes since v1: - Fix error reported by test bot https://lore.kernel.org/all/202208272028.IwrNZ0Ur-lkp@intel.com/ Anup Patel (4): RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c RISC-V: Implement arch specific PMEM APIs RISC-V: Enable PMEM drivers arch/riscv/Kconfig | 1 + arch/riscv/configs/defconfig | 1 + arch/riscv/include/asm/cacheflush.h | 2 ++ arch/riscv/include/asm/io.h | 10 ++++++++ arch/riscv/include/asm/pgtable.h | 2 ++ arch/riscv/mm/Makefile | 1 + arch/riscv/mm/cacheflush.c | 39 +++++++++++++++++++++++++++++ arch/riscv/mm/dma-noncoherent.c | 38 ---------------------------- arch/riscv/mm/pmem.c | 21 ++++++++++++++++ 9 files changed, 77 insertions(+), 38 deletions(-) create mode 100644 arch/riscv/mm/pmem.c -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-08-30 4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel @ 2022-08-30 4:46 ` Anup Patel 2022-09-01 15:25 ` Heiko Stübner ` (3 more replies) 2022-08-30 4:46 ` [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c Anup Patel ` (2 subsequent siblings) 3 siblings, 4 replies; 20+ messages in thread From: Anup Patel @ 2022-08-30 4:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale Currently, all flavors of ioremap_xyz() function maps to the generic ioremap() which means any ioremap_xyz() call will always map the target memory as IO using _PAGE_IOREMAP page attributes. This breaks ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP page attributes. To address above (just like other architectures), we implement RISC-V specific ioremap_cache() and ioremap_wc() which maps memory using page attributes as defined by the Svpbmt specification. Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- arch/riscv/include/asm/io.h | 10 ++++++++++ arch/riscv/include/asm/pgtable.h | 2 ++ 2 files changed, 12 insertions(+) diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h index 69605a474270..07ac63999575 100644 --- a/arch/riscv/include/asm/io.h +++ b/arch/riscv/include/asm/io.h @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) #endif +#ifdef CONFIG_MMU +#define ioremap_wc(addr, size) \ + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) +#endif + #include <asm-generic/io.h> +#ifdef CONFIG_MMU +#define ioremap_cache(addr, size) \ + ioremap_prot((addr), (size), _PAGE_KERNEL) +#endif + #endif /* _ASM_RISCV_IO_H */ diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 7ec936910a96..346b7c1a3eeb 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; #define PAGE_TABLE __pgprot(_PAGE_TABLE) #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ + _PAGE_NOCACHE) #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) extern pgd_t swapper_pg_dir[]; -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel @ 2022-09-01 15:25 ` Heiko Stübner 2022-09-01 16:07 ` Conor.Dooley ` (2 subsequent siblings) 3 siblings, 0 replies; 20+ messages in thread From: Heiko Stübner @ 2022-09-01 15:25 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Anup Patel Cc: Atish Patra, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale Am Dienstag, 30. August 2022, 06:46:39 CEST schrieb Anup Patel: > Currently, all flavors of ioremap_xyz() function maps to the generic > ioremap() which means any ioremap_xyz() call will always map the > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > page attributes. > > To address above (just like other architectures), we implement RISC-V > specific ioremap_cache() and ioremap_wc() which maps memory using page > attributes as defined by the Svpbmt specification. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> And at least on a qemu Tested-by: Heiko Stuebner <heiko@sntech.de> But it was running there before as well of course. Heiko > --- > arch/riscv/include/asm/io.h | 10 ++++++++++ > arch/riscv/include/asm/pgtable.h | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index 69605a474270..07ac63999575 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) > #endif > > +#ifdef CONFIG_MMU > +#define ioremap_wc(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > +#endif > + > #include <asm-generic/io.h> > > +#ifdef CONFIG_MMU > +#define ioremap_cache(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_KERNEL) > +#endif > + > #endif /* _ASM_RISCV_IO_H */ > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 7ec936910a96..346b7c1a3eeb 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > + _PAGE_NOCACHE) > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel 2022-09-01 15:25 ` Heiko Stübner @ 2022-09-01 16:07 ` Conor.Dooley 2022-09-09 8:10 ` Anup Patel 2022-09-16 2:24 ` Anup Patel 3 siblings, 0 replies; 20+ messages in thread From: Conor.Dooley @ 2022-09-01 16:07 UTC (permalink / raw) To: apatel, palmer, paul.walmsley Cc: atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On 30/08/2022 05:46, Anup Patel wrote: > Currently, all flavors of ioremap_xyz() function maps to the generic > ioremap() which means any ioremap_xyz() call will always map the > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > page attributes. > > To address above (just like other architectures), we implement RISC-V > specific ioremap_cache() and ioremap_wc() which maps memory using page > attributes as defined by the Svpbmt specification. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Seems sane to me too :) Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > --- > arch/riscv/include/asm/io.h | 10 ++++++++++ > arch/riscv/include/asm/pgtable.h | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index 69605a474270..07ac63999575 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) > #endif > > +#ifdef CONFIG_MMU > +#define ioremap_wc(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > +#endif > + > #include <asm-generic/io.h> > > +#ifdef CONFIG_MMU > +#define ioremap_cache(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_KERNEL) > +#endif > + > #endif /* _ASM_RISCV_IO_H */ > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 7ec936910a96..346b7c1a3eeb 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > + _PAGE_NOCACHE) > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel 2022-09-01 15:25 ` Heiko Stübner 2022-09-01 16:07 ` Conor.Dooley @ 2022-09-09 8:10 ` Anup Patel 2022-09-16 2:24 ` Anup Patel 3 siblings, 0 replies; 20+ messages in thread From: Anup Patel @ 2022-09-09 8:10 UTC (permalink / raw) To: Palmer Dabbelt Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Mayuresh Chitale, Paul Walmsley Hi Palmer, On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote: > > Currently, all flavors of ioremap_xyz() function maps to the generic > ioremap() which means any ioremap_xyz() call will always map the > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > page attributes. > > To address above (just like other architectures), we implement RISC-V > specific ioremap_cache() and ioremap_wc() which maps memory using page > attributes as defined by the Svpbmt specification. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Can you please consider this patch for Linux-6.0-rc5 ? Regards, Anup > --- > arch/riscv/include/asm/io.h | 10 ++++++++++ > arch/riscv/include/asm/pgtable.h | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index 69605a474270..07ac63999575 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) > #endif > > +#ifdef CONFIG_MMU > +#define ioremap_wc(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > +#endif > + > #include <asm-generic/io.h> > > +#ifdef CONFIG_MMU > +#define ioremap_cache(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_KERNEL) > +#endif > + > #endif /* _ASM_RISCV_IO_H */ > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 7ec936910a96..346b7c1a3eeb 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > + _PAGE_NOCACHE) > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > -- > 2.34.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel ` (2 preceding siblings ...) 2022-09-09 8:10 ` Anup Patel @ 2022-09-16 2:24 ` Anup Patel 2022-09-22 16:35 ` Palmer Dabbelt 3 siblings, 1 reply; 20+ messages in thread From: Anup Patel @ 2022-09-16 2:24 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Mayuresh Chitale Hi Palmer, On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote: > > Currently, all flavors of ioremap_xyz() function maps to the generic > ioremap() which means any ioremap_xyz() call will always map the > target memory as IO using _PAGE_IOREMAP page attributes. This breaks > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP > page attributes. > > To address above (just like other architectures), we implement RISC-V > specific ioremap_cache() and ioremap_wc() which maps memory using page > attributes as defined by the Svpbmt specification. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> This is a crucial RC fix. Can you please take this ? Regards, Anup > --- > arch/riscv/include/asm/io.h | 10 ++++++++++ > arch/riscv/include/asm/pgtable.h | 2 ++ > 2 files changed, 12 insertions(+) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index 69605a474270..07ac63999575 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) > #endif > > +#ifdef CONFIG_MMU > +#define ioremap_wc(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) > +#endif > + > #include <asm-generic/io.h> > > +#ifdef CONFIG_MMU > +#define ioremap_cache(addr, size) \ > + ioremap_prot((addr), (size), _PAGE_KERNEL) > +#endif > + > #endif /* _ASM_RISCV_IO_H */ > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 7ec936910a96..346b7c1a3eeb 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) > +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ > + _PAGE_NOCACHE) > #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > -- > 2.34.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-09-16 2:24 ` Anup Patel @ 2022-09-22 16:35 ` Palmer Dabbelt 2022-09-23 10:35 ` Arnd Bergmann 2022-09-28 12:14 ` Christoph Hellwig 0 siblings, 2 replies; 20+ messages in thread From: Palmer Dabbelt @ 2022-09-22 16:35 UTC (permalink / raw) To: apatel Cc: Paul Walmsley, atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@ventanamicro.com wrote: > Hi Palmer, > > On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote: >> >> Currently, all flavors of ioremap_xyz() function maps to the generic >> ioremap() which means any ioremap_xyz() call will always map the >> target memory as IO using _PAGE_IOREMAP page attributes. This breaks >> ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory >> remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP >> page attributes. >> >> To address above (just like other architectures), we implement RISC-V >> specific ioremap_cache() and ioremap_wc() which maps memory using page >> attributes as defined by the Svpbmt specification. >> >> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") >> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > This is a crucial RC fix. Can you please take this ? Sorry I missed this, I thought it was just part of the rest of this patch set. That said, I'm not actually sure this is a critical fix: sure it's a performance problem, and if some driver is expecting ioremap_cache() to go fast then possibly a pretty big one, but the only Svpmbt hardware that exists is the D1 and that was just supported this release so it's not a regression. Maybe that's a bit pedantic, but all this travel has kind of made things a mess and I'm trying to make sure nothing goes off the rails. Probably a pointless distinction as it'll just get backported anyway, but I'm going to hold off on this for now -- it generally looks OK, but I don't get back until this weekend and I'm super tired so I'm trying to avoid screwing anything up. > > Regards, > Anup > >> --- >> arch/riscv/include/asm/io.h | 10 ++++++++++ >> arch/riscv/include/asm/pgtable.h | 2 ++ >> 2 files changed, 12 insertions(+) >> >> diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h >> index 69605a474270..07ac63999575 100644 >> --- a/arch/riscv/include/asm/io.h >> +++ b/arch/riscv/include/asm/io.h >> @@ -133,6 +133,16 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) >> #define outsq(addr, buffer, count) __outsq((void __iomem *)addr, buffer, count) >> #endif >> >> +#ifdef CONFIG_MMU >> +#define ioremap_wc(addr, size) \ >> + ioremap_prot((addr), (size), _PAGE_IOREMAP_WC) >> +#endif >> + >> #include <asm-generic/io.h> >> >> +#ifdef CONFIG_MMU >> +#define ioremap_cache(addr, size) \ >> + ioremap_prot((addr), (size), _PAGE_KERNEL) >> +#endif >> + >> #endif /* _ASM_RISCV_IO_H */ >> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h >> index 7ec936910a96..346b7c1a3eeb 100644 >> --- a/arch/riscv/include/asm/pgtable.h >> +++ b/arch/riscv/include/asm/pgtable.h >> @@ -182,6 +182,8 @@ extern struct pt_alloc_ops pt_ops __initdata; >> #define PAGE_TABLE __pgprot(_PAGE_TABLE) >> >> #define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MTMASK) | _PAGE_IO) >> +#define _PAGE_IOREMAP_WC ((_PAGE_KERNEL & ~_PAGE_MTMASK) | \ >> + _PAGE_NOCACHE) >> #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) >> >> extern pgd_t swapper_pg_dir[]; >> -- >> 2.34.1 >> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-09-22 16:35 ` Palmer Dabbelt @ 2022-09-23 10:35 ` Arnd Bergmann 2022-09-23 10:45 ` Palmer Dabbelt 2022-09-28 12:14 ` Christoph Hellwig 1 sibling, 1 reply; 20+ messages in thread From: Arnd Bergmann @ 2022-09-23 10:35 UTC (permalink / raw) To: Palmer Dabbelt, Anup Patel Cc: Paul Walmsley, Atish Patra, Heiko Stübner, anup, linux-riscv, linux-kernel, mchitale On Thu, Sep 22, 2022, at 6:35 PM, Palmer Dabbelt wrote: > On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@ventanamicro.com wrote: >> >> On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote: >>> >>> Currently, all flavors of ioremap_xyz() function maps to the generic >>> ioremap() which means any ioremap_xyz() call will always map the >>> target memory as IO using _PAGE_IOREMAP page attributes. This breaks >>> ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory >>> remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP >>> page attributes. >>> >>> To address above (just like other architectures), we implement RISC-V >>> specific ioremap_cache() and ioremap_wc() which maps memory using page >>> attributes as defined by the Svpbmt specification. >>> >>> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") >>> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> >>> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >> >> This is a crucial RC fix. Can you please take this ? > > Sorry I missed this, I thought it was just part of the rest of this > patch set. That said, I'm not actually sure this is a critical fix: > sure it's a performance problem, and if some driver is expecting > ioremap_cache() to go fast then possibly a pretty big one, but the only > Svpmbt hardware that exists is the D1 and that was just supported this > release so it's not a regression. Maybe that's a bit pedantic, but all > this travel has kind of made things a mess and I'm trying to make sure > nothing goes off the rails. I think generally speaking any use of ioremap_cache() in a driver is a mistake. The few users that exist are usually from historic x86 specific code and are hard to kill off. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-09-23 10:35 ` Arnd Bergmann @ 2022-09-23 10:45 ` Palmer Dabbelt 0 siblings, 0 replies; 20+ messages in thread From: Palmer Dabbelt @ 2022-09-23 10:45 UTC (permalink / raw) To: Arnd Bergmann Cc: apatel, Paul Walmsley, atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On Fri, 23 Sep 2022 03:35:50 PDT (-0700), Arnd Bergmann wrote: > On Thu, Sep 22, 2022, at 6:35 PM, Palmer Dabbelt wrote: >> On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@ventanamicro.com wrote: >>> >>> On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@ventanamicro.com> wrote: >>>> >>>> Currently, all flavors of ioremap_xyz() function maps to the generic >>>> ioremap() which means any ioremap_xyz() call will always map the >>>> target memory as IO using _PAGE_IOREMAP page attributes. This breaks >>>> ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory >>>> remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP >>>> page attributes. >>>> >>>> To address above (just like other architectures), we implement RISC-V >>>> specific ioremap_cache() and ioremap_wc() which maps memory using page >>>> attributes as defined by the Svpbmt specification. >>>> >>>> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") >>>> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> >>>> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> >>>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >>> >>> This is a crucial RC fix. Can you please take this ? >> >> Sorry I missed this, I thought it was just part of the rest of this >> patch set. That said, I'm not actually sure this is a critical fix: >> sure it's a performance problem, and if some driver is expecting >> ioremap_cache() to go fast then possibly a pretty big one, but the only >> Svpmbt hardware that exists is the D1 and that was just supported this >> release so it's not a regression. Maybe that's a bit pedantic, but all >> this travel has kind of made things a mess and I'm trying to make sure >> nothing goes off the rails. > > I think generally speaking any use of ioremap_cache() in a driver > is a mistake. The few users that exist are usually from historic > x86 specific code and are hard to kill off. Should we just add some sort of CONFIG_ARCH_HAS_IOREMAP_CACHE and then ban those drivers from everywhere else? _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-09-22 16:35 ` Palmer Dabbelt 2022-09-23 10:35 ` Arnd Bergmann @ 2022-09-28 12:14 ` Christoph Hellwig 2022-10-07 3:50 ` Palmer Dabbelt 1 sibling, 1 reply; 20+ messages in thread From: Christoph Hellwig @ 2022-09-28 12:14 UTC (permalink / raw) To: Palmer Dabbelt Cc: apatel, Paul Walmsley, atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On Thu, Sep 22, 2022 at 09:35:56AM -0700, Palmer Dabbelt wrote: > Sorry I missed this, I thought it was just part of the rest of this patch > set. That said, I'm not actually sure this is a critical fix: sure it's a > performance problem, and if some driver is expecting ioremap_cache() to go > fast then possibly a pretty big one, but the only Svpmbt hardware that More importantly nothing should be using ioremap_cache at all. It is an API that has long been deprecated in favor of memremap. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-09-28 12:14 ` Christoph Hellwig @ 2022-10-07 3:50 ` Palmer Dabbelt 2022-10-07 5:34 ` Anup Patel 0 siblings, 1 reply; 20+ messages in thread From: Palmer Dabbelt @ 2022-10-07 3:50 UTC (permalink / raw) To: Christoph Hellwig Cc: apatel, Paul Walmsley, atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On Wed, 28 Sep 2022 05:14:30 PDT (-0700), Christoph Hellwig wrote: > On Thu, Sep 22, 2022 at 09:35:56AM -0700, Palmer Dabbelt wrote: >> Sorry I missed this, I thought it was just part of the rest of this patch >> set. That said, I'm not actually sure this is a critical fix: sure it's a >> performance problem, and if some driver is expecting ioremap_cache() to go >> fast then possibly a pretty big one, but the only Svpmbt hardware that > > More importantly nothing should be using ioremap_cache at all. It is > an API that has long been deprecated in favor of memremap. There's a few uses of it, I just send along a patch to make it arch-specific and make the users depend on it. That should let us stop adding this to ports just to get the drivers building. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt 2022-10-07 3:50 ` Palmer Dabbelt @ 2022-10-07 5:34 ` Anup Patel 0 siblings, 0 replies; 20+ messages in thread From: Anup Patel @ 2022-10-07 5:34 UTC (permalink / raw) To: Palmer Dabbelt Cc: Christoph Hellwig, apatel, Paul Walmsley, atishp, heiko, linux-riscv, linux-kernel, mchitale On Fri, Oct 7, 2022 at 9:20 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Wed, 28 Sep 2022 05:14:30 PDT (-0700), Christoph Hellwig wrote: > > On Thu, Sep 22, 2022 at 09:35:56AM -0700, Palmer Dabbelt wrote: > >> Sorry I missed this, I thought it was just part of the rest of this patch > >> set. That said, I'm not actually sure this is a critical fix: sure it's a > >> performance problem, and if some driver is expecting ioremap_cache() to go > >> fast then possibly a pretty big one, but the only Svpmbt hardware that > > > > More importantly nothing should be using ioremap_cache at all. It is > > an API that has long been deprecated in favor of memremap. > > There's a few uses of it, I just send along a patch to make it > arch-specific and make the users depend on it. That should let us stop > adding this to ports just to get the drivers building. I agree, ioremap_cache() should not be used by drivers. I encountered this issue with the PMEM driver which uses devm_memremap() which in-turn calls memremap() (kernel/iomem.c). The kernel memremap() still expects arch-specific ioremap_xyz() functions/macros to implement various MEMREMAP_xyz flags which is why we need these RISC-V specific ioremap_xyz(). An alternative way is to implement RISC-V specific arch_memremap_wb() but this will still look similar to ioremap_cache() added by this patch. Also, only 32bit ARM implements arch_memremap_wb() whereas all other archs (ARM64, x86_64, etc) implement ioremap_xyz() functions/macros. Regards, Anup _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c 2022-08-30 4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel @ 2022-08-30 4:46 ` Anup Patel 2022-09-01 15:29 ` Heiko Stübner 2022-08-30 4:46 ` [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs Anup Patel 2022-08-30 4:46 ` [PATCH v2 4/4] RISC-V: Enable PMEM drivers Anup Patel 3 siblings, 1 reply; 20+ messages in thread From: Anup Patel @ 2022-08-30 4:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale The riscv_cbom_block_size parsing from DT belongs to cacheflush.c which is home for all cache maintenance related stuff so let us move the riscv_init_cbom_blocksize() and riscv_cbom_block_size to cacheflush.c. Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- arch/riscv/include/asm/cacheflush.h | 2 ++ arch/riscv/mm/cacheflush.c | 39 +++++++++++++++++++++++++++++ arch/riscv/mm/dma-noncoherent.c | 38 ---------------------------- 3 files changed, 41 insertions(+), 38 deletions(-) diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h index a60acaecfeda..de55d6b8deeb 100644 --- a/arch/riscv/include/asm/cacheflush.h +++ b/arch/riscv/include/asm/cacheflush.h @@ -42,6 +42,8 @@ void flush_icache_mm(struct mm_struct *mm, bool local); #endif /* CONFIG_SMP */ +extern unsigned int riscv_cbom_block_size; + #ifdef CONFIG_RISCV_ISA_ZICBOM void riscv_init_cbom_blocksize(void); #else diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c index 6cb7d96ad9c7..336c5deea870 100644 --- a/arch/riscv/mm/cacheflush.c +++ b/arch/riscv/mm/cacheflush.c @@ -3,6 +3,8 @@ * Copyright (C) 2017 SiFive */ +#include <linux/of.h> +#include <linux/of_device.h> #include <asm/cacheflush.h> #ifdef CONFIG_SMP @@ -86,3 +88,40 @@ void flush_icache_pte(pte_t pte) flush_icache_all(); } #endif /* CONFIG_MMU */ + +unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; + +#ifdef CONFIG_RISCV_ISA_ZICBOM +void riscv_init_cbom_blocksize(void) +{ + struct device_node *node; + int ret; + u32 val; + + for_each_of_cpu_node(node) { + unsigned long hartid; + int cbom_hartid; + + ret = riscv_of_processor_hartid(node, &hartid); + if (ret) + continue; + + if (hartid < 0) + continue; + + /* set block-size for cbom extension if available */ + ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); + if (ret) + continue; + + if (!riscv_cbom_block_size) { + riscv_cbom_block_size = val; + cbom_hartid = hartid; + } else { + if (riscv_cbom_block_size != val) + pr_warn("cbom-block-size mismatched between harts %d and %lu\n", + cbom_hartid, hartid); + } + } +} +#endif diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c index cd2225304c82..3f502a1a68b1 100644 --- a/arch/riscv/mm/dma-noncoherent.c +++ b/arch/riscv/mm/dma-noncoherent.c @@ -8,11 +8,8 @@ #include <linux/dma-direct.h> #include <linux/dma-map-ops.h> #include <linux/mm.h> -#include <linux/of.h> -#include <linux/of_device.h> #include <asm/cacheflush.h> -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; static bool noncoherent_supported; void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, @@ -75,41 +72,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, dev->dma_coherent = coherent; } -#ifdef CONFIG_RISCV_ISA_ZICBOM -void riscv_init_cbom_blocksize(void) -{ - struct device_node *node; - int ret; - u32 val; - - for_each_of_cpu_node(node) { - unsigned long hartid; - int cbom_hartid; - - ret = riscv_of_processor_hartid(node, &hartid); - if (ret) - continue; - - if (hartid < 0) - continue; - - /* set block-size for cbom extension if available */ - ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); - if (ret) - continue; - - if (!riscv_cbom_block_size) { - riscv_cbom_block_size = val; - cbom_hartid = hartid; - } else { - if (riscv_cbom_block_size != val) - pr_warn("cbom-block-size mismatched between harts %d and %lu\n", - cbom_hartid, hartid); - } - } -} -#endif - void riscv_noncoherent_supported(void) { noncoherent_supported = true; -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c 2022-08-30 4:46 ` [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c Anup Patel @ 2022-09-01 15:29 ` Heiko Stübner 2022-09-01 15:49 ` Conor.Dooley 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2022-09-01 15:29 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Anup Patel Cc: Atish Patra, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale Hi, Am Dienstag, 30. August 2022, 06:46:40 CEST schrieb Anup Patel: > The riscv_cbom_block_size parsing from DT belongs to cacheflush.c which > is home for all cache maintenance related stuff so let us move the > riscv_init_cbom_blocksize() and riscv_cbom_block_size to cacheflush.c. > > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Makes a lot of sense to keep stuff together. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Also, can we handle this as fix patch? I.e. Currently the t-head code somewhat relies on the default value set to L1_CACHE_BYTES. The cache-block-size is static there. Palmers upcoming patch reworking the parsing [0], will remove that default, so having the riscv_cbom_block_size defined in the cacheflush header will allow an easy fix by setting that value from the t-head errata init for those cores. Heiko [0] https://lore.kernel.org/r/20220812154010.18280-1-palmer@rivosinc.com > --- > arch/riscv/include/asm/cacheflush.h | 2 ++ > arch/riscv/mm/cacheflush.c | 39 +++++++++++++++++++++++++++++ > arch/riscv/mm/dma-noncoherent.c | 38 ---------------------------- > 3 files changed, 41 insertions(+), 38 deletions(-) > > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h > index a60acaecfeda..de55d6b8deeb 100644 > --- a/arch/riscv/include/asm/cacheflush.h > +++ b/arch/riscv/include/asm/cacheflush.h > @@ -42,6 +42,8 @@ void flush_icache_mm(struct mm_struct *mm, bool local); > > #endif /* CONFIG_SMP */ > > +extern unsigned int riscv_cbom_block_size; > + > #ifdef CONFIG_RISCV_ISA_ZICBOM > void riscv_init_cbom_blocksize(void); > #else > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c > index 6cb7d96ad9c7..336c5deea870 100644 > --- a/arch/riscv/mm/cacheflush.c > +++ b/arch/riscv/mm/cacheflush.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2017 SiFive > */ > > +#include <linux/of.h> > +#include <linux/of_device.h> > #include <asm/cacheflush.h> > > #ifdef CONFIG_SMP > @@ -86,3 +88,40 @@ void flush_icache_pte(pte_t pte) > flush_icache_all(); > } > #endif /* CONFIG_MMU */ > + > +unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; > + > +#ifdef CONFIG_RISCV_ISA_ZICBOM > +void riscv_init_cbom_blocksize(void) > +{ > + struct device_node *node; > + int ret; > + u32 val; > + > + for_each_of_cpu_node(node) { > + unsigned long hartid; > + int cbom_hartid; > + > + ret = riscv_of_processor_hartid(node, &hartid); > + if (ret) > + continue; > + > + if (hartid < 0) > + continue; > + > + /* set block-size for cbom extension if available */ > + ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); > + if (ret) > + continue; > + > + if (!riscv_cbom_block_size) { > + riscv_cbom_block_size = val; > + cbom_hartid = hartid; > + } else { > + if (riscv_cbom_block_size != val) > + pr_warn("cbom-block-size mismatched between harts %d and %lu\n", > + cbom_hartid, hartid); > + } > + } > +} > +#endif > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index cd2225304c82..3f502a1a68b1 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -8,11 +8,8 @@ > #include <linux/dma-direct.h> > #include <linux/dma-map-ops.h> > #include <linux/mm.h> > -#include <linux/of.h> > -#include <linux/of_device.h> > #include <asm/cacheflush.h> > > -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; > static bool noncoherent_supported; > > void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, > @@ -75,41 +72,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, > dev->dma_coherent = coherent; > } > > -#ifdef CONFIG_RISCV_ISA_ZICBOM > -void riscv_init_cbom_blocksize(void) > -{ > - struct device_node *node; > - int ret; > - u32 val; > - > - for_each_of_cpu_node(node) { > - unsigned long hartid; > - int cbom_hartid; > - > - ret = riscv_of_processor_hartid(node, &hartid); > - if (ret) > - continue; > - > - if (hartid < 0) > - continue; > - > - /* set block-size for cbom extension if available */ > - ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); > - if (ret) > - continue; > - > - if (!riscv_cbom_block_size) { > - riscv_cbom_block_size = val; > - cbom_hartid = hartid; > - } else { > - if (riscv_cbom_block_size != val) > - pr_warn("cbom-block-size mismatched between harts %d and %lu\n", > - cbom_hartid, hartid); > - } > - } > -} > -#endif > - > void riscv_noncoherent_supported(void) > { > noncoherent_supported = true; > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c 2022-09-01 15:29 ` Heiko Stübner @ 2022-09-01 15:49 ` Conor.Dooley 0 siblings, 0 replies; 20+ messages in thread From: Conor.Dooley @ 2022-09-01 15:49 UTC (permalink / raw) To: heiko, palmer, paul.walmsley, apatel Cc: atishp, anup, linux-riscv, linux-kernel, mchitale On 01/09/2022 16:29, Heiko Stübner wrote: > Hi, > > Am Dienstag, 30. August 2022, 06:46:40 CEST schrieb Anup Patel: >> The riscv_cbom_block_size parsing from DT belongs to cacheflush.c which >> is home for all cache maintenance related stuff so let us move the >> riscv_init_cbom_blocksize() and riscv_cbom_block_size to cacheflush.c. >> >> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> >> Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > Makes a lot of sense to keep stuff together. > > Reviewed-by: Heiko Stuebner <heiko@sntech.de> > Tested-by: Heiko Stuebner <heiko@sntech.de> > > > Also, can we handle this as fix patch? > > I.e. Currently the t-head code somewhat relies on the default value > set to L1_CACHE_BYTES. The cache-block-size is static there. > > Palmers upcoming patch reworking the parsing [0], will remove that default, > so having the riscv_cbom_block_size defined in the cacheflush header > will allow an easy fix by setting that value from the t-head errata init > for those cores. @Palmer what is the status of that fix? Since I have a clang toolchain set up, I could squash my fixup-for-clang into your patch and respin it as a real patch for Anup to base on? Anyway, I too like this cleanup: Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > Heiko > > [0] https://lore.kernel.org/r/20220812154010.18280-1-palmer@rivosinc.com > >> --- >> arch/riscv/include/asm/cacheflush.h | 2 ++ >> arch/riscv/mm/cacheflush.c | 39 +++++++++++++++++++++++++++++ >> arch/riscv/mm/dma-noncoherent.c | 38 ---------------------------- >> 3 files changed, 41 insertions(+), 38 deletions(-) >> >> diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h >> index a60acaecfeda..de55d6b8deeb 100644 >> --- a/arch/riscv/include/asm/cacheflush.h >> +++ b/arch/riscv/include/asm/cacheflush.h >> @@ -42,6 +42,8 @@ void flush_icache_mm(struct mm_struct *mm, bool local); >> >> #endif /* CONFIG_SMP */ >> >> +extern unsigned int riscv_cbom_block_size; >> + >> #ifdef CONFIG_RISCV_ISA_ZICBOM >> void riscv_init_cbom_blocksize(void); >> #else >> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c >> index 6cb7d96ad9c7..336c5deea870 100644 >> --- a/arch/riscv/mm/cacheflush.c >> +++ b/arch/riscv/mm/cacheflush.c >> @@ -3,6 +3,8 @@ >> * Copyright (C) 2017 SiFive >> */ >> >> +#include <linux/of.h> >> +#include <linux/of_device.h> >> #include <asm/cacheflush.h> >> >> #ifdef CONFIG_SMP >> @@ -86,3 +88,40 @@ void flush_icache_pte(pte_t pte) >> flush_icache_all(); >> } >> #endif /* CONFIG_MMU */ >> + >> +unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; >> + >> +#ifdef CONFIG_RISCV_ISA_ZICBOM >> +void riscv_init_cbom_blocksize(void) >> +{ >> + struct device_node *node; >> + int ret; >> + u32 val; >> + >> + for_each_of_cpu_node(node) { >> + unsigned long hartid; >> + int cbom_hartid; >> + >> + ret = riscv_of_processor_hartid(node, &hartid); >> + if (ret) >> + continue; >> + >> + if (hartid < 0) >> + continue; >> + >> + /* set block-size for cbom extension if available */ >> + ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); >> + if (ret) >> + continue; >> + >> + if (!riscv_cbom_block_size) { >> + riscv_cbom_block_size = val; >> + cbom_hartid = hartid; >> + } else { >> + if (riscv_cbom_block_size != val) >> + pr_warn("cbom-block-size mismatched between harts %d and %lu\n", >> + cbom_hartid, hartid); >> + } >> + } >> +} >> +#endif >> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c >> index cd2225304c82..3f502a1a68b1 100644 >> --- a/arch/riscv/mm/dma-noncoherent.c >> +++ b/arch/riscv/mm/dma-noncoherent.c >> @@ -8,11 +8,8 @@ >> #include <linux/dma-direct.h> >> #include <linux/dma-map-ops.h> >> #include <linux/mm.h> >> -#include <linux/of.h> >> -#include <linux/of_device.h> >> #include <asm/cacheflush.h> >> >> -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES; >> static bool noncoherent_supported; >> >> void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, >> @@ -75,41 +72,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, >> dev->dma_coherent = coherent; >> } >> >> -#ifdef CONFIG_RISCV_ISA_ZICBOM >> -void riscv_init_cbom_blocksize(void) >> -{ >> - struct device_node *node; >> - int ret; >> - u32 val; >> - >> - for_each_of_cpu_node(node) { >> - unsigned long hartid; >> - int cbom_hartid; >> - >> - ret = riscv_of_processor_hartid(node, &hartid); >> - if (ret) >> - continue; >> - >> - if (hartid < 0) >> - continue; >> - >> - /* set block-size for cbom extension if available */ >> - ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); >> - if (ret) >> - continue; >> - >> - if (!riscv_cbom_block_size) { >> - riscv_cbom_block_size = val; >> - cbom_hartid = hartid; >> - } else { >> - if (riscv_cbom_block_size != val) >> - pr_warn("cbom-block-size mismatched between harts %d and %lu\n", >> - cbom_hartid, hartid); >> - } >> - } >> -} >> -#endif >> - >> void riscv_noncoherent_supported(void) >> { >> noncoherent_supported = true; >> > > > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs 2022-08-30 4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel 2022-08-30 4:46 ` [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c Anup Patel @ 2022-08-30 4:46 ` Anup Patel 2022-09-01 15:38 ` Heiko Stübner 2022-08-30 4:46 ` [PATCH v2 4/4] RISC-V: Enable PMEM drivers Anup Patel 3 siblings, 1 reply; 20+ messages in thread From: Anup Patel @ 2022-08-30 4:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale The NVDIMM PMEM driver expects arch specific APIs for cache maintenance and if arch does not provide these APIs then NVDIMM PMEM driver will always use MEMREMAP_WT to map persistent memory which in-turn maps as UC memory type defined by the RISC-V Svpbmt specification. Now that the Svpbmt and Zicbom support is available in RISC-V kernel, we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM PMEM driver can use MEMREMAP_WB to map persistent memory. Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- arch/riscv/Kconfig | 1 + arch/riscv/mm/Makefile | 1 + arch/riscv/mm/pmem.c | 21 +++++++++++++++++++++ 3 files changed, 23 insertions(+) create mode 100644 arch/riscv/mm/pmem.c diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 0ebd8da388d8..37d6370d29c3 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -25,6 +25,7 @@ config RISCV select ARCH_HAS_GIGANTIC_PAGE select ARCH_HAS_KCOV select ARCH_HAS_MMIOWB + select ARCH_HAS_PMEM_API select ARCH_HAS_PTE_SPECIAL select ARCH_HAS_SET_DIRECT_MAP if MMU select ARCH_HAS_SET_MEMORY if MMU diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile index d76aabf4b94d..3b368e547f83 100644 --- a/arch/riscv/mm/Makefile +++ b/arch/riscv/mm/Makefile @@ -31,3 +31,4 @@ endif obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o obj-$(CONFIG_RISCV_DMA_NONCOHERENT) += dma-noncoherent.o +obj-$(CONFIG_ARCH_HAS_PMEM_API) += pmem.o diff --git a/arch/riscv/mm/pmem.c b/arch/riscv/mm/pmem.c new file mode 100644 index 000000000000..089df92ae876 --- /dev/null +++ b/arch/riscv/mm/pmem.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Ventana Micro Systems Inc. + */ + +#include <linux/export.h> +#include <linux/libnvdimm.h> + +#include <asm/cacheflush.h> + +void arch_wb_cache_pmem(void *addr, size_t size) +{ + ALT_CMO_OP(clean, addr, size, riscv_cbom_block_size); +} +EXPORT_SYMBOL_GPL(arch_wb_cache_pmem); + +void arch_invalidate_pmem(void *addr, size_t size) +{ + ALT_CMO_OP(inval, addr, size, riscv_cbom_block_size); +} +EXPORT_SYMBOL_GPL(arch_invalidate_pmem); -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs 2022-08-30 4:46 ` [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs Anup Patel @ 2022-09-01 15:38 ` Heiko Stübner 2022-09-03 16:03 ` Anup Patel 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2022-09-01 15:38 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Anup Patel Cc: Atish Patra, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale Hi Anup, Am Dienstag, 30. August 2022, 06:46:41 CEST schrieb Anup Patel: > The NVDIMM PMEM driver expects arch specific APIs for cache maintenance > and if arch does not provide these APIs then NVDIMM PMEM driver will > always use MEMREMAP_WT to map persistent memory which in-turn maps as > UC memory type defined by the RISC-V Svpbmt specification. > > Now that the Svpbmt and Zicbom support is available in RISC-V kernel, > we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM > PMEM driver can use MEMREMAP_WB to map persistent memory. Zicbom is detected at runtime, though that kconfig setting changes the behaviour for the memremap-type at compile-time. So what happens on systems not using zicbom (or another cmo-variant) ? Heiko > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > --- > arch/riscv/Kconfig | 1 + > arch/riscv/mm/Makefile | 1 + > arch/riscv/mm/pmem.c | 21 +++++++++++++++++++++ > 3 files changed, 23 insertions(+) > create mode 100644 arch/riscv/mm/pmem.c > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 0ebd8da388d8..37d6370d29c3 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -25,6 +25,7 @@ config RISCV > select ARCH_HAS_GIGANTIC_PAGE > select ARCH_HAS_KCOV > select ARCH_HAS_MMIOWB > + select ARCH_HAS_PMEM_API > select ARCH_HAS_PTE_SPECIAL > select ARCH_HAS_SET_DIRECT_MAP if MMU > select ARCH_HAS_SET_MEMORY if MMU > diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile > index d76aabf4b94d..3b368e547f83 100644 > --- a/arch/riscv/mm/Makefile > +++ b/arch/riscv/mm/Makefile > @@ -31,3 +31,4 @@ endif > > obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o > obj-$(CONFIG_RISCV_DMA_NONCOHERENT) += dma-noncoherent.o > +obj-$(CONFIG_ARCH_HAS_PMEM_API) += pmem.o > diff --git a/arch/riscv/mm/pmem.c b/arch/riscv/mm/pmem.c > new file mode 100644 > index 000000000000..089df92ae876 > --- /dev/null > +++ b/arch/riscv/mm/pmem.c > @@ -0,0 +1,21 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2022 Ventana Micro Systems Inc. > + */ > + > +#include <linux/export.h> > +#include <linux/libnvdimm.h> > + > +#include <asm/cacheflush.h> > + > +void arch_wb_cache_pmem(void *addr, size_t size) > +{ > + ALT_CMO_OP(clean, addr, size, riscv_cbom_block_size); > +} > +EXPORT_SYMBOL_GPL(arch_wb_cache_pmem); > + > +void arch_invalidate_pmem(void *addr, size_t size) > +{ > + ALT_CMO_OP(inval, addr, size, riscv_cbom_block_size); > +} > +EXPORT_SYMBOL_GPL(arch_invalidate_pmem); > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs 2022-09-01 15:38 ` Heiko Stübner @ 2022-09-03 16:03 ` Anup Patel 0 siblings, 0 replies; 20+ messages in thread From: Anup Patel @ 2022-09-03 16:03 UTC (permalink / raw) To: Heiko Stübner Cc: Palmer Dabbelt, Paul Walmsley, Atish Patra, Anup Patel, linux-riscv, linux-kernel, Mayuresh Chitale On Thu, Sep 1, 2022 at 9:08 PM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Anup, > > Am Dienstag, 30. August 2022, 06:46:41 CEST schrieb Anup Patel: > > The NVDIMM PMEM driver expects arch specific APIs for cache maintenance > > and if arch does not provide these APIs then NVDIMM PMEM driver will > > always use MEMREMAP_WT to map persistent memory which in-turn maps as > > UC memory type defined by the RISC-V Svpbmt specification. > > > > Now that the Svpbmt and Zicbom support is available in RISC-V kernel, > > we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM > > PMEM driver can use MEMREMAP_WB to map persistent memory. > > Zicbom is detected at runtime, though that kconfig setting changes the > behaviour for the memremap-type at compile-time. So what happens on > systems not using zicbom (or another cmo-variant) ? On a system without Zicbom (or some other cmo-variant), the PMEM read will always work but PMEM writes will not be reliable. Currently, the generic PMEM driver has no provision to allow arch code to disable cacheable mapping at boot-time. Maybe we can add WARN_ONCE() for the case when arch_xyz_pmem() is called on a system not having Zicbom ? Regards, Anup > > > Heiko > > > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > --- > > arch/riscv/Kconfig | 1 + > > arch/riscv/mm/Makefile | 1 + > > arch/riscv/mm/pmem.c | 21 +++++++++++++++++++++ > > 3 files changed, 23 insertions(+) > > create mode 100644 arch/riscv/mm/pmem.c > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index 0ebd8da388d8..37d6370d29c3 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -25,6 +25,7 @@ config RISCV > > select ARCH_HAS_GIGANTIC_PAGE > > select ARCH_HAS_KCOV > > select ARCH_HAS_MMIOWB > > + select ARCH_HAS_PMEM_API > > select ARCH_HAS_PTE_SPECIAL > > select ARCH_HAS_SET_DIRECT_MAP if MMU > > select ARCH_HAS_SET_MEMORY if MMU > > diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile > > index d76aabf4b94d..3b368e547f83 100644 > > --- a/arch/riscv/mm/Makefile > > +++ b/arch/riscv/mm/Makefile > > @@ -31,3 +31,4 @@ endif > > > > obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o > > obj-$(CONFIG_RISCV_DMA_NONCOHERENT) += dma-noncoherent.o > > +obj-$(CONFIG_ARCH_HAS_PMEM_API) += pmem.o > > diff --git a/arch/riscv/mm/pmem.c b/arch/riscv/mm/pmem.c > > new file mode 100644 > > index 000000000000..089df92ae876 > > --- /dev/null > > +++ b/arch/riscv/mm/pmem.c > > @@ -0,0 +1,21 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2022 Ventana Micro Systems Inc. > > + */ > > + > > +#include <linux/export.h> > > +#include <linux/libnvdimm.h> > > + > > +#include <asm/cacheflush.h> > > + > > +void arch_wb_cache_pmem(void *addr, size_t size) > > +{ > > + ALT_CMO_OP(clean, addr, size, riscv_cbom_block_size); > > +} > > +EXPORT_SYMBOL_GPL(arch_wb_cache_pmem); > > + > > +void arch_invalidate_pmem(void *addr, size_t size) > > +{ > > + ALT_CMO_OP(inval, addr, size, riscv_cbom_block_size); > > +} > > +EXPORT_SYMBOL_GPL(arch_invalidate_pmem); > > > > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 4/4] RISC-V: Enable PMEM drivers 2022-08-30 4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel ` (2 preceding siblings ...) 2022-08-30 4:46 ` [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs Anup Patel @ 2022-08-30 4:46 ` Anup Patel 2022-09-01 16:11 ` Conor.Dooley 3 siblings, 1 reply; 20+ messages in thread From: Anup Patel @ 2022-08-30 4:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley Cc: Atish Patra, Heiko Stuebner, Anup Patel, linux-riscv, linux-kernel, Anup Patel, Mayuresh Chitale We now have PMEM arch support available in RISC-V kernel so let us enable relevant drivers in defconfig. Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- arch/riscv/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index aed332a9d4ea..010b673ebd11 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -159,6 +159,7 @@ CONFIG_VIRTIO_MMIO=y CONFIG_RPMSG_CHAR=y CONFIG_RPMSG_CTRL=y CONFIG_RPMSG_VIRTIO=y +CONFIG_LIBNVDIMM=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v2 4/4] RISC-V: Enable PMEM drivers 2022-08-30 4:46 ` [PATCH v2 4/4] RISC-V: Enable PMEM drivers Anup Patel @ 2022-09-01 16:11 ` Conor.Dooley 0 siblings, 0 replies; 20+ messages in thread From: Conor.Dooley @ 2022-09-01 16:11 UTC (permalink / raw) To: apatel, palmer, paul.walmsley Cc: atishp, heiko, anup, linux-riscv, linux-kernel, mchitale On 30/08/2022 05:46, Anup Patel wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > We now have PMEM arch support available in RISC-V kernel so let us > enable relevant drivers in defconfig. > > Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> Bunch of new build time warnings related to pmem w/ this patch but they all seem to be problems in the nvdimm core code that've just been exposed here... Here's another name to add to your single-line defconfig change: Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > --- > arch/riscv/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig > index aed332a9d4ea..010b673ebd11 100644 > --- a/arch/riscv/configs/defconfig > +++ b/arch/riscv/configs/defconfig > @@ -159,6 +159,7 @@ CONFIG_VIRTIO_MMIO=y > CONFIG_RPMSG_CHAR=y > CONFIG_RPMSG_CTRL=y > CONFIG_RPMSG_VIRTIO=y > +CONFIG_LIBNVDIMM=y > CONFIG_EXT4_FS=y > CONFIG_EXT4_FS_POSIX_ACL=y > CONFIG_EXT4_FS_SECURITY=y > -- > 2.34.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-10-07 5:35 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-30 4:46 [PATCH v2 0/4] Add PMEM support for RISC-V Anup Patel 2022-08-30 4:46 ` [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt Anup Patel 2022-09-01 15:25 ` Heiko Stübner 2022-09-01 16:07 ` Conor.Dooley 2022-09-09 8:10 ` Anup Patel 2022-09-16 2:24 ` Anup Patel 2022-09-22 16:35 ` Palmer Dabbelt 2022-09-23 10:35 ` Arnd Bergmann 2022-09-23 10:45 ` Palmer Dabbelt 2022-09-28 12:14 ` Christoph Hellwig 2022-10-07 3:50 ` Palmer Dabbelt 2022-10-07 5:34 ` Anup Patel 2022-08-30 4:46 ` [PATCH v2 2/4] RISC-V: Move riscv_init_cbom_blocksize() to cacheflush.c Anup Patel 2022-09-01 15:29 ` Heiko Stübner 2022-09-01 15:49 ` Conor.Dooley 2022-08-30 4:46 ` [PATCH v2 3/4] RISC-V: Implement arch specific PMEM APIs Anup Patel 2022-09-01 15:38 ` Heiko Stübner 2022-09-03 16:03 ` Anup Patel 2022-08-30 4:46 ` [PATCH v2 4/4] RISC-V: Enable PMEM drivers Anup Patel 2022-09-01 16:11 ` Conor.Dooley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).