All of lore.kernel.org
 help / color / mirror / Atom feed
* fix the non-coherent coldfire dma_alloc_coherent v2
@ 2023-10-16  5:47 ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi all,

this is the next attempt to not return memory that is not DMA coherent
on coldfire/m68knommu.  The last one needed more fixups in the fec
driver, which this versions includes.  On top of that I've also added
a few more cleanups to the core DMA allocation code.

Jim: any work to support the set_uncached and remap method for arm32
should probably be based on this, and patch 3 should make that
selection a little easier.

Changes since v1:
 - sort out the dependency mess in RISCV
 - don't even built non-coherent DMA support for coldfire cores without
   data caches
 - apply the fec workarounds to all coldfire platforms with data caches
 - add a trivial cleanup for m68k dma.c

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* fix the non-coherent coldfire dma_alloc_coherent v2
@ 2023-10-16  5:47 ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi all,

this is the next attempt to not return memory that is not DMA coherent
on coldfire/m68knommu.  The last one needed more fixups in the fec
driver, which this versions includes.  On top of that I've also added
a few more cleanups to the core DMA allocation code.

Jim: any work to support the set_uncached and remap method for arm32
should probably be based on this, and patch 3 should make that
selection a little easier.

Changes since v1:
 - sort out the dependency mess in RISCV
 - don't even built non-coherent DMA support for coldfire cores without
   data caches
 - apply the fec workarounds to all coldfire platforms with data caches
 - add a trivial cleanup for m68k dma.c

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
helpers, which are built into the kernel unconditionally.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/riscv/Kconfig          | 1 -
 drivers/cache/Kconfig       | 2 +-
 drivers/soc/renesas/Kconfig | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d607ab0f7c6daf..0ac0b538379718 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -277,7 +277,6 @@ config RISCV_DMA_NONCOHERENT
 
 config RISCV_NONSTANDARD_CACHE_OPS
 	bool
-	depends on RISCV_DMA_NONCOHERENT
 	help
 	  This enables function pointer support for non-standard noncoherent
 	  systems to handle cache management.
diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
index a57677f908f3ba..d6e5e3abaad8af 100644
--- a/drivers/cache/Kconfig
+++ b/drivers/cache/Kconfig
@@ -3,7 +3,7 @@ menu "Cache Drivers"
 
 config AX45MP_L2_CACHE
 	bool "Andes Technology AX45MP L2 Cache controller"
-	depends on RISCV_DMA_NONCOHERENT
+	depends on RISCV
 	select RISCV_NONSTANDARD_CACHE_OPS
 	help
 	  Support for the L2 cache controller on Andes Technology AX45MP platforms.
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 12040ce116a551..880c544bb2dfda 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -335,7 +335,7 @@ config ARCH_R9A07G043
 	bool "RISC-V Platform support for RZ/Five"
 	depends on NONPORTABLE
 	select ARCH_RZG2L
-	select AX45MP_L2_CACHE if RISCV_DMA_NONCOHERENT
+	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
 	select ERRATA_ANDES if RISCV_SBI
 	select ERRATA_ANDES_CMO if ERRATA_ANDES
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
helpers, which are built into the kernel unconditionally.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/riscv/Kconfig          | 1 -
 drivers/cache/Kconfig       | 2 +-
 drivers/soc/renesas/Kconfig | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d607ab0f7c6daf..0ac0b538379718 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -277,7 +277,6 @@ config RISCV_DMA_NONCOHERENT
 
 config RISCV_NONSTANDARD_CACHE_OPS
 	bool
-	depends on RISCV_DMA_NONCOHERENT
 	help
 	  This enables function pointer support for non-standard noncoherent
 	  systems to handle cache management.
diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
index a57677f908f3ba..d6e5e3abaad8af 100644
--- a/drivers/cache/Kconfig
+++ b/drivers/cache/Kconfig
@@ -3,7 +3,7 @@ menu "Cache Drivers"
 
 config AX45MP_L2_CACHE
 	bool "Andes Technology AX45MP L2 Cache controller"
-	depends on RISCV_DMA_NONCOHERENT
+	depends on RISCV
 	select RISCV_NONSTANDARD_CACHE_OPS
 	help
 	  Support for the L2 cache controller on Andes Technology AX45MP platforms.
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 12040ce116a551..880c544bb2dfda 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -335,7 +335,7 @@ config ARCH_R9A07G043
 	bool "RISC-V Platform support for RZ/Five"
 	depends on NONPORTABLE
 	select ARCH_RZG2L
-	select AX45MP_L2_CACHE if RISCV_DMA_NONCOHERENT
+	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
 	select ERRATA_ANDES if RISCV_SBI
 	select ERRATA_ANDES_CMO if ERRATA_ANDES
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

RISCV_DMA_NONCOHERENT is also used for whacky non-standard
non-coherent ops that use different hooks in dma-direct.

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 0ac0b538379718..9c48fecc671918 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
 	select ARCH_HAS_SYNC_DMA_FOR_CPU
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
 	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
-	select DMA_DIRECT_REMAP if MMU
 
 config RISCV_NONSTANDARD_CACHE_OPS
 	bool
@@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
 	depends on RISCV_ALTERNATIVE
 	default y
 	select RISCV_DMA_NONCOHERENT
+	select DMA_DIRECT_REMAP
 	help
 	   Adds support to dynamically detect the presence of the ZICBOM
 	   extension (Cache Block Management Operations) and enable its
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

RISCV_DMA_NONCOHERENT is also used for whacky non-standard
non-coherent ops that use different hooks in dma-direct.

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 0ac0b538379718..9c48fecc671918 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
 	select ARCH_HAS_SYNC_DMA_FOR_CPU
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
 	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
-	select DMA_DIRECT_REMAP if MMU
 
 config RISCV_NONSTANDARD_CACHE_OPS
 	bool
@@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
 	depends on RISCV_ALTERNATIVE
 	default y
 	select RISCV_DMA_NONCOHERENT
+	select DMA_DIRECT_REMAP
 	help
 	   Adds support to dynamically detect the presence of the ZICBOM
 	   extension (Cache Block Management Operations) and enable its
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
Add a proper dependency.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/soc/renesas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 880c544bb2dfda..f1696d3b5018d0 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -334,6 +334,7 @@ if RISCV
 config ARCH_R9A07G043
 	bool "RISC-V Platform support for RZ/Five"
 	depends on NONPORTABLE
+	depends on !RISCV_ISA_ZICBOM
 	select ARCH_RZG2L
 	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
Add a proper dependency.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/soc/renesas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 880c544bb2dfda..f1696d3b5018d0 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -334,6 +334,7 @@ if RISCV
 config ARCH_R9A07G043
 	bool "RISC-V Platform support for RZ/Five"
 	depends on NONPORTABLE
+	depends on !RISCV_ISA_ZICBOM
 	select ARCH_RZG2L
 	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
infrastructure does not make sense.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/soc/renesas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index f1696d3b5018d0..ea473b4150dfa8 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -338,6 +338,7 @@ config ARCH_R9A07G043
 	select ARCH_RZG2L
 	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
+	select RISCV_DMA_NONCOHERENT
 	select ERRATA_ANDES if RISCV_SBI
 	select ERRATA_ANDES_CMO if ERRATA_ANDES
 
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
infrastructure does not make sense.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/soc/renesas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index f1696d3b5018d0..ea473b4150dfa8 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -338,6 +338,7 @@ config ARCH_R9A07G043
 	select ARCH_RZG2L
 	select AX45MP_L2_CACHE
 	select DMA_GLOBAL_POOL
+	select RISCV_DMA_NONCOHERENT
 	select ERRATA_ANDES if RISCV_SBI
 	select ERRATA_ANDES_CMO if ERRATA_ANDES
 
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
allocators.  Add dependencies to Kconfig to document this, and make
kconfig complain about unment dependencies if someone tries.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index f488997b071712..4524db877eba36 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
 
 config DMA_GLOBAL_POOL
 	select DMA_DECLARE_COHERENT
+	depends on !ARCH_HAS_DMA_SET_UNCACHED
+	depends on !DMA_DIRECT_REMAP
 	bool
 
 config DMA_DIRECT_REMAP
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
allocators.  Add dependencies to Kconfig to document this, and make
kconfig complain about unment dependencies if someone tries.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index f488997b071712..4524db877eba36 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
 
 config DMA_GLOBAL_POOL
 	select DMA_DECLARE_COHERENT
+	depends on !ARCH_HAS_DMA_SET_UNCACHED
+	depends on !DMA_DIRECT_REMAP
 	bool
 
 config DMA_DIRECT_REMAP
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Instead of using arch_dma_alloc if none of the generic coherent
allocators are used, require the architectures to explicitly opt into
providing it.  This will used to deal with the case of m68knommu and
coldfire where we can't do any coherent allocations whatsoever, and
also makes it clear that arch_dma_alloc is a last resort.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm/Kconfig    |  1 +
 arch/m68k/Kconfig   |  1 +
 arch/parisc/Kconfig |  1 +
 kernel/dma/Kconfig  |  9 +++++++++
 kernel/dma/direct.c | 12 ++----------
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9557808e8937b1..a3fdf584278f86 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,6 +4,7 @@ config ARM
 	default y
 	select ARCH_32BIT_OFF_T
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
+	select ARCH_DMA_ALLOC if MMU
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 3e318bf9504c5b..0430b8ba6b5cc6 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,6 +3,7 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
+	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index a15ab147af2e07..30a4916fa9b0cc 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -3,6 +3,7 @@ config PARISC
 	def_bool y
 	select ALTERNATE_USER_ADDRESS_SPACE
 	select ARCH_32BIT_OFF_T if !64BIT
+	select ARCH_DMA_ALLOC if PA11
 	select ARCH_MIGHT_HAVE_PC_PARPORT
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4524db877eba36..515d2063b509ac 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -144,6 +144,15 @@ config DMA_DIRECT_REMAP
 	select DMA_COHERENT_POOL
 	select DMA_NONCOHERENT_MMAP
 
+#
+# Fallback to arch code for DMA allocations.  This should eventually go away.
+#
+config ARCH_DMA_ALLOC
+	depends on !ARCH_HAS_DMA_SET_UNCACHED
+	depends on !DMA_DIRECT_REMAP
+	depends on !DMA_GLOBAL_POOL
+	bool
+
 config DMA_CMA
 	bool "DMA Contiguous Memory Allocator"
 	depends on HAVE_DMA_CONTIGUOUS && CMA
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 9596ae1aa0dacf..ec410af1d8a14e 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -220,13 +220,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
 
 	if (!dev_is_dma_coherent(dev)) {
-		/*
-		 * Fallback to the arch handler if it exists.  This should
-		 * eventually go away.
-		 */
-		if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-		    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-		    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
 		    !is_swiotlb_for_alloc(dev))
 			return arch_dma_alloc(dev, size, dma_handle, gfp,
 					      attrs);
@@ -330,9 +324,7 @@ void dma_direct_free(struct device *dev, size_t size,
 		return;
 	}
 
-	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-	    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
 	    !dev_is_dma_coherent(dev) &&
 	    !is_swiotlb_for_alloc(dev)) {
 		arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Instead of using arch_dma_alloc if none of the generic coherent
allocators are used, require the architectures to explicitly opt into
providing it.  This will used to deal with the case of m68knommu and
coldfire where we can't do any coherent allocations whatsoever, and
also makes it clear that arch_dma_alloc is a last resort.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm/Kconfig    |  1 +
 arch/m68k/Kconfig   |  1 +
 arch/parisc/Kconfig |  1 +
 kernel/dma/Kconfig  |  9 +++++++++
 kernel/dma/direct.c | 12 ++----------
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9557808e8937b1..a3fdf584278f86 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,6 +4,7 @@ config ARM
 	default y
 	select ARCH_32BIT_OFF_T
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
+	select ARCH_DMA_ALLOC if MMU
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 3e318bf9504c5b..0430b8ba6b5cc6 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,6 +3,7 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
+	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index a15ab147af2e07..30a4916fa9b0cc 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -3,6 +3,7 @@ config PARISC
 	def_bool y
 	select ALTERNATE_USER_ADDRESS_SPACE
 	select ARCH_32BIT_OFF_T if !64BIT
+	select ARCH_DMA_ALLOC if PA11
 	select ARCH_MIGHT_HAVE_PC_PARPORT
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4524db877eba36..515d2063b509ac 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -144,6 +144,15 @@ config DMA_DIRECT_REMAP
 	select DMA_COHERENT_POOL
 	select DMA_NONCOHERENT_MMAP
 
+#
+# Fallback to arch code for DMA allocations.  This should eventually go away.
+#
+config ARCH_DMA_ALLOC
+	depends on !ARCH_HAS_DMA_SET_UNCACHED
+	depends on !DMA_DIRECT_REMAP
+	depends on !DMA_GLOBAL_POOL
+	bool
+
 config DMA_CMA
 	bool "DMA Contiguous Memory Allocator"
 	depends on HAVE_DMA_CONTIGUOUS && CMA
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 9596ae1aa0dacf..ec410af1d8a14e 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -220,13 +220,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
 
 	if (!dev_is_dma_coherent(dev)) {
-		/*
-		 * Fallback to the arch handler if it exists.  This should
-		 * eventually go away.
-		 */
-		if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-		    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-		    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
 		    !is_swiotlb_for_alloc(dev))
 			return arch_dma_alloc(dev, size, dma_handle, gfp,
 					      attrs);
@@ -330,9 +324,7 @@ void dma_direct_free(struct device *dev, size_t size,
 		return;
 	}
 
-	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-	    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
 	    !dev_is_dma_coherent(dev) &&
 	    !is_swiotlb_for_alloc(dev)) {
 		arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

The logic in dma_direct_alloc when to use the atomic pool vs remapping
grew a bit unreadable.  Consolidate it into a single check, and clean
up the set_uncached vs remap logic a bit as well.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/direct.c | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index ec410af1d8a14e..1327d04fa32a25 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 					dma_handle);
 
 		/*
-		 * Otherwise remap if the architecture is asking for it.  But
-		 * given that remapping memory is a blocking operation we'll
-		 * instead have to dip into the atomic pools.
+		 * Otherwise we require the architecture to either be able to
+		 * mark arbitrary parts of the kernel direct mapping uncached,
+		 * or remapped it uncached.
 		 */
+		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
 		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
-		if (remap) {
-			if (dma_direct_use_pool(dev, gfp))
-				return dma_direct_alloc_from_pool(dev, size,
-						dma_handle, gfp);
-		} else {
-			if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
-				return NULL;
-			set_uncached = true;
-		}
+		if (!set_uncached && !remap)
+			return NULL;
 	}
 
 	/*
-	 * Decrypting memory may block, so allocate the memory from the atomic
-	 * pools if we can't block.
+	 * Remapping or decrypting memory may block, allocate the memory from
+	 * the atomic pools instead if we aren't allowed block.
 	 */
-	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
+	if ((remap || force_dma_unencrypted(dev)) &&
+	    dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
 	/* we always manually zero the memory once we are done */
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

The logic in dma_direct_alloc when to use the atomic pool vs remapping
grew a bit unreadable.  Consolidate it into a single check, and clean
up the set_uncached vs remap logic a bit as well.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/direct.c | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index ec410af1d8a14e..1327d04fa32a25 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 					dma_handle);
 
 		/*
-		 * Otherwise remap if the architecture is asking for it.  But
-		 * given that remapping memory is a blocking operation we'll
-		 * instead have to dip into the atomic pools.
+		 * Otherwise we require the architecture to either be able to
+		 * mark arbitrary parts of the kernel direct mapping uncached,
+		 * or remapped it uncached.
 		 */
+		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
 		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
-		if (remap) {
-			if (dma_direct_use_pool(dev, gfp))
-				return dma_direct_alloc_from_pool(dev, size,
-						dma_handle, gfp);
-		} else {
-			if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
-				return NULL;
-			set_uncached = true;
-		}
+		if (!set_uncached && !remap)
+			return NULL;
 	}
 
 	/*
-	 * Decrypting memory may block, so allocate the memory from the atomic
-	 * pools if we can't block.
+	 * Remapping or decrypting memory may block, allocate the memory from
+	 * the atomic pools instead if we aren't allowed block.
 	 */
-	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
+	if ((remap || force_dma_unencrypted(dev)) &&
+	    dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
 	/* we always manually zero the memory once we are done */
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Log a warning once when dma_alloc_coherent fails because the platform
does not support coherent allocations at all.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/direct.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 1327d04fa32a25..fddfea3b2fe173 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -240,8 +240,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		 */
 		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
 		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
-		if (!set_uncached && !remap)
+		if (!set_uncached && !remap) {
+			pr_warn_once("coherent DMA allocations not supported on this platform.\n");
 			return NULL;
+		}
 	}
 
 	/*
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Log a warning once when dma_alloc_coherent fails because the platform
does not support coherent allocations at all.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 kernel/dma/direct.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 1327d04fa32a25..fddfea3b2fe173 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -240,8 +240,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		 */
 		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
 		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
-		if (!set_uncached && !remap)
+		if (!set_uncached && !remap) {
+			pr_warn_once("coherent DMA allocations not supported on this platform.\n");
 			return NULL;
+		}
 	}
 
 	/*
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire cores configured without a data cache are DMA coherent and
should thus simply use the simple coherent version of dma-direct.

Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
for all cases where we need to build non-coherent DMA infrastructure
to simplify the Kconfig and code conditionals.

Not building the non-coherent DMA code slightly reduces the code
size for such configurations.

Numers for m5249evb_defconfig below:

  text	   data	    bss	    dec	    hex	filename
2896158	 401052	  65392	3362602	 334f2a	vmlinux.before
2895166	 400988	  65392	3361546	 334b0a	vmlinux.after

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/Kconfig         |  8 ++++----
 arch/m68k/Kconfig.cpu     | 12 ++++++++++++
 arch/m68k/kernel/Makefile |  2 +-
 arch/m68k/kernel/dma.c    |  2 +-
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 0430b8ba6b5cc6..6c585eae89f4dc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,19 +3,19 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
-	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
+	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
-	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
-	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
+	select ARCH_HAS_DMA_PREP_COHERENT if M68K_NONCOHERENT_DMA && !COLDFIRE
+	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if M68K_NONCOHERENT_DMA
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
 	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
 	select ARCH_NO_PREEMPT if !COLDFIRE
 	select ARCH_USE_MEMTEST if MMU_MOTOROLA
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
-	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
+	select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
 	select GENERIC_ATOMIC64
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index b826e9c677b2ae..e8905d38c714c4 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -535,3 +535,15 @@ config CACHE_COPYBACK
 	  The ColdFire CPU cache is set into Copy-back mode.
 endchoice
 endif # HAVE_CACHE_CB
+
+# Coldfire cores that do not have a data cache configured can do coherent DMA.
+config COLDFIRE_COHERENT_DMA
+	bool
+	default y
+	depends on COLDFIRE
+	depends on !HAVE_CACHE_CB && !CONFIG_CACHE_D && !CONFIG_CACHE_BOTH
+
+config M68K_NONCOHERENT_DMA
+	bool
+	default y
+	depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
index af015447dfb4c1..01fb69a5095f43 100644
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@ -23,7 +23,7 @@ obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
 obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
 obj-$(CONFIG_PCI) += pcibios.o
 
-obj-$(CONFIG_HAS_DMA)	+= dma.o
+obj-$(CONFIG_M68K_NONCOHERENT_DMA) += dma.o
 
 obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
 obj-$(CONFIG_BOOTINFO_PROC)	+= bootinfo_proc.o
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 2e192a5df949bb..f83870cfa79b37 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -17,7 +17,7 @@
 
 #include <asm/cacheflush.h>
 
-#if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
+#ifndef CONFIG_COLDFIRE
 void arch_dma_prep_coherent(struct page *page, size_t size)
 {
 	cache_push(page_to_phys(page), size);
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire cores configured without a data cache are DMA coherent and
should thus simply use the simple coherent version of dma-direct.

Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
for all cases where we need to build non-coherent DMA infrastructure
to simplify the Kconfig and code conditionals.

Not building the non-coherent DMA code slightly reduces the code
size for such configurations.

Numers for m5249evb_defconfig below:

  text	   data	    bss	    dec	    hex	filename
2896158	 401052	  65392	3362602	 334f2a	vmlinux.before
2895166	 400988	  65392	3361546	 334b0a	vmlinux.after

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/Kconfig         |  8 ++++----
 arch/m68k/Kconfig.cpu     | 12 ++++++++++++
 arch/m68k/kernel/Makefile |  2 +-
 arch/m68k/kernel/dma.c    |  2 +-
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 0430b8ba6b5cc6..6c585eae89f4dc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,19 +3,19 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
-	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
+	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
-	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
-	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
+	select ARCH_HAS_DMA_PREP_COHERENT if M68K_NONCOHERENT_DMA && !COLDFIRE
+	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if M68K_NONCOHERENT_DMA
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
 	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
 	select ARCH_NO_PREEMPT if !COLDFIRE
 	select ARCH_USE_MEMTEST if MMU_MOTOROLA
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
-	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
+	select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
 	select GENERIC_ATOMIC64
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index b826e9c677b2ae..e8905d38c714c4 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -535,3 +535,15 @@ config CACHE_COPYBACK
 	  The ColdFire CPU cache is set into Copy-back mode.
 endchoice
 endif # HAVE_CACHE_CB
+
+# Coldfire cores that do not have a data cache configured can do coherent DMA.
+config COLDFIRE_COHERENT_DMA
+	bool
+	default y
+	depends on COLDFIRE
+	depends on !HAVE_CACHE_CB && !CONFIG_CACHE_D && !CONFIG_CACHE_BOTH
+
+config M68K_NONCOHERENT_DMA
+	bool
+	default y
+	depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
index af015447dfb4c1..01fb69a5095f43 100644
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@ -23,7 +23,7 @@ obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
 obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
 obj-$(CONFIG_PCI) += pcibios.o
 
-obj-$(CONFIG_HAS_DMA)	+= dma.o
+obj-$(CONFIG_M68K_NONCOHERENT_DMA) += dma.o
 
 obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
 obj-$(CONFIG_BOOTINFO_PROC)	+= bootinfo_proc.o
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 2e192a5df949bb..f83870cfa79b37 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -17,7 +17,7 @@
 
 #include <asm/cacheflush.h>
 
-#if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
+#ifndef CONFIG_COLDFIRE
 void arch_dma_prep_coherent(struct page *page, size_t size)
 {
 	cache_push(page_to_phys(page), size);
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire platforms with data caches can't properly implement
dma_alloc_coherent and currently just return noncoherent memory from
dma_alloc_coherent.

The fec driver than works around this with a flush of all caches in the
receive path. Make this hack a little less bad by using the explicit
dma_alloc_noncoherent API and documenting the hacky cache flushes so
that the DMA API level hack can be removed.

Also replace the check for CONFIG_M532x for said hack with a check
for COLDFIRE && !COLDFIRE_COHERENT_DMA.  While m532x is the only such
platform with a fec module, this makes the code more consistent and
easier to follow.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/net/ethernet/freescale/fec_main.c | 86 ++++++++++++++++++++---
 1 file changed, 76 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 77c8e9cfb44562..3fc3444402622b 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -406,6 +406,70 @@ static void fec_dump(struct net_device *ndev)
 	} while (bdp != txq->bd.base);
 }
 
+/*
+ * Coldfire does not support DMA coherent allocations, and has historically used
+ * a band-aid with a manual flush in fec_enet_rx_queue.
+ */
+#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
+static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	return dma_alloc_noncoherent(dev, size, handle, DMA_BIDIRECTIONAL, gfp);
+}
+
+static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
+		dma_addr_t handle)
+{
+	dma_free_noncoherent(dev, size, cpu_addr, handle, DMA_BIDIRECTIONAL);
+}
+#else /* CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */
+static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	return dma_alloc_coherent(dev, size, handle, gfp);
+}
+
+static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
+		dma_addr_t handle)
+{
+	dma_free_coherent(dev, size, cpu_addr, handle);
+}
+#endif /* !CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */
+
+struct fec_dma_devres {
+	size_t		size;
+	void		*vaddr;
+	dma_addr_t	dma_handle;
+};
+
+static void fec_dmam_release(struct device *dev, void *res)
+{
+	struct fec_dma_devres *this = res;
+
+	fec_dma_free(dev, this->size, this->vaddr, this->dma_handle);
+}
+
+static void *fec_dmam_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	struct fec_dma_devres *dr;
+	void *vaddr;
+
+	dr = devres_alloc(fec_dmam_release, sizeof(*dr), gfp);
+	if (!dr)
+		return NULL;
+	vaddr = fec_dma_alloc(dev, size, handle, gfp);
+	if (!vaddr) {
+		devres_free(dr);
+		return NULL;
+	}
+	dr->vaddr = vaddr;
+	dr->dma_handle = *handle;
+	dr->size = size;
+	devres_add(dev, dr);
+	return vaddr;
+}
+
 static inline bool is_ipv4_pkt(struct sk_buff *skb)
 {
 	return skb->protocol == htons(ETH_P_IP) && ip_hdr(skb)->version == 4;
@@ -1660,7 +1724,11 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 	}
 #endif
 
-#ifdef CONFIG_M532x
+#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
+	/*
+	 * Hacky flush of all caches instead of using the DMA API for the TSO
+	 * headers.
+	 */
 	flush_cache_all();
 #endif
 	rxq = fep->rx_queue[queue_id];
@@ -3288,10 +3356,9 @@ static void fec_enet_free_queue(struct net_device *ndev)
 	for (i = 0; i < fep->num_tx_queues; i++)
 		if (fep->tx_queue[i] && fep->tx_queue[i]->tso_hdrs) {
 			txq = fep->tx_queue[i];
-			dma_free_coherent(&fep->pdev->dev,
-					  txq->bd.ring_size * TSO_HEADER_SIZE,
-					  txq->tso_hdrs,
-					  txq->tso_hdrs_dma);
+			fec_dma_free(&fep->pdev->dev,
+				     txq->bd.ring_size * TSO_HEADER_SIZE,
+				     txq->tso_hdrs, txq->tso_hdrs_dma);
 		}
 
 	for (i = 0; i < fep->num_rx_queues; i++)
@@ -3321,10 +3388,9 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
 		txq->tx_stop_threshold = FEC_MAX_SKB_DESCS;
 		txq->tx_wake_threshold = FEC_MAX_SKB_DESCS + 2 * MAX_SKB_FRAGS;
 
-		txq->tso_hdrs = dma_alloc_coherent(&fep->pdev->dev,
+		txq->tso_hdrs = fec_dma_alloc(&fep->pdev->dev,
 					txq->bd.ring_size * TSO_HEADER_SIZE,
-					&txq->tso_hdrs_dma,
-					GFP_KERNEL);
+					&txq->tso_hdrs_dma, GFP_KERNEL);
 		if (!txq->tso_hdrs) {
 			ret = -ENOMEM;
 			goto alloc_failed;
@@ -4043,8 +4109,8 @@ static int fec_enet_init(struct net_device *ndev)
 	bd_size = (fep->total_tx_ring_size + fep->total_rx_ring_size) * dsize;
 
 	/* Allocate memory for buffer descriptors. */
-	cbd_base = dmam_alloc_coherent(&fep->pdev->dev, bd_size, &bd_dma,
-				       GFP_KERNEL);
+	cbd_base = fec_dmam_alloc(&fep->pdev->dev, bd_size, &bd_dma,
+				  GFP_KERNEL);
 	if (!cbd_base) {
 		ret = -ENOMEM;
 		goto free_queue_mem;
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire platforms with data caches can't properly implement
dma_alloc_coherent and currently just return noncoherent memory from
dma_alloc_coherent.

The fec driver than works around this with a flush of all caches in the
receive path. Make this hack a little less bad by using the explicit
dma_alloc_noncoherent API and documenting the hacky cache flushes so
that the DMA API level hack can be removed.

Also replace the check for CONFIG_M532x for said hack with a check
for COLDFIRE && !COLDFIRE_COHERENT_DMA.  While m532x is the only such
platform with a fec module, this makes the code more consistent and
easier to follow.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/net/ethernet/freescale/fec_main.c | 86 ++++++++++++++++++++---
 1 file changed, 76 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 77c8e9cfb44562..3fc3444402622b 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -406,6 +406,70 @@ static void fec_dump(struct net_device *ndev)
 	} while (bdp != txq->bd.base);
 }
 
+/*
+ * Coldfire does not support DMA coherent allocations, and has historically used
+ * a band-aid with a manual flush in fec_enet_rx_queue.
+ */
+#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
+static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	return dma_alloc_noncoherent(dev, size, handle, DMA_BIDIRECTIONAL, gfp);
+}
+
+static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
+		dma_addr_t handle)
+{
+	dma_free_noncoherent(dev, size, cpu_addr, handle, DMA_BIDIRECTIONAL);
+}
+#else /* CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */
+static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	return dma_alloc_coherent(dev, size, handle, gfp);
+}
+
+static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
+		dma_addr_t handle)
+{
+	dma_free_coherent(dev, size, cpu_addr, handle);
+}
+#endif /* !CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */
+
+struct fec_dma_devres {
+	size_t		size;
+	void		*vaddr;
+	dma_addr_t	dma_handle;
+};
+
+static void fec_dmam_release(struct device *dev, void *res)
+{
+	struct fec_dma_devres *this = res;
+
+	fec_dma_free(dev, this->size, this->vaddr, this->dma_handle);
+}
+
+static void *fec_dmam_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+		gfp_t gfp)
+{
+	struct fec_dma_devres *dr;
+	void *vaddr;
+
+	dr = devres_alloc(fec_dmam_release, sizeof(*dr), gfp);
+	if (!dr)
+		return NULL;
+	vaddr = fec_dma_alloc(dev, size, handle, gfp);
+	if (!vaddr) {
+		devres_free(dr);
+		return NULL;
+	}
+	dr->vaddr = vaddr;
+	dr->dma_handle = *handle;
+	dr->size = size;
+	devres_add(dev, dr);
+	return vaddr;
+}
+
 static inline bool is_ipv4_pkt(struct sk_buff *skb)
 {
 	return skb->protocol == htons(ETH_P_IP) && ip_hdr(skb)->version == 4;
@@ -1660,7 +1724,11 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 	}
 #endif
 
-#ifdef CONFIG_M532x
+#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
+	/*
+	 * Hacky flush of all caches instead of using the DMA API for the TSO
+	 * headers.
+	 */
 	flush_cache_all();
 #endif
 	rxq = fep->rx_queue[queue_id];
@@ -3288,10 +3356,9 @@ static void fec_enet_free_queue(struct net_device *ndev)
 	for (i = 0; i < fep->num_tx_queues; i++)
 		if (fep->tx_queue[i] && fep->tx_queue[i]->tso_hdrs) {
 			txq = fep->tx_queue[i];
-			dma_free_coherent(&fep->pdev->dev,
-					  txq->bd.ring_size * TSO_HEADER_SIZE,
-					  txq->tso_hdrs,
-					  txq->tso_hdrs_dma);
+			fec_dma_free(&fep->pdev->dev,
+				     txq->bd.ring_size * TSO_HEADER_SIZE,
+				     txq->tso_hdrs, txq->tso_hdrs_dma);
 		}
 
 	for (i = 0; i < fep->num_rx_queues; i++)
@@ -3321,10 +3388,9 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
 		txq->tx_stop_threshold = FEC_MAX_SKB_DESCS;
 		txq->tx_wake_threshold = FEC_MAX_SKB_DESCS + 2 * MAX_SKB_FRAGS;
 
-		txq->tso_hdrs = dma_alloc_coherent(&fep->pdev->dev,
+		txq->tso_hdrs = fec_dma_alloc(&fep->pdev->dev,
 					txq->bd.ring_size * TSO_HEADER_SIZE,
-					&txq->tso_hdrs_dma,
-					GFP_KERNEL);
+					&txq->tso_hdrs_dma, GFP_KERNEL);
 		if (!txq->tso_hdrs) {
 			ret = -ENOMEM;
 			goto alloc_failed;
@@ -4043,8 +4109,8 @@ static int fec_enet_init(struct net_device *ndev)
 	bd_size = (fep->total_tx_ring_size + fep->total_rx_ring_size) * dsize;
 
 	/* Allocate memory for buffer descriptors. */
-	cbd_base = dmam_alloc_coherent(&fep->pdev->dev, bd_size, &bd_dma,
-				       GFP_KERNEL);
+	cbd_base = fec_dmam_alloc(&fep->pdev->dev, bd_size, &bd_dma,
+				  GFP_KERNEL);
 	if (!cbd_base) {
 		ret = -ENOMEM;
 		goto free_queue_mem;
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 11/12] m68k: don't provide arch_dma_alloc for nommu/coldfire
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire cores configured with a data cache can't provide coherent
DMA allocations at all.

Instead of returning non-coherent kernel memory in this case,
return NULL and fail the allocation.

The only driver that used to rely on the previous behavior (fec) has
been switched to use non-coherent allocations for this case recently.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/Kconfig      |  1 -
 arch/m68k/kernel/dma.c | 23 -----------------------
 2 files changed, 24 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 6c585eae89f4dc..c1c0faffb0d413 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,7 +3,6 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
-	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index f83870cfa79b37..eef63d032abb53 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -33,29 +33,6 @@ pgprot_t pgprot_dmacoherent(pgprot_t prot)
 	}
 	return prot;
 }
-#else
-void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
-		gfp_t gfp, unsigned long attrs)
-{
-	void *ret;
-
-	if (dev == NULL || (*dev->dma_mask < 0xffffffff))
-		gfp |= GFP_DMA;
-	ret = (void *)__get_free_pages(gfp, get_order(size));
-
-	if (ret != NULL) {
-		memset(ret, 0, size);
-		*dma_handle = virt_to_phys(ret);
-	}
-	return ret;
-}
-
-void arch_dma_free(struct device *dev, size_t size, void *vaddr,
-		dma_addr_t dma_handle, unsigned long attrs)
-{
-	free_pages((unsigned long)vaddr, get_order(size));
-}
-
 #endif /* CONFIG_MMU && !CONFIG_COLDFIRE */
 
 void arch_sync_dma_for_device(phys_addr_t handle, size_t size,
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 11/12] m68k: don't provide arch_dma_alloc for nommu/coldfire
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Coldfire cores configured with a data cache can't provide coherent
DMA allocations at all.

Instead of returning non-coherent kernel memory in this case,
return NULL and fail the allocation.

The only driver that used to rely on the previous behavior (fec) has
been switched to use non-coherent allocations for this case recently.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/Kconfig      |  1 -
 arch/m68k/kernel/dma.c | 23 -----------------------
 2 files changed, 24 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 6c585eae89f4dc..c1c0faffb0d413 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -3,7 +3,6 @@ config M68K
 	bool
 	default y
 	select ARCH_32BIT_OFF_T
-	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index f83870cfa79b37..eef63d032abb53 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -33,29 +33,6 @@ pgprot_t pgprot_dmacoherent(pgprot_t prot)
 	}
 	return prot;
 }
-#else
-void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
-		gfp_t gfp, unsigned long attrs)
-{
-	void *ret;
-
-	if (dev == NULL || (*dev->dma_mask < 0xffffffff))
-		gfp |= GFP_DMA;
-	ret = (void *)__get_free_pages(gfp, get_order(size));
-
-	if (ret != NULL) {
-		memset(ret, 0, size);
-		*dma_handle = virt_to_phys(ret);
-	}
-	return ret;
-}
-
-void arch_dma_free(struct device *dev, size_t size, void *vaddr,
-		dma_addr_t dma_handle, unsigned long attrs)
-{
-	free_pages((unsigned long)vaddr, get_order(size));
-}
-
 #endif /* CONFIG_MMU && !CONFIG_COLDFIRE */
 
 void arch_sync_dma_for_device(phys_addr_t handle, size_t size,
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 12/12] m68k: remove unused includes from dma.c
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-16  5:47   ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

dma.c doesn't need most of the headers it includes.  Also there is
no point in undefining the DEBUG symbol given that it isn't used
anywhere in this small file.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/kernel/dma.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index eef63d032abb53..16063783aa80c6 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -4,17 +4,8 @@
  * for more details.
  */
 
-#undef DEBUG
-
 #include <linux/dma-map-ops.h>
-#include <linux/device.h>
 #include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/scatterlist.h>
-#include <linux/slab.h>
-#include <linux/vmalloc.h>
-#include <linux/export.h>
-
 #include <asm/cacheflush.h>
 
 #ifndef CONFIG_COLDFIRE
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* [PATCH 12/12] m68k: remove unused includes from dma.c
@ 2023-10-16  5:47   ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16  5:47 UTC (permalink / raw)
  To: Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

dma.c doesn't need most of the headers it includes.  Also there is
no point in undefining the DEBUG symbol given that it isn't used
anywhere in this small file.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/m68k/kernel/dma.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index eef63d032abb53..16063783aa80c6 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -4,17 +4,8 @@
  * for more details.
  */
 
-#undef DEBUG
-
 #include <linux/dma-map-ops.h>
-#include <linux/device.h>
 #include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/scatterlist.h>
-#include <linux/slab.h>
-#include <linux/vmalloc.h>
-#include <linux/export.h>
-
 #include <asm/cacheflush.h>
 
 #ifndef CONFIG_COLDFIRE
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 11:18     ` Robin Murphy
  -1 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:18 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.

FWIW,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> 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 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>   	select ARCH_HAS_SYNC_DMA_FOR_CPU
>   	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>   	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -	select DMA_DIRECT_REMAP if MMU
>   
>   config RISCV_NONSTANDARD_CACHE_OPS
>   	bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>   	depends on RISCV_ALTERNATIVE
>   	default y
>   	select RISCV_DMA_NONCOHERENT
> +	select DMA_DIRECT_REMAP
>   	help
>   	   Adds support to dynamically detect the presence of the ZICBOM
>   	   extension (Cache Block Management Operations) and enable its

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
@ 2023-10-16 11:18     ` Robin Murphy
  0 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:18 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.

FWIW,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> 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 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>   	select ARCH_HAS_SYNC_DMA_FOR_CPU
>   	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>   	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -	select DMA_DIRECT_REMAP if MMU
>   
>   config RISCV_NONSTANDARD_CACHE_OPS
>   	bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>   	depends on RISCV_ALTERNATIVE
>   	default y
>   	select RISCV_DMA_NONCOHERENT
> +	select DMA_DIRECT_REMAP
>   	help
>   	   Adds support to dynamically detect the presence of the ZICBOM
>   	   extension (Cache Block Management Operations) and enable its

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 11:18     ` Robin Murphy
  -1 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:18 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
> allocators.  Add dependencies to Kconfig to document this, and make
> kconfig complain about unment dependencies if someone tries.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index f488997b071712..4524db877eba36 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
>   
>   config DMA_GLOBAL_POOL
>   	select DMA_DECLARE_COHERENT
> +	depends on !ARCH_HAS_DMA_SET_UNCACHED
> +	depends on !DMA_DIRECT_REMAP
>   	bool
>   
>   config DMA_DIRECT_REMAP

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
@ 2023-10-16 11:18     ` Robin Murphy
  0 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:18 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
> allocators.  Add dependencies to Kconfig to document this, and make
> kconfig complain about unment dependencies if someone tries.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/Kconfig | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index f488997b071712..4524db877eba36 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
>   
>   config DMA_GLOBAL_POOL
>   	select DMA_DECLARE_COHERENT
> +	depends on !ARCH_HAS_DMA_SET_UNCACHED
> +	depends on !DMA_DIRECT_REMAP
>   	bool
>   
>   config DMA_DIRECT_REMAP

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 11:33     ` Robin Murphy
  -1 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:33 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> Instead of using arch_dma_alloc if none of the generic coherent
> allocators are used, require the architectures to explicitly opt into
> providing it.  This will used to deal with the case of m68knommu and
> coldfire where we can't do any coherent allocations whatsoever, and
> also makes it clear that arch_dma_alloc is a last resort.

With one miniscule nit that possibly ARCH_HAS_DMA_ALLOC might be a 
little more consistent with other symbol names in this area (but feel 
free to disagree),

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   arch/arm/Kconfig    |  1 +
>   arch/m68k/Kconfig   |  1 +
>   arch/parisc/Kconfig |  1 +
>   kernel/dma/Kconfig  |  9 +++++++++
>   kernel/dma/direct.c | 12 ++----------
>   5 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9557808e8937b1..a3fdf584278f86 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -4,6 +4,7 @@ config ARM
>   	default y
>   	select ARCH_32BIT_OFF_T
>   	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
> +	select ARCH_DMA_ALLOC if MMU
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 3e318bf9504c5b..0430b8ba6b5cc6 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -3,6 +3,7 @@ config M68K
>   	bool
>   	default y
>   	select ARCH_32BIT_OFF_T
> +	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index a15ab147af2e07..30a4916fa9b0cc 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -3,6 +3,7 @@ config PARISC
>   	def_bool y
>   	select ALTERNATE_USER_ADDRESS_SPACE
>   	select ARCH_32BIT_OFF_T if !64BIT
> +	select ARCH_DMA_ALLOC if PA11
>   	select ARCH_MIGHT_HAVE_PC_PARPORT
>   	select HAVE_FUNCTION_TRACER
>   	select HAVE_FUNCTION_GRAPH_TRACER
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4524db877eba36..515d2063b509ac 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -144,6 +144,15 @@ config DMA_DIRECT_REMAP
>   	select DMA_COHERENT_POOL
>   	select DMA_NONCOHERENT_MMAP
>   
> +#
> +# Fallback to arch code for DMA allocations.  This should eventually go away.
> +#
> +config ARCH_DMA_ALLOC
> +	depends on !ARCH_HAS_DMA_SET_UNCACHED
> +	depends on !DMA_DIRECT_REMAP
> +	depends on !DMA_GLOBAL_POOL
> +	bool
> +
>   config DMA_CMA
>   	bool "DMA Contiguous Memory Allocator"
>   	depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 9596ae1aa0dacf..ec410af1d8a14e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -220,13 +220,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>   
>   	if (!dev_is_dma_coherent(dev)) {
> -		/*
> -		 * Fallback to the arch handler if it exists.  This should
> -		 * eventually go away.
> -		 */
> -		if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> -		    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> -		    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
> +		if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
>   		    !is_swiotlb_for_alloc(dev))
>   			return arch_dma_alloc(dev, size, dma_handle, gfp,
>   					      attrs);
> @@ -330,9 +324,7 @@ void dma_direct_free(struct device *dev, size_t size,
>   		return;
>   	}
>   
> -	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> -	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> -	    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
> +	if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
>   	    !dev_is_dma_coherent(dev) &&
>   	    !is_swiotlb_for_alloc(dev)) {
>   		arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol
@ 2023-10-16 11:33     ` Robin Murphy
  0 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:33 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> Instead of using arch_dma_alloc if none of the generic coherent
> allocators are used, require the architectures to explicitly opt into
> providing it.  This will used to deal with the case of m68knommu and
> coldfire where we can't do any coherent allocations whatsoever, and
> also makes it clear that arch_dma_alloc is a last resort.

With one miniscule nit that possibly ARCH_HAS_DMA_ALLOC might be a 
little more consistent with other symbol names in this area (but feel 
free to disagree),

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   arch/arm/Kconfig    |  1 +
>   arch/m68k/Kconfig   |  1 +
>   arch/parisc/Kconfig |  1 +
>   kernel/dma/Kconfig  |  9 +++++++++
>   kernel/dma/direct.c | 12 ++----------
>   5 files changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9557808e8937b1..a3fdf584278f86 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -4,6 +4,7 @@ config ARM
>   	default y
>   	select ARCH_32BIT_OFF_T
>   	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
> +	select ARCH_DMA_ALLOC if MMU
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 3e318bf9504c5b..0430b8ba6b5cc6 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -3,6 +3,7 @@ config M68K
>   	bool
>   	default y
>   	select ARCH_32BIT_OFF_T
> +	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index a15ab147af2e07..30a4916fa9b0cc 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -3,6 +3,7 @@ config PARISC
>   	def_bool y
>   	select ALTERNATE_USER_ADDRESS_SPACE
>   	select ARCH_32BIT_OFF_T if !64BIT
> +	select ARCH_DMA_ALLOC if PA11
>   	select ARCH_MIGHT_HAVE_PC_PARPORT
>   	select HAVE_FUNCTION_TRACER
>   	select HAVE_FUNCTION_GRAPH_TRACER
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4524db877eba36..515d2063b509ac 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -144,6 +144,15 @@ config DMA_DIRECT_REMAP
>   	select DMA_COHERENT_POOL
>   	select DMA_NONCOHERENT_MMAP
>   
> +#
> +# Fallback to arch code for DMA allocations.  This should eventually go away.
> +#
> +config ARCH_DMA_ALLOC
> +	depends on !ARCH_HAS_DMA_SET_UNCACHED
> +	depends on !DMA_DIRECT_REMAP
> +	depends on !DMA_GLOBAL_POOL
> +	bool
> +
>   config DMA_CMA
>   	bool "DMA Contiguous Memory Allocator"
>   	depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 9596ae1aa0dacf..ec410af1d8a14e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -220,13 +220,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>   
>   	if (!dev_is_dma_coherent(dev)) {
> -		/*
> -		 * Fallback to the arch handler if it exists.  This should
> -		 * eventually go away.
> -		 */
> -		if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> -		    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> -		    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
> +		if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
>   		    !is_swiotlb_for_alloc(dev))
>   			return arch_dma_alloc(dev, size, dma_handle, gfp,
>   					      attrs);
> @@ -330,9 +324,7 @@ void dma_direct_free(struct device *dev, size_t size,
>   		return;
>   	}
>   
> -	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> -	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> -	    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
> +	if (IS_ENABLED(CONFIG_ARCH_DMA_ALLOC) &&
>   	    !dev_is_dma_coherent(dev) &&
>   	    !is_swiotlb_for_alloc(dev)) {
>   		arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 11:58     ` Robin Murphy
  -1 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:58 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> The logic in dma_direct_alloc when to use the atomic pool vs remapping
> grew a bit unreadable.  Consolidate it into a single check, and clean
> up the set_uncached vs remap logic a bit as well.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/direct.c | 25 ++++++++++---------------
>   1 file changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index ec410af1d8a14e..1327d04fa32a25 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   					dma_handle);
>   
>   		/*
> -		 * Otherwise remap if the architecture is asking for it.  But
> -		 * given that remapping memory is a blocking operation we'll
> -		 * instead have to dip into the atomic pools.
> +		 * Otherwise we require the architecture to either be able to
> +		 * mark arbitrary parts of the kernel direct mapping uncached,
> +		 * or remapped it uncached.
>   		 */
> +		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
>   		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
> -		if (remap) {
> -			if (dma_direct_use_pool(dev, gfp))
> -				return dma_direct_alloc_from_pool(dev, size,
> -						dma_handle, gfp);
> -		} else {
> -			if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> -				return NULL;
> -			set_uncached = true;
> -		}
> +		if (!set_uncached && !remap)
> +			return NULL;
>   	}
>   
>   	/*
> -	 * Decrypting memory may block, so allocate the memory from the atomic
> -	 * pools if we can't block.
> +	 * Remapping or decrypting memory may block, allocate the memory from
> +	 * the atomic pools instead if we aren't allowed block.
>   	 */
> -	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
> +	if ((remap || force_dma_unencrypted(dev)) &&
> +	    dma_direct_use_pool(dev, gfp))
>   		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>   
>   	/* we always manually zero the memory once we are done */

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc
@ 2023-10-16 11:58     ` Robin Murphy
  0 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:58 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> The logic in dma_direct_alloc when to use the atomic pool vs remapping
> grew a bit unreadable.  Consolidate it into a single check, and clean
> up the set_uncached vs remap logic a bit as well.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/direct.c | 25 ++++++++++---------------
>   1 file changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index ec410af1d8a14e..1327d04fa32a25 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   					dma_handle);
>   
>   		/*
> -		 * Otherwise remap if the architecture is asking for it.  But
> -		 * given that remapping memory is a blocking operation we'll
> -		 * instead have to dip into the atomic pools.
> +		 * Otherwise we require the architecture to either be able to
> +		 * mark arbitrary parts of the kernel direct mapping uncached,
> +		 * or remapped it uncached.
>   		 */
> +		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
>   		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
> -		if (remap) {
> -			if (dma_direct_use_pool(dev, gfp))
> -				return dma_direct_alloc_from_pool(dev, size,
> -						dma_handle, gfp);
> -		} else {
> -			if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> -				return NULL;
> -			set_uncached = true;
> -		}
> +		if (!set_uncached && !remap)
> +			return NULL;
>   	}
>   
>   	/*
> -	 * Decrypting memory may block, so allocate the memory from the atomic
> -	 * pools if we can't block.
> +	 * Remapping or decrypting memory may block, allocate the memory from
> +	 * the atomic pools instead if we aren't allowed block.
>   	 */
> -	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
> +	if ((remap || force_dma_unencrypted(dev)) &&
> +	    dma_direct_use_pool(dev, gfp))
>   		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>   
>   	/* we always manually zero the memory once we are done */

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 11:59     ` Robin Murphy
  -1 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:59 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> Log a warning once when dma_alloc_coherent fails because the platform
> does not support coherent allocations at all.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/direct.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 1327d04fa32a25..fddfea3b2fe173 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -240,8 +240,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   		 */
>   		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
>   		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
> -		if (!set_uncached && !remap)
> +		if (!set_uncached && !remap) {
> +			pr_warn_once("coherent DMA allocations not supported on this platform.\n");
>   			return NULL;
> +		}
>   	}
>   
>   	/*

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported
@ 2023-10-16 11:59     ` Robin Murphy
  0 siblings, 0 replies; 78+ messages in thread
From: Robin Murphy @ 2023-10-16 11:59 UTC (permalink / raw)
  To: Christoph Hellwig, Greg Ungerer, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On 16/10/2023 6:47 am, Christoph Hellwig wrote:
> Log a warning once when dma_alloc_coherent fails because the platform
> does not support coherent allocations at all.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   kernel/dma/direct.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 1327d04fa32a25..fddfea3b2fe173 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -240,8 +240,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   		 */
>   		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
>   		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
> -		if (!set_uncached && !remap)
> +		if (!set_uncached && !remap) {
> +			pr_warn_once("coherent DMA allocations not supported on this platform.\n");
>   			return NULL;
> +		}
>   	}
>   
>   	/*

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 12:49     ` Conor Dooley
  -1 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:49 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

Hey,

On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> helpers, which are built into the kernel unconditionally.

You surely have better insight than I do here, but is this actually
required?
This patch seems to allow creation of a kernel where the cache
maintenance operations could be used for pmem, but would be otherwise
unavailable, which seems counter intuitive to me.
Why would someone want to provide the pmem helpers with cache
maintenance operations, but not provide them generally?

I also don't really understand what the unconditional nature of the pmem
helpers has to do with anything, as this patch does not unconditionally
provide any cache management operations, only relax the conditions under
which the non-standard cache management operations can be provided.

What am I missing?

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/riscv/Kconfig          | 1 -
>  drivers/cache/Kconfig       | 2 +-
>  drivers/soc/renesas/Kconfig | 2 +-
>  3 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d607ab0f7c6daf..0ac0b538379718 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -277,7 +277,6 @@ config RISCV_DMA_NONCOHERENT
>  
>  config RISCV_NONSTANDARD_CACHE_OPS
>  	bool
> -	depends on RISCV_DMA_NONCOHERENT
>  	help
>  	  This enables function pointer support for non-standard noncoherent
>  	  systems to handle cache management.
> diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> index a57677f908f3ba..d6e5e3abaad8af 100644
> --- a/drivers/cache/Kconfig
> +++ b/drivers/cache/Kconfig
> @@ -3,7 +3,7 @@ menu "Cache Drivers"
>  
>  config AX45MP_L2_CACHE
>  	bool "Andes Technology AX45MP L2 Cache controller"
> -	depends on RISCV_DMA_NONCOHERENT
> +	depends on RISCV
>  	select RISCV_NONSTANDARD_CACHE_OPS
>  	help
>  	  Support for the L2 cache controller on Andes Technology AX45MP platforms.
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 12040ce116a551..880c544bb2dfda 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -335,7 +335,7 @@ config ARCH_R9A07G043
>  	bool "RISC-V Platform support for RZ/Five"
>  	depends on NONPORTABLE
>  	select ARCH_RZG2L
> -	select AX45MP_L2_CACHE if RISCV_DMA_NONCOHERENT

FWIW, this one is already gone in linux-next, as part of fixing some
randconfig issues.

Cheers,
Conor.

> +	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
>  	select ERRATA_ANDES if RISCV_SBI
>  	select ERRATA_ANDES_CMO if ERRATA_ANDES
> -- 
> 2.39.2
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
@ 2023-10-16 12:49     ` Conor Dooley
  0 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:49 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan


[-- Attachment #1.1: Type: text/plain, Size: 2730 bytes --]

Hey,

On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> helpers, which are built into the kernel unconditionally.

You surely have better insight than I do here, but is this actually
required?
This patch seems to allow creation of a kernel where the cache
maintenance operations could be used for pmem, but would be otherwise
unavailable, which seems counter intuitive to me.
Why would someone want to provide the pmem helpers with cache
maintenance operations, but not provide them generally?

I also don't really understand what the unconditional nature of the pmem
helpers has to do with anything, as this patch does not unconditionally
provide any cache management operations, only relax the conditions under
which the non-standard cache management operations can be provided.

What am I missing?

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/riscv/Kconfig          | 1 -
>  drivers/cache/Kconfig       | 2 +-
>  drivers/soc/renesas/Kconfig | 2 +-
>  3 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d607ab0f7c6daf..0ac0b538379718 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -277,7 +277,6 @@ config RISCV_DMA_NONCOHERENT
>  
>  config RISCV_NONSTANDARD_CACHE_OPS
>  	bool
> -	depends on RISCV_DMA_NONCOHERENT
>  	help
>  	  This enables function pointer support for non-standard noncoherent
>  	  systems to handle cache management.
> diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> index a57677f908f3ba..d6e5e3abaad8af 100644
> --- a/drivers/cache/Kconfig
> +++ b/drivers/cache/Kconfig
> @@ -3,7 +3,7 @@ menu "Cache Drivers"
>  
>  config AX45MP_L2_CACHE
>  	bool "Andes Technology AX45MP L2 Cache controller"
> -	depends on RISCV_DMA_NONCOHERENT
> +	depends on RISCV
>  	select RISCV_NONSTANDARD_CACHE_OPS
>  	help
>  	  Support for the L2 cache controller on Andes Technology AX45MP platforms.
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 12040ce116a551..880c544bb2dfda 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -335,7 +335,7 @@ config ARCH_R9A07G043
>  	bool "RISC-V Platform support for RZ/Five"
>  	depends on NONPORTABLE
>  	select ARCH_RZG2L
> -	select AX45MP_L2_CACHE if RISCV_DMA_NONCOHERENT

FWIW, this one is already gone in linux-next, as part of fixing some
randconfig issues.

Cheers,
Conor.

> +	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
>  	select ERRATA_ANDES if RISCV_SBI
>  	select ERRATA_ANDES_CMO if ERRATA_ANDES
> -- 
> 2.39.2
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 12:52     ` Conor Dooley
  -1 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:52 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Mon, Oct 16, 2023 at 07:47:46AM +0200, Christoph Hellwig wrote:
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>  	select ARCH_RZG2L
>  	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
> +	select RISCV_DMA_NONCOHERENT
>  	select ERRATA_ANDES if RISCV_SBI
>  	select ERRATA_ANDES_CMO if ERRATA_ANDES

Since this Kconfig menu has changed a bit in linux-next, the selects
are unconditional here, and ERRATA_ANDES_CMO will in turn select
RISCV_DMA_NONCOHERENT.

I don't think being more explicit hurts anyone though, so
Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-16 12:52     ` Conor Dooley
  0 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:52 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan


[-- Attachment #1.1: Type: text/plain, Size: 1045 bytes --]

On Mon, Oct 16, 2023 at 07:47:46AM +0200, Christoph Hellwig wrote:
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>  	select ARCH_RZG2L
>  	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
> +	select RISCV_DMA_NONCOHERENT
>  	select ERRATA_ANDES if RISCV_SBI
>  	select ERRATA_ANDES_CMO if ERRATA_ANDES

Since this Kconfig menu has changed a bit in linux-next, the selects
are unconditional here, and ERRATA_ANDES_CMO will in turn select
RISCV_DMA_NONCOHERENT.

I don't think being more explicit hurts anyone though, so
Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 12:53     ` Conor Dooley
  -1 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Mon, Oct 16, 2023 at 07:47:45AM +0200, Christoph Hellwig wrote:
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 880c544bb2dfda..f1696d3b5018d0 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -334,6 +334,7 @@ if RISCV
>  config ARCH_R9A07G043
>  	bool "RISC-V Platform support for RZ/Five"
>  	depends on NONPORTABLE
> +	depends on !RISCV_ISA_ZICBOM
>  	select ARCH_RZG2L
>  	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
> -- 
> 2.39.2
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
@ 2023-10-16 12:53     ` Conor Dooley
  0 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan


[-- Attachment #1.1: Type: text/plain, Size: 924 bytes --]

On Mon, Oct 16, 2023 at 07:47:45AM +0200, Christoph Hellwig wrote:
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 880c544bb2dfda..f1696d3b5018d0 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -334,6 +334,7 @@ if RISCV
>  config ARCH_R9A07G043
>  	bool "RISC-V Platform support for RZ/Five"
>  	depends on NONPORTABLE
> +	depends on !RISCV_ISA_ZICBOM
>  	select ARCH_RZG2L
>  	select AX45MP_L2_CACHE
>  	select DMA_GLOBAL_POOL
> -- 
> 2.39.2
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 12:55     ` Conor Dooley
  -1 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:55 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Mon, Oct 16, 2023 at 07:47:44AM +0200, Christoph Hellwig wrote:
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> ---
>  arch/riscv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>  	select ARCH_HAS_SYNC_DMA_FOR_CPU
>  	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>  	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -	select DMA_DIRECT_REMAP if MMU
>  
>  config RISCV_NONSTANDARD_CACHE_OPS
>  	bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>  	depends on RISCV_ALTERNATIVE
>  	default y
>  	select RISCV_DMA_NONCOHERENT
> +	select DMA_DIRECT_REMAP
>  	help
>  	   Adds support to dynamically detect the presence of the ZICBOM
>  	   extension (Cache Block Management Operations) and enable its
> -- 
> 2.39.2
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
@ 2023-10-16 12:55     ` Conor Dooley
  0 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 12:55 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan


[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

On Mon, Oct 16, 2023 at 07:47:44AM +0200, Christoph Hellwig wrote:
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> ---
>  arch/riscv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>  	select ARCH_HAS_SYNC_DMA_FOR_CPU
>  	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>  	select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -	select DMA_DIRECT_REMAP if MMU
>  
>  config RISCV_NONSTANDARD_CACHE_OPS
>  	bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>  	depends on RISCV_ALTERNATIVE
>  	default y
>  	select RISCV_DMA_NONCOHERENT
> +	select DMA_DIRECT_REMAP
>  	help
>  	   Adds support to dynamically detect the presence of the ZICBOM
>  	   extension (Cache Block Management Operations) and enable its
> -- 
> 2.39.2
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
  2023-10-16 12:49     ` Conor Dooley
@ 2023-10-16 13:17       ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16 13:17 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Christoph Hellwig, Greg Ungerer, iommu, Paul Walmsley,
	Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 01:49:41PM +0100, Conor Dooley wrote:
> Hey,
> 
> On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> > RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> > helpers, which are built into the kernel unconditionally.
> 
> You surely have better insight than I do here, but is this actually
> required?
> This patch seems to allow creation of a kernel where the cache
> maintenance operations could be used for pmem, but would be otherwise
> unavailable, which seems counter intuitive to me.
>
> Why would someone want to provide the pmem helpers with cache
> maintenance operations, but not provide them generally?
> 

Even if all your periphals are cache coherent (very common on server
class hardware) you still need cache maintenance for pmem.  No need
to force the extra text size and runtime overhead for non-coherent DMA.

> I also don't really understand what the unconditional nature of the pmem
> helpers has to do with anything, as this patch does not unconditionally
> provide any cache management operations, only relax the conditions under
> which the non-standard cache management operations can be provided.

They simply were broken if a platform had non-standard cache mem but
only coherent DMA before.  That's probably more a theoretical than
practial case, but still worth fixing.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
@ 2023-10-16 13:17       ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16 13:17 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Christoph Hellwig, Greg Ungerer, iommu, Paul Walmsley,
	Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 01:49:41PM +0100, Conor Dooley wrote:
> Hey,
> 
> On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> > RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> > helpers, which are built into the kernel unconditionally.
> 
> You surely have better insight than I do here, but is this actually
> required?
> This patch seems to allow creation of a kernel where the cache
> maintenance operations could be used for pmem, but would be otherwise
> unavailable, which seems counter intuitive to me.
>
> Why would someone want to provide the pmem helpers with cache
> maintenance operations, but not provide them generally?
> 

Even if all your periphals are cache coherent (very common on server
class hardware) you still need cache maintenance for pmem.  No need
to force the extra text size and runtime overhead for non-coherent DMA.

> I also don't really understand what the unconditional nature of the pmem
> helpers has to do with anything, as this patch does not unconditionally
> provide any cache management operations, only relax the conditions under
> which the non-standard cache management operations can be provided.

They simply were broken if a platform had non-standard cache mem but
only coherent DMA before.  That's probably more a theoretical than
practial case, but still worth fixing.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16 12:52     ` Conor Dooley
@ 2023-10-16 13:17       ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16 13:17 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Christoph Hellwig, Greg Ungerer, iommu, Paul Walmsley,
	Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > +	select RISCV_DMA_NONCOHERENT
> >  	select ERRATA_ANDES if RISCV_SBI
> >  	select ERRATA_ANDES_CMO if ERRATA_ANDES
> 
> Since this Kconfig menu has changed a bit in linux-next, the selects
> are unconditional here, and ERRATA_ANDES_CMO will in turn select
> RISCV_DMA_NONCOHERENT.

Oh, looks like another patch landed there in linux-next.  I had
waited for the previous one go go upstream in -rc6.  Not sure
how to best handle this conflict.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-16 13:17       ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-16 13:17 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Christoph Hellwig, Greg Ungerer, iommu, Paul Walmsley,
	Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Geert Uytterhoeven, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > +	select RISCV_DMA_NONCOHERENT
> >  	select ERRATA_ANDES if RISCV_SBI
> >  	select ERRATA_ANDES_CMO if ERRATA_ANDES
> 
> Since this Kconfig menu has changed a bit in linux-next, the selects
> are unconditional here, and ERRATA_ANDES_CMO will in turn select
> RISCV_DMA_NONCOHERENT.

Oh, looks like another patch landed there in linux-next.  I had
waited for the previous one go go upstream in -rc6.  Not sure
how to best handle this conflict.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 15:39     ` Lad, Prabhakar
  -1 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:39 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/riscv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>         select ARCH_HAS_SYNC_DMA_FOR_CPU
>         select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>         select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -       select DMA_DIRECT_REMAP if MMU
>
>  config RISCV_NONSTANDARD_CACHE_OPS
>         bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>         depends on RISCV_ALTERNATIVE
>         default y
>         select RISCV_DMA_NONCOHERENT
> +       select DMA_DIRECT_REMAP
>         help
>            Adds support to dynamically detect the presence of the ZICBOM
>            extension (Cache Block Management Operations) and enable its
> --
> 2.39.2
>

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM
@ 2023-10-16 15:39     ` Lad, Prabhakar
  0 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:39 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> RISCV_DMA_NONCOHERENT is also used for whacky non-standard
> non-coherent ops that use different hooks in dma-direct.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/riscv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 0ac0b538379718..9c48fecc671918 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,7 +273,6 @@ config RISCV_DMA_NONCOHERENT
>         select ARCH_HAS_SYNC_DMA_FOR_CPU
>         select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>         select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
> -       select DMA_DIRECT_REMAP if MMU
>
>  config RISCV_NONSTANDARD_CACHE_OPS
>         bool
> @@ -549,6 +548,7 @@ config RISCV_ISA_ZICBOM
>         depends on RISCV_ALTERNATIVE
>         default y
>         select RISCV_DMA_NONCOHERENT
> +       select DMA_DIRECT_REMAP
>         help
>            Adds support to dynamically detect the presence of the ZICBOM
>            extension (Cache Block Management Operations) and enable its
> --
> 2.39.2
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 15:40     ` Lad, Prabhakar
  -1 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:40 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 880c544bb2dfda..f1696d3b5018d0 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -334,6 +334,7 @@ if RISCV
>  config ARCH_R9A07G043
>         bool "RISC-V Platform support for RZ/Five"
>         depends on NONPORTABLE
> +       depends on !RISCV_ISA_ZICBOM
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> --
> 2.39.2
>

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
@ 2023-10-16 15:40     ` Lad, Prabhakar
  0 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:40 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent
> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 880c544bb2dfda..f1696d3b5018d0 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -334,6 +334,7 @@ if RISCV
>  config ARCH_R9A07G043
>         bool "RISC-V Platform support for RZ/Five"
>         depends on NONPORTABLE
> +       depends on !RISCV_ISA_ZICBOM
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> --
> 2.39.2
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 15:42     ` Lad, Prabhakar
  -1 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:42 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> +       select RISCV_DMA_NONCOHERENT
Can we keep this alphabetical sorted please, with that fixed:

Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

>         select ERRATA_ANDES if RISCV_SBI
>         select ERRATA_ANDES_CMO if ERRATA_ANDES
>
> --
> 2.39.2
>

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-16 15:42     ` Lad, Prabhakar
  0 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:42 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> +       select RISCV_DMA_NONCOHERENT
Can we keep this alphabetical sorted please, with that fixed:

Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

>         select ERRATA_ANDES if RISCV_SBI
>         select ERRATA_ANDES_CMO if ERRATA_ANDES
>
> --
> 2.39.2
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-16 15:44     ` Lad, Prabhakar
  -1 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:44 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
> allocators.  Add dependencies to Kconfig to document this, and make
> kconfig complain about unment dependencies if someone tries.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  kernel/dma/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index f488997b071712..4524db877eba36 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
>
>  config DMA_GLOBAL_POOL
>         select DMA_DECLARE_COHERENT
> +       depends on !ARCH_HAS_DMA_SET_UNCACHED
> +       depends on !DMA_DIRECT_REMAP
>         bool
>
>  config DMA_DIRECT_REMAP
> --
> 2.39.2
>

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL
@ 2023-10-16 15:44     ` Lad, Prabhakar
  0 siblings, 0 replies; 78+ messages in thread
From: Lad, Prabhakar @ 2023-10-16 15:44 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 6:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
> allocators.  Add dependencies to Kconfig to document this, and make
> kconfig complain about unment dependencies if someone tries.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  kernel/dma/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index f488997b071712..4524db877eba36 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -135,6 +135,8 @@ config DMA_COHERENT_POOL
>
>  config DMA_GLOBAL_POOL
>         select DMA_DECLARE_COHERENT
> +       depends on !ARCH_HAS_DMA_SET_UNCACHED
> +       depends on !DMA_DIRECT_REMAP
>         bool
>
>  config DMA_DIRECT_REMAP
> --
> 2.39.2
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
  2023-10-16 13:17       ` Christoph Hellwig
@ 2023-10-16 17:16         ` Conor Dooley
  -1 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 17:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Mon, Oct 16, 2023 at 03:17:16PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 16, 2023 at 01:49:41PM +0100, Conor Dooley wrote:
> > Hey,
> > 
> > On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> > > RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> > > helpers, which are built into the kernel unconditionally.
> > 
> > You surely have better insight than I do here, but is this actually
> > required?
> > This patch seems to allow creation of a kernel where the cache
> > maintenance operations could be used for pmem, but would be otherwise
> > unavailable, which seems counter intuitive to me.
> >
> > Why would someone want to provide the pmem helpers with cache
> > maintenance operations, but not provide them generally?
> > 
> 
> Even if all your periphals are cache coherent (very common on server
> class hardware) you still need cache maintenance for pmem.  No need
> to force the extra text size and runtime overhead for non-coherent DMA.

Ah, right.

> > I also don't really understand what the unconditional nature of the pmem
> > helpers has to do with anything, as this patch does not unconditionally
> > provide any cache management operations, only relax the conditions under
> > which the non-standard cache management operations can be provided.
> 
> They simply were broken if a platform had non-standard cache mem but
> only coherent DMA before.  That's probably more a theoretical than
> practial case, but still worth fixing.

And this part of it makes more sense with the above use-case explained.

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
@ 2023-10-16 17:16         ` Conor Dooley
  0 siblings, 0 replies; 78+ messages in thread
From: Conor Dooley @ 2023-10-16 17:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Geert Uytterhoeven, Wei Fang, Shenwei Wang, Clark Wang,
	NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan


[-- Attachment #1.1: Type: text/plain, Size: 1679 bytes --]

On Mon, Oct 16, 2023 at 03:17:16PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 16, 2023 at 01:49:41PM +0100, Conor Dooley wrote:
> > Hey,
> > 
> > On Mon, Oct 16, 2023 at 07:47:43AM +0200, Christoph Hellwig wrote:
> > > RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance
> > > helpers, which are built into the kernel unconditionally.
> > 
> > You surely have better insight than I do here, but is this actually
> > required?
> > This patch seems to allow creation of a kernel where the cache
> > maintenance operations could be used for pmem, but would be otherwise
> > unavailable, which seems counter intuitive to me.
> >
> > Why would someone want to provide the pmem helpers with cache
> > maintenance operations, but not provide them generally?
> > 
> 
> Even if all your periphals are cache coherent (very common on server
> class hardware) you still need cache maintenance for pmem.  No need
> to force the extra text size and runtime overhead for non-coherent DMA.

Ah, right.

> > I also don't really understand what the unconditional nature of the pmem
> > helpers has to do with anything, as this patch does not unconditionally
> > provide any cache management operations, only relax the conditions under
> > which the non-standard cache management operations can be provided.
> 
> They simply were broken if a platform had non-standard cache mem but
> only coherent DMA before.  That's probably more a theoretical than
> practial case, but still worth fixing.

And this part of it makes more sense with the above use-case explained.

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-17  7:59     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  7:59 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent

its

> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
@ 2023-10-17  7:59     ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  7:59 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> ARCH_R9A07G043 has it's own non-standard global pool based DMA coherent

its

> allocator, which conflicts with the remap based RISCV_ISA_ZICBOM version.
> Add a proper dependency.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-17  8:20     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:20 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> +       select RISCV_DMA_NONCOHERENT
>         select ERRATA_ANDES if RISCV_SBI
>         select ERRATA_ANDES_CMO if ERRATA_ANDES

With proper sort order, and rebased to soc/for-next:
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-17  8:20     ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:20 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Selecting DMA_GLOBAL_POOL without the rest of the non-coherent DMA
> infrastructure does not make sense.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/soc/renesas/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index f1696d3b5018d0..ea473b4150dfa8 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -338,6 +338,7 @@ config ARCH_R9A07G043
>         select ARCH_RZG2L
>         select AX45MP_L2_CACHE
>         select DMA_GLOBAL_POOL
> +       select RISCV_DMA_NONCOHERENT
>         select ERRATA_ANDES if RISCV_SBI
>         select ERRATA_ANDES_CMO if ERRATA_ANDES

With proper sort order, and rebased to soc/for-next:
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-17  8:40     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:40 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Coldfire cores configured without a data cache are DMA coherent and
> should thus simply use the simple coherent version of dma-direct.
>
> Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
> short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
> for all cases where we need to build non-coherent DMA infrastructure
> to simplify the Kconfig and code conditionals.
>
> Not building the non-coherent DMA code slightly reduces the code
> size for such configurations.
>
> Numers for m5249evb_defconfig below:
>
>   text     data     bss     dec     hex filename
> 2896158  401052   65392 3362602  334f2a vmlinux.before
> 2895166  400988   65392 3361546  334b0a vmlinux.after
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

The m68kclassic-with-MMU parts look fine to me, so
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

I'll defer to Greg for the nommu and Coldfire parts...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
@ 2023-10-17  8:40     ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:40 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Wei Fang,
	Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k, netdev,
	linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Coldfire cores configured without a data cache are DMA coherent and
> should thus simply use the simple coherent version of dma-direct.
>
> Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
> short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
> for all cases where we need to build non-coherent DMA infrastructure
> to simplify the Kconfig and code conditionals.
>
> Not building the non-coherent DMA code slightly reduces the code
> size for such configurations.
>
> Numers for m5249evb_defconfig below:
>
>   text     data     bss     dec     hex filename
> 2896158  401052   65392 3362602  334f2a vmlinux.before
> 2895166  400988   65392 3361546  334b0a vmlinux.after
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

The m68kclassic-with-MMU parts look fine to me, so
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

I'll defer to Greg for the nommu and Coldfire parts...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-17  8:43     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Coldfire platforms with data caches can't properly implement
> dma_alloc_coherent and currently just return noncoherent memory from
> dma_alloc_coherent.
>
> The fec driver than works around this with a flush of all caches in the
> receive path. Make this hack a little less bad by using the explicit
> dma_alloc_noncoherent API and documenting the hacky cache flushes so
> that the DMA API level hack can be removed.
>
> Also replace the check for CONFIG_M532x for said hack with a check
> for COLDFIRE && !COLDFIRE_COHERENT_DMA.  While m532x is the only such
> platform with a fec module, this makes the code more consistent and
> easier to follow.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Thanks for your patch!

> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -406,6 +406,70 @@ static void fec_dump(struct net_device *ndev)
>         } while (bdp != txq->bd.base);
>  }
>
> +/*
> + * Coldfire does not support DMA coherent allocations, and has historically used
> + * a band-aid with a manual flush in fec_enet_rx_queue.
> + */
> +#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
> +static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> +               gfp_t gfp)
> +{
> +       return dma_alloc_noncoherent(dev, size, handle, DMA_BIDIRECTIONAL, gfp);
> +}
> +
> +static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
> +               dma_addr_t handle)
> +{
> +       dma_free_noncoherent(dev, size, cpu_addr, handle, DMA_BIDIRECTIONAL);
> +}
> +#else /* CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */

!CONFIG_COLDFIRE || CONFIG_COLDFIRE_COHERENT_DMA

> +static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> +               gfp_t gfp)
> +{
> +       return dma_alloc_coherent(dev, size, handle, gfp);
> +}
> +
> +static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
> +               dma_addr_t handle)
> +{
> +       dma_free_coherent(dev, size, cpu_addr, handle);
> +}
> +#endif /* !CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */

!CONFIG_COLDFIRE || CONFIG_COLDFIRE_COHERENT_DMA

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
@ 2023-10-17  8:43     ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Coldfire platforms with data caches can't properly implement
> dma_alloc_coherent and currently just return noncoherent memory from
> dma_alloc_coherent.
>
> The fec driver than works around this with a flush of all caches in the
> receive path. Make this hack a little less bad by using the explicit
> dma_alloc_noncoherent API and documenting the hacky cache flushes so
> that the DMA API level hack can be removed.
>
> Also replace the check for CONFIG_M532x for said hack with a check
> for COLDFIRE && !COLDFIRE_COHERENT_DMA.  While m532x is the only such
> platform with a fec module, this makes the code more consistent and
> easier to follow.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Thanks for your patch!

> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -406,6 +406,70 @@ static void fec_dump(struct net_device *ndev)
>         } while (bdp != txq->bd.base);
>  }
>
> +/*
> + * Coldfire does not support DMA coherent allocations, and has historically used
> + * a band-aid with a manual flush in fec_enet_rx_queue.
> + */
> +#if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
> +static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> +               gfp_t gfp)
> +{
> +       return dma_alloc_noncoherent(dev, size, handle, DMA_BIDIRECTIONAL, gfp);
> +}
> +
> +static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
> +               dma_addr_t handle)
> +{
> +       dma_free_noncoherent(dev, size, cpu_addr, handle, DMA_BIDIRECTIONAL);
> +}
> +#else /* CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */

!CONFIG_COLDFIRE || CONFIG_COLDFIRE_COHERENT_DMA

> +static void *fec_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> +               gfp_t gfp)
> +{
> +       return dma_alloc_coherent(dev, size, handle, gfp);
> +}
> +
> +static void fec_dma_free(struct device *dev, size_t size, void *cpu_addr,
> +               dma_addr_t handle)
> +{
> +       dma_free_coherent(dev, size, cpu_addr, handle);
> +}
> +#endif /* !CONFIG_COLDFIRE && !CONFIG_COLDFIRE_COHERENT_DMA */

!CONFIG_COLDFIRE || CONFIG_COLDFIRE_COHERENT_DMA

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 12/12] m68k: remove unused includes from dma.c
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-17  8:48     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:48 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> dma.c doesn't need most of the headers it includes.  Also there is
> no point in undefining the DEBUG symbol given that it isn't used
> anywhere in this small file.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 12/12] m68k: remove unused includes from dma.c
@ 2023-10-17  8:48     ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17  8:48 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

On Mon, Oct 16, 2023 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
> dma.c doesn't need most of the headers it includes.  Also there is
> no point in undefining the DEBUG symbol given that it isn't used
> anywhere in this small file.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-16 13:17       ` Christoph Hellwig
@ 2023-10-17 10:44         ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17 10:44 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Conor Dooley, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan, arm-soc

Hi Christoph,

On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > +   select RISCV_DMA_NONCOHERENT
> > >     select ERRATA_ANDES if RISCV_SBI
> > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> >
> > Since this Kconfig menu has changed a bit in linux-next, the selects
> > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > RISCV_DMA_NONCOHERENT.
>
> Oh, looks like another patch landed there in linux-next.  I had
> waited for the previous one go go upstream in -rc6.  Not sure
> how to best handle this conflict.

I think the easiest is to ask soc to apply this series?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-17 10:44         ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17 10:44 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Conor Dooley, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan, arm-soc

Hi Christoph,

On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > +   select RISCV_DMA_NONCOHERENT
> > >     select ERRATA_ANDES if RISCV_SBI
> > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> >
> > Since this Kconfig menu has changed a bit in linux-next, the selects
> > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > RISCV_DMA_NONCOHERENT.
>
> Oh, looks like another patch landed there in linux-next.  I had
> waited for the previous one go go upstream in -rc6.  Not sure
> how to best handle this conflict.

I think the easiest is to ask soc to apply this series?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-17 10:44         ` Geert Uytterhoeven
@ 2023-10-17 12:46           ` Christoph Hellwig
  -1 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-17 12:46 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Christoph Hellwig, Conor Dooley, Greg Ungerer, iommu,
	Paul Walmsley, Palmer Dabbelt, Conor Dooley, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Wei Fang, Shenwei Wang,
	Clark Wang, NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan, arm-soc

On Tue, Oct 17, 2023 at 12:44:41PM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
> 
> On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> > On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > > +   select RISCV_DMA_NONCOHERENT
> > > >     select ERRATA_ANDES if RISCV_SBI
> > > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> > >
> > > Since this Kconfig menu has changed a bit in linux-next, the selects
> > > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > > RISCV_DMA_NONCOHERENT.
> >
> > Oh, looks like another patch landed there in linux-next.  I had
> > waited for the previous one go go upstream in -rc6.  Not sure
> > how to best handle this conflict.
> 
> I think the easiest is to ask soc to apply this series?

I don't think pulling all the DMA bits into a random other tree
would be a good idea.   I can hand off the first few bits, but I'd
need a stable branch to pull in after that.  Which of the half a dozen
soc trees we have in linux-next is this anyway?

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-17 12:46           ` Christoph Hellwig
  0 siblings, 0 replies; 78+ messages in thread
From: Christoph Hellwig @ 2023-10-17 12:46 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Christoph Hellwig, Conor Dooley, Greg Ungerer, iommu,
	Paul Walmsley, Palmer Dabbelt, Conor Dooley, Magnus Damm,
	Robin Murphy, Marek Szyprowski, Wei Fang, Shenwei Wang,
	Clark Wang, NXP Linux Team, linux-m68k, netdev, linux-riscv,
	linux-renesas-soc, Jim Quinlan, arm-soc

On Tue, Oct 17, 2023 at 12:44:41PM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
> 
> On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> > On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > > +   select RISCV_DMA_NONCOHERENT
> > > >     select ERRATA_ANDES if RISCV_SBI
> > > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> > >
> > > Since this Kconfig menu has changed a bit in linux-next, the selects
> > > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > > RISCV_DMA_NONCOHERENT.
> >
> > Oh, looks like another patch landed there in linux-next.  I had
> > waited for the previous one go go upstream in -rc6.  Not sure
> > how to best handle this conflict.
> 
> I think the easiest is to ask soc to apply this series?

I don't think pulling all the DMA bits into a random other tree
would be a good idea.   I can hand off the first few bits, but I'd
need a stable branch to pull in after that.  Which of the half a dozen
soc trees we have in linux-next is this anyway?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
  2023-10-17 12:46           ` Christoph Hellwig
@ 2023-10-17 13:12             ` Geert Uytterhoeven
  -1 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17 13:12 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Conor Dooley, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan, arm-soc

Hi Christoph,

On Tue, Oct 17, 2023 at 2:46 PM Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Oct 17, 2023 at 12:44:41PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> > > On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > > > +   select RISCV_DMA_NONCOHERENT
> > > > >     select ERRATA_ANDES if RISCV_SBI
> > > > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> > > >
> > > > Since this Kconfig menu has changed a bit in linux-next, the selects
> > > > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > > > RISCV_DMA_NONCOHERENT.
> > >
> > > Oh, looks like another patch landed there in linux-next.  I had
> > > waited for the previous one go go upstream in -rc6.  Not sure
> > > how to best handle this conflict.
> >
> > I think the easiest is to ask soc to apply this series?
>
> I don't think pulling all the DMA bits into a random other tree
> would be a good idea.   I can hand off the first few bits, but I'd
> need a stable branch to pull in after that.  Which of the half a dozen
> soc trees we have in linux-next is this anyway?

The one and only https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043
@ 2023-10-17 13:12             ` Geert Uytterhoeven
  0 siblings, 0 replies; 78+ messages in thread
From: Geert Uytterhoeven @ 2023-10-17 13:12 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Conor Dooley, Greg Ungerer, iommu, Paul Walmsley, Palmer Dabbelt,
	Conor Dooley, Magnus Damm, Robin Murphy, Marek Szyprowski,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan, arm-soc

Hi Christoph,

On Tue, Oct 17, 2023 at 2:46 PM Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Oct 17, 2023 at 12:44:41PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Oct 16, 2023 at 3:17 PM Christoph Hellwig <hch@lst.de> wrote:
> > > On Mon, Oct 16, 2023 at 01:52:57PM +0100, Conor Dooley wrote:
> > > > > +   select RISCV_DMA_NONCOHERENT
> > > > >     select ERRATA_ANDES if RISCV_SBI
> > > > >     select ERRATA_ANDES_CMO if ERRATA_ANDES
> > > >
> > > > Since this Kconfig menu has changed a bit in linux-next, the selects
> > > > are unconditional here, and ERRATA_ANDES_CMO will in turn select
> > > > RISCV_DMA_NONCOHERENT.
> > >
> > > Oh, looks like another patch landed there in linux-next.  I had
> > > waited for the previous one go go upstream in -rc6.  Not sure
> > > how to best handle this conflict.
> >
> > I think the easiest is to ask soc to apply this series?
>
> I don't think pulling all the DMA bits into a random other tree
> would be a good idea.   I can hand off the first few bits, but I'd
> need a stable branch to pull in after that.  Which of the half a dozen
> soc trees we have in linux-next is this anyway?

The one and only https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
  2023-10-16  5:47   ` Christoph Hellwig
@ 2023-10-19 12:50     ` Greg Ungerer
  -1 siblings, 0 replies; 78+ messages in thread
From: Greg Ungerer @ 2023-10-19 12:50 UTC (permalink / raw)
  To: Christoph Hellwig, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On 16/10/23 15:47, Christoph Hellwig wrote:
> Coldfire cores configured without a data cache are DMA coherent and
> should thus simply use the simple coherent version of dma-direct.
> 
> Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
> short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
> for all cases where we need to build non-coherent DMA infrastructure
> to simplify the Kconfig and code conditionals.
> 
> Not building the non-coherent DMA code slightly reduces the code
> size for such configurations.
> 
> Numers for m5249evb_defconfig below:
> 
>    text	   data	    bss	    dec	    hex	filename
> 2896158	 401052	  65392	3362602	 334f2a	vmlinux.before
> 2895166	 400988	  65392	3361546	 334b0a	vmlinux.after
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   arch/m68k/Kconfig         |  8 ++++----
>   arch/m68k/Kconfig.cpu     | 12 ++++++++++++
>   arch/m68k/kernel/Makefile |  2 +-
>   arch/m68k/kernel/dma.c    |  2 +-
>   4 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 0430b8ba6b5cc6..6c585eae89f4dc 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -3,19 +3,19 @@ config M68K
>   	bool
>   	default y
>   	select ARCH_32BIT_OFF_T
> -	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
> +	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> -	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
> -	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
> +	select ARCH_HAS_DMA_PREP_COHERENT if M68K_NONCOHERENT_DMA && !COLDFIRE
> +	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if M68K_NONCOHERENT_DMA
>   	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
>   	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
>   	select ARCH_NO_PREEMPT if !COLDFIRE
>   	select ARCH_USE_MEMTEST if MMU_MOTOROLA
>   	select ARCH_WANT_IPC_PARSE_VERSION
>   	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
> -	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
> +	select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
>   	select GENERIC_ATOMIC64
>   	select GENERIC_CPU_DEVICES
>   	select GENERIC_IOMAP
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index b826e9c677b2ae..e8905d38c714c4 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -535,3 +535,15 @@ config CACHE_COPYBACK
>   	  The ColdFire CPU cache is set into Copy-back mode.
>   endchoice
>   endif # HAVE_CACHE_CB
> +
> +# Coldfire cores that do not have a data cache configured can do coherent DMA.
> +config COLDFIRE_COHERENT_DMA
> +	bool
> +	default y
> +	depends on COLDFIRE
> +	depends on !HAVE_CACHE_CB && !CONFIG_CACHE_D && !CONFIG_CACHE_BOTH
                                       ^^^^^^             ^^^^^^

This needs to be "depends on !HAVE_CACHE_CB && !CACHE_D && !CACHE_BOTH".

Regards
Greg


> +
> +config M68K_NONCOHERENT_DMA
> +	bool
> +	default y
> +	depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
> diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
> index af015447dfb4c1..01fb69a5095f43 100644
> --- a/arch/m68k/kernel/Makefile
> +++ b/arch/m68k/kernel/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
>   obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
>   obj-$(CONFIG_PCI) += pcibios.o
>   
> -obj-$(CONFIG_HAS_DMA)	+= dma.o
> +obj-$(CONFIG_M68K_NONCOHERENT_DMA) += dma.o
>   
>   obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
>   obj-$(CONFIG_BOOTINFO_PROC)	+= bootinfo_proc.o
> diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
> index 2e192a5df949bb..f83870cfa79b37 100644
> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -17,7 +17,7 @@
>   
>   #include <asm/cacheflush.h>
>   
> -#if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
> +#ifndef CONFIG_COLDFIRE
>   void arch_dma_prep_coherent(struct page *page, size_t size)
>   {
>   	cache_push(page_to_phys(page), size);

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache
@ 2023-10-19 12:50     ` Greg Ungerer
  0 siblings, 0 replies; 78+ messages in thread
From: Greg Ungerer @ 2023-10-19 12:50 UTC (permalink / raw)
  To: Christoph Hellwig, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On 16/10/23 15:47, Christoph Hellwig wrote:
> Coldfire cores configured without a data cache are DMA coherent and
> should thus simply use the simple coherent version of dma-direct.
> 
> Introduce a new COLDFIRE_COHERENT_DMA Kconfig symbol as a convenient
> short hand for such configurations, and a M68K_NONCOHERENT_DMA symbol
> for all cases where we need to build non-coherent DMA infrastructure
> to simplify the Kconfig and code conditionals.
> 
> Not building the non-coherent DMA code slightly reduces the code
> size for such configurations.
> 
> Numers for m5249evb_defconfig below:
> 
>    text	   data	    bss	    dec	    hex	filename
> 2896158	 401052	  65392	3362602	 334f2a	vmlinux.before
> 2895166	 400988	  65392	3361546	 334b0a	vmlinux.after
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   arch/m68k/Kconfig         |  8 ++++----
>   arch/m68k/Kconfig.cpu     | 12 ++++++++++++
>   arch/m68k/kernel/Makefile |  2 +-
>   arch/m68k/kernel/dma.c    |  2 +-
>   4 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 0430b8ba6b5cc6..6c585eae89f4dc 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -3,19 +3,19 @@ config M68K
>   	bool
>   	default y
>   	select ARCH_32BIT_OFF_T
> -	select ARCH_DMA_ALLOC if !MMU || COLDFIRE
> +	select ARCH_DMA_ALLOC if M68K_NONCOHERENT_DMA && COLDFIRE
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
>   	select ARCH_HAS_CURRENT_STACK_POINTER
> -	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
> -	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
> +	select ARCH_HAS_DMA_PREP_COHERENT if M68K_NONCOHERENT_DMA && !COLDFIRE
> +	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if M68K_NONCOHERENT_DMA
>   	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
>   	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
>   	select ARCH_NO_PREEMPT if !COLDFIRE
>   	select ARCH_USE_MEMTEST if MMU_MOTOROLA
>   	select ARCH_WANT_IPC_PARSE_VERSION
>   	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
> -	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
> +	select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
>   	select GENERIC_ATOMIC64
>   	select GENERIC_CPU_DEVICES
>   	select GENERIC_IOMAP
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index b826e9c677b2ae..e8905d38c714c4 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -535,3 +535,15 @@ config CACHE_COPYBACK
>   	  The ColdFire CPU cache is set into Copy-back mode.
>   endchoice
>   endif # HAVE_CACHE_CB
> +
> +# Coldfire cores that do not have a data cache configured can do coherent DMA.
> +config COLDFIRE_COHERENT_DMA
> +	bool
> +	default y
> +	depends on COLDFIRE
> +	depends on !HAVE_CACHE_CB && !CONFIG_CACHE_D && !CONFIG_CACHE_BOTH
                                       ^^^^^^             ^^^^^^

This needs to be "depends on !HAVE_CACHE_CB && !CACHE_D && !CACHE_BOTH".

Regards
Greg


> +
> +config M68K_NONCOHERENT_DMA
> +	bool
> +	default y
> +	depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
> diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
> index af015447dfb4c1..01fb69a5095f43 100644
> --- a/arch/m68k/kernel/Makefile
> +++ b/arch/m68k/kernel/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
>   obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
>   obj-$(CONFIG_PCI) += pcibios.o
>   
> -obj-$(CONFIG_HAS_DMA)	+= dma.o
> +obj-$(CONFIG_M68K_NONCOHERENT_DMA) += dma.o
>   
>   obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
>   obj-$(CONFIG_BOOTINFO_PROC)	+= bootinfo_proc.o
> diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
> index 2e192a5df949bb..f83870cfa79b37 100644
> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -17,7 +17,7 @@
>   
>   #include <asm/cacheflush.h>
>   
> -#if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
> +#ifndef CONFIG_COLDFIRE
>   void arch_dma_prep_coherent(struct page *page, size_t size)
>   {
>   	cache_push(page_to_phys(page), size);

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: fix the non-coherent coldfire dma_alloc_coherent v2
  2023-10-16  5:47 ` Christoph Hellwig
@ 2023-10-19 13:09   ` Greg Ungerer
  -1 siblings, 0 replies; 78+ messages in thread
From: Greg Ungerer @ 2023-10-19 13:09 UTC (permalink / raw)
  To: Christoph Hellwig, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On 16/10/23 15:47, Christoph Hellwig wrote:
> Hi all,
> 
> this is the next attempt to not return memory that is not DMA coherent
> on coldfire/m68knommu.  The last one needed more fixups in the fec
> driver, which this versions includes.  On top of that I've also added
> a few more cleanups to the core DMA allocation code.
> 
> Jim: any work to support the set_uncached and remap method for arm32
> should probably be based on this, and patch 3 should make that
> selection a little easier.
> 
> Changes since v1:
>   - sort out the dependency mess in RISCV
>   - don't even built non-coherent DMA support for coldfire cores without
>     data caches
>   - apply the fec workarounds to all coldfire platforms with data caches
>   - add a trivial cleanup for m68k dma.c

This looks good to me for the ColdFire changes. I tested it on a 5208
(version 2 core) with all combinations of cache (instruction only,
data only and both) and it worked good in all cases - with the one
configuration fix to patch 9 I sent earlier. So for ColdFire:

Tested-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Greg Ungerer <gerg@linux-m68k.org>

I don't have a 532x ColdFire board, so I can't directly test the case
of a version 3 core with the FEC hardware block.

Regards
Greg


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: fix the non-coherent coldfire dma_alloc_coherent v2
@ 2023-10-19 13:09   ` Greg Ungerer
  0 siblings, 0 replies; 78+ messages in thread
From: Greg Ungerer @ 2023-10-19 13:09 UTC (permalink / raw)
  To: Christoph Hellwig, iommu
  Cc: Paul Walmsley, Palmer Dabbelt, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Robin Murphy, Marek Szyprowski, Geert Uytterhoeven,
	Wei Fang, Shenwei Wang, Clark Wang, NXP Linux Team, linux-m68k,
	netdev, linux-riscv, linux-renesas-soc, Jim Quinlan

Hi Christoph,

On 16/10/23 15:47, Christoph Hellwig wrote:
> Hi all,
> 
> this is the next attempt to not return memory that is not DMA coherent
> on coldfire/m68knommu.  The last one needed more fixups in the fec
> driver, which this versions includes.  On top of that I've also added
> a few more cleanups to the core DMA allocation code.
> 
> Jim: any work to support the set_uncached and remap method for arm32
> should probably be based on this, and patch 3 should make that
> selection a little easier.
> 
> Changes since v1:
>   - sort out the dependency mess in RISCV
>   - don't even built non-coherent DMA support for coldfire cores without
>     data caches
>   - apply the fec workarounds to all coldfire platforms with data caches
>   - add a trivial cleanup for m68k dma.c

This looks good to me for the ColdFire changes. I tested it on a 5208
(version 2 core) with all combinations of cache (instruction only,
data only and both) and it worked good in all cases - with the one
configuration fix to patch 9 I sent earlier. So for ColdFire:

Tested-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Greg Ungerer <gerg@linux-m68k.org>

I don't have a 532x ColdFire board, so I can't directly test the case
of a version 3 core with the FEC hardware block.

Regards
Greg


^ permalink raw reply	[flat|nested] 78+ messages in thread

end of thread, other threads:[~2023-10-19 13:10 UTC | newest]

Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-16  5:47 fix the non-coherent coldfire dma_alloc_coherent v2 Christoph Hellwig
2023-10-16  5:47 ` Christoph Hellwig
2023-10-16  5:47 ` [PATCH 01/12] riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 12:49   ` Conor Dooley
2023-10-16 12:49     ` Conor Dooley
2023-10-16 13:17     ` Christoph Hellwig
2023-10-16 13:17       ` Christoph Hellwig
2023-10-16 17:16       ` Conor Dooley
2023-10-16 17:16         ` Conor Dooley
2023-10-16  5:47 ` [PATCH 02/12] riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 11:18   ` Robin Murphy
2023-10-16 11:18     ` Robin Murphy
2023-10-16 12:55   ` Conor Dooley
2023-10-16 12:55     ` Conor Dooley
2023-10-16 15:39   ` Lad, Prabhakar
2023-10-16 15:39     ` Lad, Prabhakar
2023-10-16  5:47 ` [PATCH 03/12] soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 12:53   ` Conor Dooley
2023-10-16 12:53     ` Conor Dooley
2023-10-16 15:40   ` Lad, Prabhakar
2023-10-16 15:40     ` Lad, Prabhakar
2023-10-17  7:59   ` Geert Uytterhoeven
2023-10-17  7:59     ` Geert Uytterhoeven
2023-10-16  5:47 ` [PATCH 04/12] soc: renesas: select RISCV_DMA_NONCOHERENT from ARCH_R9A07G043 Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 12:52   ` Conor Dooley
2023-10-16 12:52     ` Conor Dooley
2023-10-16 13:17     ` Christoph Hellwig
2023-10-16 13:17       ` Christoph Hellwig
2023-10-17 10:44       ` Geert Uytterhoeven
2023-10-17 10:44         ` Geert Uytterhoeven
2023-10-17 12:46         ` Christoph Hellwig
2023-10-17 12:46           ` Christoph Hellwig
2023-10-17 13:12           ` Geert Uytterhoeven
2023-10-17 13:12             ` Geert Uytterhoeven
2023-10-16 15:42   ` Lad, Prabhakar
2023-10-16 15:42     ` Lad, Prabhakar
2023-10-17  8:20   ` Geert Uytterhoeven
2023-10-17  8:20     ` Geert Uytterhoeven
2023-10-16  5:47 ` [PATCH 05/12] dma-direct: add depdenencies to CONFIG_DMA_GLOBAL_POOL Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 11:18   ` Robin Murphy
2023-10-16 11:18     ` Robin Murphy
2023-10-16 15:44   ` Lad, Prabhakar
2023-10-16 15:44     ` Lad, Prabhakar
2023-10-16  5:47 ` [PATCH 06/12] dma-direct: add a CONFIG_ARCH_DMA_ALLOC symbol Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 11:33   ` Robin Murphy
2023-10-16 11:33     ` Robin Murphy
2023-10-16  5:47 ` [PATCH 07/12] dma-direct: simplify the use atomic pool logic in dma_direct_alloc Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 11:58   ` Robin Murphy
2023-10-16 11:58     ` Robin Murphy
2023-10-16  5:47 ` [PATCH 08/12] dma-direct: warn when coherent allocations aren't supported Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16 11:59   ` Robin Murphy
2023-10-16 11:59     ` Robin Murphy
2023-10-16  5:47 ` [PATCH 09/12] m68k: use the coherent DMA code for coldfire without data cache Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-17  8:40   ` Geert Uytterhoeven
2023-10-17  8:40     ` Geert Uytterhoeven
2023-10-19 12:50   ` Greg Ungerer
2023-10-19 12:50     ` Greg Ungerer
2023-10-16  5:47 ` [PATCH 10/12] net: fec: use dma_alloc_noncoherent for data cache enabled coldfire Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-17  8:43   ` Geert Uytterhoeven
2023-10-17  8:43     ` Geert Uytterhoeven
2023-10-16  5:47 ` [PATCH 11/12] m68k: don't provide arch_dma_alloc for nommu/coldfire Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-16  5:47 ` [PATCH 12/12] m68k: remove unused includes from dma.c Christoph Hellwig
2023-10-16  5:47   ` Christoph Hellwig
2023-10-17  8:48   ` Geert Uytterhoeven
2023-10-17  8:48     ` Geert Uytterhoeven
2023-10-19 13:09 ` fix the non-coherent coldfire dma_alloc_coherent v2 Greg Ungerer
2023-10-19 13:09   ` Greg Ungerer

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.