add swiotlb support for riscv

add swiotlb support for riscv

[Christoph Hellwig]

Current 64-bit RISC-V cores don't have any iommu support, so they need
iommu support when used with more than 4GB DRAM (or even just address
space depending on the SBI).  This wires the support up based on
earlier patches from Palmer.

Note that the patches are on to of the dma mapping tree as they require
the swiotlb Kconfig consolidation, and should probably merged through
that tree as well.

Git tree:

    git://git.infradead.org/users/hch/misc.git riscv-swiotlb

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb

add swiotlb support for riscv

[Christoph Hellwig]

Current 64-bit RISC-V cores don't have any iommu support, so they need
iommu support when used with more than 4GB DRAM (or even just address
space depending on the SBI).  This wires the support up based on
earlier patches from Palmer.

Note that the patches are on to of the dma mapping tree as they require
the swiotlb Kconfig consolidation, and should probably merged through
that tree as well.

Git tree:

    git://git.infradead.org/users/hch/misc.git riscv-swiotlb

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb

[PATCH 1/3] riscv: simplify Kconfig magic for 32-bit vs 64-bit kernels

[Christoph Hellwig]

We can deduct this directly using a select from ARCH_RV32I/ARCH_RV64I.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/riscv/Kconfig | 31 ++++++-------------------------
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c27bac1d4f65..7817bbe0cfac 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -3,6 +3,12 @@
 # see Documentation/kbuild/kconfig-language.txt.
 #
 
+config 64BIT
+	bool
+
+config 32BIT
+	bool
+
 config RISCV
 	def_bool y
 	# even on 32-bit, physical (and DMA) addresses are > 32-bits
@@ -95,7 +101,6 @@ choice
 
 config ARCH_RV32I
 	bool "RV32I"
-	select CPU_SUPPORTS_32BIT_KERNEL
 	select 32BIT
 	select GENERIC_ASHLDI3
 	select GENERIC_ASHRDI3
@@ -103,7 +108,6 @@ config ARCH_RV32I
 
 config ARCH_RV64I
 	bool "RV64I"
-	select CPU_SUPPORTS_64BIT_KERNEL
 	select 64BIT
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
@@ -165,11 +169,6 @@ config NR_CPUS
 	depends on SMP
 	default "8"
 
-config CPU_SUPPORTS_32BIT_KERNEL
-	bool
-config CPU_SUPPORTS_64BIT_KERNEL
-	bool
-
 choice
 	prompt "CPU Tuning"
 	default TUNE_GENERIC
@@ -196,24 +195,6 @@ endmenu
 
 menu "Kernel type"
 
-choice
-	prompt "Kernel code model"
-	default 64BIT
-
-config 32BIT
-	bool "32-bit kernel"
-	depends on CPU_SUPPORTS_32BIT_KERNEL
-	help
-	  Select this option to build a 32-bit kernel.
-
-config 64BIT
-	bool "64-bit kernel"
-	depends on CPU_SUPPORTS_64BIT_KERNEL
-	help
-	  Select this option to build a 64-bit kernel.
-
-endchoice
-
 source "mm/Kconfig"
 
 source "kernel/Kconfig.preempt"
-- 
2.17.0

[PATCH 1/3] riscv: simplify Kconfig magic for 32-bit vs 64-bit kernels

[Christoph Hellwig]

We can deduct this directly using a select from ARCH_RV32I/ARCH_RV64I.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 arch/riscv/Kconfig | 31 ++++++-------------------------
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c27bac1d4f65..7817bbe0cfac 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -3,6 +3,12 @@
 # see Documentation/kbuild/kconfig-language.txt.
 #
 
+config 64BIT
+	bool
+
+config 32BIT
+	bool
+
 config RISCV
 	def_bool y
 	# even on 32-bit, physical (and DMA) addresses are > 32-bits
@@ -95,7 +101,6 @@ choice
 
 config ARCH_RV32I
 	bool "RV32I"
-	select CPU_SUPPORTS_32BIT_KERNEL
 	select 32BIT
 	select GENERIC_ASHLDI3
 	select GENERIC_ASHRDI3
@@ -103,7 +108,6 @@ config ARCH_RV32I
 
 config ARCH_RV64I
 	bool "RV64I"
-	select CPU_SUPPORTS_64BIT_KERNEL
 	select 64BIT
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
@@ -165,11 +169,6 @@ config NR_CPUS
 	depends on SMP
 	default "8"
 
-config CPU_SUPPORTS_32BIT_KERNEL
-	bool
-config CPU_SUPPORTS_64BIT_KERNEL
-	bool
-
 choice
 	prompt "CPU Tuning"
 	default TUNE_GENERIC
@@ -196,24 +195,6 @@ endmenu
 
 menu "Kernel type"
 
-choice
-	prompt "Kernel code model"
-	default 64BIT
-
-config 32BIT
-	bool "32-bit kernel"
-	depends on CPU_SUPPORTS_32BIT_KERNEL
-	help
-	  Select this option to build a 32-bit kernel.
-
-config 64BIT
-	bool "64-bit kernel"
-	depends on CPU_SUPPORTS_64BIT_KERNEL
-	help
-	  Select this option to build a 64-bit kernel.
-
-endchoice
-
 source "mm/Kconfig"
 
 source "kernel/Kconfig.preempt"
-- 
2.17.0

[PATCH 2/3] riscv: only enable ZONE_DMA32 for 64-bit

[Christoph Hellwig]

Until we actually support > 32bit physical addresses for 32-bit using
highmem there is no point in enabling ZONE_DMA32.  And even if such
support is ever added it probably should be conditional to not burden
low end embedded devices.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 7817bbe0cfac..c4488ce8c2fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -48,7 +48,7 @@ config MMU
 
 config ZONE_DMA32
 	bool
-	default y
+	default y if 64BIT
 
 config PAGE_OFFSET
 	hex
-- 
2.17.0

[PATCH 2/3] riscv: only enable ZONE_DMA32 for 64-bit

[Christoph Hellwig]

Until we actually support > 32bit physical addresses for 32-bit using
highmem there is no point in enabling ZONE_DMA32.  And even if such
support is ever added it probably should be conditional to not burden
low end embedded devices.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 7817bbe0cfac..c4488ce8c2fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -48,7 +48,7 @@ config MMU
 
 config ZONE_DMA32
 	bool
-	default y
+	default y if 64BIT
 
 config PAGE_OFFSET
 	hex
-- 
2.17.0

[PATCH 3/3] riscv: add swiotlb support

[Christoph Hellwig]

All RISC-V platforms today lack an IOMMU. However, legacy PCI devices
sometimes require DMA-memory to be in the low 32 bits.  To make this work,
we enable the software-based bounce buffers from swiotlb.  They only impose
overhead when the device in question cannot address the full 64-bit address
space, so a perfect fit.

This patch assumes that DMA is coherent with the processor and the PCI
bus.  It also assumes that the processor and devices share a common
address space. This is true for all RISC-V platforms so far.

[changelog stolen from an earlier patch by Palmer Dabbelt that did the
 more complicated swiotlb wireup before the recent consolidation]

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/riscv/Kconfig                   |  1 +
 arch/riscv/include/asm/dma-mapping.h | 15 +++++++++++++++
 arch/riscv/kernel/setup.c            |  2 ++
 3 files changed, 18 insertions(+)
 create mode 100644 arch/riscv/include/asm/dma-mapping.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c4488ce8c2fa..274bc064c41f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -114,6 +114,7 @@ config ARCH_RV64I
 	select HAVE_FTRACE_MCOUNT_RECORD
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_DYNAMIC_FTRACE_WITH_REGS
+	select SWIOTLB
 
 endchoice
 
diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h
new file mode 100644
index 000000000000..8facc1c8fa05
--- /dev/null
+++ b/arch/riscv/include/asm/dma-mapping.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef _RISCV_ASM_DMA_MAPPING_H
+#define _RISCV_ASM_DMA_MAPPING_H 1
+
+#ifdef CONFIG_SWIOTLB
+#include <linux/swiotlb.h>
+static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
+{
+	return &swiotlb_dma_ops;
+}
+#else
+#include <asm-generic/dma-mapping.h>
+#endif /* CONFIG_SWIOTLB */
+
+#endif /* _RISCV_ASM_DMA_MAPPING_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index c11f40c1b2a8..ee44a48faf79 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -29,6 +29,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/sched/task.h>
+#include <linux/swiotlb.h>
 
 #include <asm/setup.h>
 #include <asm/sections.h>
@@ -206,6 +207,7 @@ void __init setup_arch(char **cmdline_p)
 	setup_bootmem();
 	paging_init();
 	unflatten_device_tree();
+	swiotlb_init(1);
 
 #ifdef CONFIG_SMP
 	setup_smp();
-- 
2.17.0

[PATCH 3/3] riscv: add swiotlb support

[Christoph Hellwig]

All RISC-V platforms today lack an IOMMU. However, legacy PCI devices
sometimes require DMA-memory to be in the low 32 bits.  To make this work,
we enable the software-based bounce buffers from swiotlb.  They only impose
overhead when the device in question cannot address the full 64-bit address
space, so a perfect fit.

This patch assumes that DMA is coherent with the processor and the PCI
bus.  It also assumes that the processor and devices share a common
address space. This is true for all RISC-V platforms so far.

[changelog stolen from an earlier patch by Palmer Dabbelt that did the
 more complicated swiotlb wireup before the recent consolidation]

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 arch/riscv/Kconfig                   |  1 +
 arch/riscv/include/asm/dma-mapping.h | 15 +++++++++++++++
 arch/riscv/kernel/setup.c            |  2 ++
 3 files changed, 18 insertions(+)
 create mode 100644 arch/riscv/include/asm/dma-mapping.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c4488ce8c2fa..274bc064c41f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -114,6 +114,7 @@ config ARCH_RV64I
 	select HAVE_FTRACE_MCOUNT_RECORD
 	select HAVE_DYNAMIC_FTRACE
 	select HAVE_DYNAMIC_FTRACE_WITH_REGS
+	select SWIOTLB
 
 endchoice
 
diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h
new file mode 100644
index 000000000000..8facc1c8fa05
--- /dev/null
+++ b/arch/riscv/include/asm/dma-mapping.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef _RISCV_ASM_DMA_MAPPING_H
+#define _RISCV_ASM_DMA_MAPPING_H 1
+
+#ifdef CONFIG_SWIOTLB
+#include <linux/swiotlb.h>
+static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
+{
+	return &swiotlb_dma_ops;
+}
+#else
+#include <asm-generic/dma-mapping.h>
+#endif /* CONFIG_SWIOTLB */
+
+#endif /* _RISCV_ASM_DMA_MAPPING_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index c11f40c1b2a8..ee44a48faf79 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -29,6 +29,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/sched/task.h>
+#include <linux/swiotlb.h>
 
 #include <asm/setup.h>
 #include <asm/sections.h>
@@ -206,6 +207,7 @@ void __init setup_arch(char **cmdline_p)
 	setup_bootmem();
 	paging_init();
 	unflatten_device_tree();
+	swiotlb_init(1);
 
 #ifdef CONFIG_SMP
 	setup_smp();
-- 
2.17.0

add swiotlb support for riscv

[Palmer Dabbelt]

On Wed, 16 May 2018 07:42:59 PDT (-0700), Christoph Hellwig wrote:
> Current 64-bit RISC-V cores don't have any iommu support, so they need
> iommu support when used with more than 4GB DRAM (or even just address
> space depending on the SBI).  This wires the support up based on
> earlier patches from Palmer.

Yep: the FU540-C000 has a feature where DRAM is always mapped at 2GiB physical, 
so if we have more than 2GiB of DRAM (we have 8GiB on the only board it'll 
probably ever be attached to) then we need swiotlb to do 32-bit DMA.

> Note that the patches are on to of the dma mapping tree as they require
> the swiotlb Kconfig consolidation, and should probably merged through
> that tree as well.
>
> Git tree:
>
>     git://git.infradead.org/users/hch/misc.git riscv-swiotlb
>
> Gitweb:
>
>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb

Ah, great!  This is much cleaner than our current implementation, which isn't 
based on the generic stuff :).  I'm happy to have these through that tree if it 
makes the merging easier, feel free to add an

    Acked-by: Palmer Dabbelt <palmer@sifive.com>

and/or a

    Reviewed-by: Palmer Dabbelt <palmer@sifive.com>

on all 3 of these patches if that helps.  I'm going to park them on my 
next-swiotlb branch so I can use them, but I won't submit them myself unless 
someone says something.

Re: add swiotlb support for riscv

[Palmer Dabbelt]

On Wed, 16 May 2018 07:42:59 PDT (-0700), Christoph Hellwig wrote:
> Current 64-bit RISC-V cores don't have any iommu support, so they need
> iommu support when used with more than 4GB DRAM (or even just address
> space depending on the SBI).  This wires the support up based on
> earlier patches from Palmer.

Yep: the FU540-C000 has a feature where DRAM is always mapped at 2GiB physical, 
so if we have more than 2GiB of DRAM (we have 8GiB on the only board it'll 
probably ever be attached to) then we need swiotlb to do 32-bit DMA.

> Note that the patches are on to of the dma mapping tree as they require
> the swiotlb Kconfig consolidation, and should probably merged through
> that tree as well.
>
> Git tree:
>
>     git://git.infradead.org/users/hch/misc.git riscv-swiotlb
>
> Gitweb:
>
>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb

Ah, great!  This is much cleaner than our current implementation, which isn't 
based on the generic stuff :).  I'm happy to have these through that tree if it 
makes the merging easier, feel free to add an

    Acked-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>

and/or a

    Reviewed-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>

on all 3 of these patches if that helps.  I'm going to park them on my 
next-swiotlb branch so I can use them, but I won't submit them myself unless 
someone says something.

add swiotlb support for riscv

[Christoph Hellwig]

On Fri, May 18, 2018 at 04:31:36PM -0700, Palmer Dabbelt wrote:
>>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb
>
> Ah, great!  This is much cleaner than our current implementation, which 
> isn't based on the generic stuff :).  I'm happy to have these through that 
> tree if it makes the merging easier, feel free to add an
>
>    Acked-by: Palmer Dabbelt <palmer@sifive.com>
>
> and/or a
>
>    Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
>
> on all 3 of these patches if that helps.  I'm going to park them on my 
> next-swiotlb branch so I can use them, but I won't submit them myself 
> unless someone says something.

I think it is indeed easiest if I pull them into the dma-mapping tree.

Feel free the keep them in a riscv branch as well, but remember that
they depend on other patches in the dma-mapping tree that consolidate
the SWIOTLB Kconfig symbol.

Re: add swiotlb support for riscv

[Christoph Hellwig]

On Fri, May 18, 2018 at 04:31:36PM -0700, Palmer Dabbelt wrote:
>>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/riscv-swiotlb
>
> Ah, great!  This is much cleaner than our current implementation, which 
> isn't based on the generic stuff :).  I'm happy to have these through that 
> tree if it makes the merging easier, feel free to add an
>
>    Acked-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
>
> and/or a
>
>    Reviewed-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
>
> on all 3 of these patches if that helps.  I'm going to park them on my 
> next-swiotlb branch so I can use them, but I won't submit them myself 
> unless someone says something.

I think it is indeed easiest if I pull them into the dma-mapping tree.

Feel free the keep them in a riscv branch as well, but remember that
they depend on other patches in the dma-mapping tree that consolidate
the SWIOTLB Kconfig symbol.