add swiotlb support for riscv

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

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

---
 arch/riscv/Kconfig | 31 ++++++-------------------------
 1 file changed, 6 insertions(+), 25 deletions(-)

index c27bac1d4f65..7817bbe0cfac 100644
@@ -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

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.

---
 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 7817bbe0cfac..c4488ce8c2fa 100644
@@ -48,7 +48,7 @@ config MMU
 
 config ZONE_DMA32
 	bool
-	default y
+	default y if 64BIT
 
 config PAGE_OFFSET
 	hex

2.17.0

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]

---
 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

index c4488ce8c2fa..274bc064c41f 100644
@@ -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
 

new file mode 100644
index 000000000000..8facc1c8fa05
@@ -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 */

index c11f40c1b2a8..ee44a48faf79 100644
@@ -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

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.

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

and/or a

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.