* [PATCH 0/2] m68k: Add basic support for DMA global coherent pool
@ 2025-01-21 10:54 Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 1/2] m68k: Enable DMA support for Coldfire M5441x Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 2/2] arch: m68k: Add DMA mapping operations " Jean-Michel Hautbois
0 siblings, 2 replies; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-21 10:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Ungerer
Cc: linux-m68k, linux-kernel, Jean-Michel Hautbois
The coldfire M5441x family can't use coherent allocations, because the
cache does not support snooping (cache coherency is not supported while
external or DMA masters use the bus).
In order to make it possible to use coherent memory, the only way is to
disable the cache for specific adresses. This patch series introduces
the global coherent pool allocation along with a different cache
configuration. This is tested on M54418 only.
The CONFIG_DMABASE is fixed to 0x4f000000 in my configuration file.
When booting with memblock=debug, we can see:
memblock_reserve: [0x4f000000-0x4fffffff] cf_bootmem_alloc+0x9a/0x11c
Which corresponds to the memblock_reserve call in cf_bootmem_alloc().
Later, I have a SPI NOR, which is detected, and the dma_alloc_coherent
is successful:
[ 3.940000] fsl-dspi fsl-dspi.0: registered host spi0
[ 3.940000] spi spi0.0: DSPI controller timing params: CS-to-SCK delay 100 ns, SCK-to-CS delay 100 ns
[ 3.940000] spi spi0.0: setup mode 0, 8 bits/w, 31250000 Hz max --> 0
[ 3.970000] Creating 1 MTD partitions on "Micron mt25ql01G SPI Flash chip":
[ 3.970000] 0x000000000000-0x000008000000 : "w25q01"
[ 4.010000] fsl-dspi fsl-dspi.0: registered child spi0.0
[ 4.020000] DSPI: Coldfire DSPI Slave driver
The FEC driver is not modified and still uses the hack cache flush,
because I have an issue when DMA is used intensively:
fec enet-fec.0 eth0: rcv is not +last
I could not figure out why it appears, so some help on this would be
great :-).
I also could not modify the ACRs successfully, and I am not sure if it is
needed or not.
Thanks !
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Jean-Michel Hautbois (2):
m68k: Enable DMA support for Coldfire M5441x
arch: m68k: Add DMA mapping operations for Coldfire M5441x
arch/m68k/Kconfig.cpu | 2 +
arch/m68k/Kconfig.machine | 15 +++++
arch/m68k/coldfire/Makefile | 2 +
arch/m68k/coldfire/dma_ops.c | 131 +++++++++++++++++++++++++++++++++++++++++++
arch/m68k/include/asm/dma.h | 1 -
arch/m68k/kernel/dma.c | 10 ++++
arch/m68k/mm/mcfmmu.c | 5 ++
7 files changed, 165 insertions(+), 1 deletion(-)
---
base-commit: ffd294d346d185b70e28b1a28abe367bbfe53c04
change-id: 20250117-coldfire-global-pool-2a77d13647b6
Best regards,
--
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 1/2] m68k: Enable DMA support for Coldfire M5441x
2025-01-21 10:54 [PATCH 0/2] m68k: Add basic support for DMA global coherent pool Jean-Michel Hautbois
@ 2025-01-21 10:54 ` Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 2/2] arch: m68k: Add DMA mapping operations " Jean-Michel Hautbois
1 sibling, 0 replies; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-21 10:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Ungerer
Cc: linux-m68k, linux-kernel, Jean-Michel Hautbois
Add DMA support for the Coldfire M5441x platform with a global DMA pool
and coherent DMA operations.
Reserve a configurable DRAM pool (default 16MB with CONFIG_DMASIZE) and
initialize it with the dedicated helper.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
arch/m68k/Kconfig.cpu | 2 ++
arch/m68k/Kconfig.machine | 8 ++++++++
arch/m68k/coldfire/Makefile | 2 ++
arch/m68k/include/asm/dma.h | 1 +
arch/m68k/kernel/dma.c | 10 ++++++++++
arch/m68k/mm/mcfmmu.c | 5 +++++
6 files changed, 28 insertions(+)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index c9a7e602d8a4da8e5094762e90c7b1a1ab1acfdf..66e5f62a0eb280f6029e7501f4fa152f422b76b4 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -303,6 +303,8 @@ config M5441x
select COLDFIRE_PIT_TIMER
select MMU_COLDFIRE if MMU
select HAVE_CACHE_CB
+ select DMA_GLOBAL_POOL
+ select ARCH_HAS_DMA_OPS
help
Freescale Coldfire 54410/54415/54416/54417/54418 processor support.
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index de39f23b180ee21d3d3a028ad46f815f3690b1ad..1467d1ff349bb26714a3c99f593a2a71c9ad273d 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -405,6 +405,14 @@ config KERNELBASE
a system with the RAM based at address 0, and leaving enough room
for the theoretical maximum number of 256 vectors.
+config DMASIZE
+ hex "Size of DRAM (in bytes) reserved pool"
+ default "0x1000000"
+ depends on DMA_GLOBAL_POOL
+ help
+ Define the DMA pool size, allocated at init time, which can then
+ be used by DMA engine. Defaults to 16MB.
+
comment "ROM configuration"
config ROM
diff --git a/arch/m68k/coldfire/Makefile b/arch/m68k/coldfire/Makefile
index c56bc0dc7f2e338c8275cfd15656f80e78825254..b30c55ec722401822651cb329a9910cfc2d1d788 100644
--- a/arch/m68k/coldfire/Makefile
+++ b/arch/m68k/coldfire/Makefile
@@ -31,6 +31,8 @@ obj-$(CONFIG_M5407) += m5407.o intc.o reset.o
obj-$(CONFIG_M54xx) += m54xx.o intc-2.o
obj-$(CONFIG_M5441x) += m5441x.o intc-simr.o reset.o
+obj-$(CONFIG_ARCH_HAS_DMA_OPS) += dma_ops.o
+
obj-$(CONFIG_COLDFIRE_PIT_TIMER) += pit.o
obj-$(CONFIG_COLDFIRE_TIMERS) += timers.o
obj-$(CONFIG_COLDFIRE_SLTIMERS) += sltimers.o
diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index 1c8d9c5bc2fadeb425965974bdfb497577ebcc3b..53f9c1570ce62ddaa521d85d9ef64523e8ad0919 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -6,4 +6,5 @@
bootmem allocator (but this should do it for this) */
#define MAX_DMA_ADDRESS PAGE_OFFSET
+extern size_t dma_coldfire_base;
#endif /* _M68K_DMA_H */
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 16063783aa80c6ef200567543f98f011a2ac4dd2..bc66b012de79be842b55f3d82726a00c929416b9 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -43,3 +43,13 @@ void arch_sync_dma_for_device(phys_addr_t handle, size_t size,
break;
}
}
+
+#ifdef CONFIG_DMA_GLOBAL_POOL
+static int __init coldfire_dma_init(void)
+{
+ return dma_init_global_coherent(PFN_PHYS(PFN_DOWN(coldfire_dma_base)),
+ CONFIG_DMASIZE);
+}
+
+core_initcall(coldfire_dma_init);
+#endif
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872e32ca9566ebfe247531c808f49d6..f6c560ea17a68ff6546b0683461b6b9ffb587db7 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -156,6 +156,8 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
return ret;
}
+size_t coldfire_dma_base = _ramend - CONFIG_DMASIZE;
+
void __init cf_bootmem_alloc(void)
{
unsigned long memstart;
@@ -179,6 +181,9 @@ void __init cf_bootmem_alloc(void)
/* Reserve kernel text/data/bss */
memblock_reserve(_rambase, memstart - _rambase);
+ /* Reserve DMA */
+ memblock_reserve(coldfire_dma_base, CONFIG_DMASIZE);
+
m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
--
2.39.5
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-21 10:54 [PATCH 0/2] m68k: Add basic support for DMA global coherent pool Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 1/2] m68k: Enable DMA support for Coldfire M5441x Jean-Michel Hautbois
@ 2025-01-21 10:54 ` Jean-Michel Hautbois
2025-01-28 6:10 ` Christoph Hellwig
1 sibling, 1 reply; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-21 10:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Ungerer
Cc: linux-m68k, linux-kernel, Jean-Michel Hautbois
Introduce `dma_ops` for the Coldfire M5441x platform, enabling both
coherent and streaming DMA operations. This addition should fill the gap
for DMA support integrates with the existing kernel DMA framework.
The key operations implemented include:
- Custom allocation using the global coherent DMA pool
- Mapping and unmapping functions for pages
- Scatter-gather support
- Resource mapping
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
arch/m68k/Kconfig.machine | 19 +++++--
arch/m68k/coldfire/dma_ops.c | 131 +++++++++++++++++++++++++++++++++++++++++++
arch/m68k/include/asm/dma.h | 2 -
arch/m68k/kernel/dma.c | 2 +-
arch/m68k/mm/mcfmmu.c | 6 +-
5 files changed, 148 insertions(+), 12 deletions(-)
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 1467d1ff349bb26714a3c99f593a2a71c9ad273d..9cecc5025401976897f815505e0bc74cba28eb0d 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -406,12 +406,19 @@ config KERNELBASE
for the theoretical maximum number of 256 vectors.
config DMASIZE
- hex "Size of DRAM (in bytes) reserved pool"
- default "0x1000000"
- depends on DMA_GLOBAL_POOL
- help
- Define the DMA pool size, allocated at init time, which can then
- be used by DMA engine. Defaults to 16MB.
+ hex "Size of DRAM (in bytes) reserved pool"
+ default "0x1000000"
+ depends on DMA_GLOBAL_POOL
+ help
+ Define the DMA pool size, allocated at init time, which can then
+ be used by DMA engine. Defaults to 16MB.
+
+config DMABASE
+ hex "Address of the base of RAM"
+ default RAMBASE
+ depends on DMA_GLOBAL_POOL
+ help
+ Define the DMA base address for the global pool.
comment "ROM configuration"
diff --git a/arch/m68k/coldfire/dma_ops.c b/arch/m68k/coldfire/dma_ops.c
new file mode 100644
index 0000000000000000000000000000000000000000..e9967adc8821fb06c828e010ef51ef4e9702925b
--- /dev/null
+++ b/arch/m68k/coldfire/dma_ops.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dma_timer.c -- Freescale ColdFire DMA Ops helpers.
+ *
+ * Copyright (C) 2024 Jean-Michel Hautbois, Yoseli
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/dma-direct.h>
+#include <linux/dma-map-ops.h>
+#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/scatterlist.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/pci.h>
+#include <asm/pgalloc.h>
+
+static void *coldfire_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+{
+ void *vaddr;
+
+ vaddr = dma_alloc_from_global_coherent(dev, size, dma_handle);
+ if (!vaddr) {
+ dev_err(dev, "Failed to allocate %zu bytes\n", size);
+ return NULL;
+ }
+
+ dev_dbg(dev, "Allocated %zu bytes at %p (dma %pad)\n", size, vaddr, dma_handle);
+
+ return vaddr;
+}
+
+static void coldfire_free_coherent(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_handle, unsigned long attrs)
+{
+ unsigned int page_order = get_order(size);
+
+ if (!dma_release_from_global_coherent(page_order, vaddr))
+ WARN_ON_ONCE(1);
+}
+
+static dma_addr_t coldfire_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ phys_addr_t phys = page_to_phys(page) + offset;
+ dma_addr_t dma_addr = phys_to_dma(dev, phys);
+
+ if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+ arch_sync_dma_for_device(phys, size, dir);
+ return dma_addr;
+}
+
+static void coldfire_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ phys_addr_t phys = dma_to_phys(dev, dma_handle);
+
+ if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+ arch_sync_dma_for_cpu(phys, size, dir);
+}
+
+static int coldfire_map_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *s;
+ dma_addr_t dma_handle;
+ int i;
+
+ if (!sg) {
+ dev_err(dev, "Invalid scatterlist, cannot map memory\n");
+ return 0;
+ }
+
+ for_each_sg(sg, s, nents, i) {
+ dma_handle = page_to_phys(sg_page(s)) + sg->offset;
+ dev_dbg(dev, "Mapped scatterlist %p (offset %u) to DMA address %pad\n",
+ sg_page(s), sg->offset, &dma_handle);
+ }
+
+ return nents;
+}
+
+static void coldfire_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+}
+
+static dma_addr_t coldfire_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ dma_addr_t dma_handle;
+
+ if (!phys) {
+ dev_err(dev, "Invalid physical address, cannot map memory\n");
+ return 0;
+ }
+
+ dma_handle = phys;
+ dev_dbg(dev, "Mapped physical address %pa (size %zu) to DMA address %pad\n",
+ &phys, size, &dma_handle);
+ return dma_handle;
+}
+
+static void coldfire_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+}
+
+const struct dma_map_ops coldfire_dma_ops = {
+ .alloc = coldfire_alloc_coherent,
+ .free = coldfire_free_coherent,
+ .map_page = coldfire_map_page,
+ .unmap_page = coldfire_unmap_page,
+ .map_sg = coldfire_map_sg,
+ .unmap_sg = coldfire_unmap_sg,
+ .map_resource = coldfire_map_resource,
+ .unmap_resource = coldfire_unmap_resource,
+ .alloc_pages_op = dma_common_alloc_pages,
+ .free_pages = dma_common_free_pages,
+};
+EXPORT_SYMBOL(coldfire_dma_ops);
diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index 53f9c1570ce62ddaa521d85d9ef64523e8ad0919..fc029b710c30bf23f8bf2657ea74a1c146b3f8b1 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -5,6 +5,4 @@
/* it's useless on the m68k, but unfortunately needed by the new
bootmem allocator (but this should do it for this) */
#define MAX_DMA_ADDRESS PAGE_OFFSET
-
-extern size_t dma_coldfire_base;
#endif /* _M68K_DMA_H */
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index bc66b012de79be842b55f3d82726a00c929416b9..6d41fdc4991589c30f9cad783fc43f56e8f8b99b 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -47,7 +47,7 @@ void arch_sync_dma_for_device(phys_addr_t handle, size_t size,
#ifdef CONFIG_DMA_GLOBAL_POOL
static int __init coldfire_dma_init(void)
{
- return dma_init_global_coherent(PFN_PHYS(PFN_DOWN(coldfire_dma_base)),
+ return dma_init_global_coherent(PFN_PHYS(PFN_DOWN(CONFIG_DMABASE)),
CONFIG_DMASIZE);
}
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index f6c560ea17a68ff6546b0683461b6b9ffb587db7..f8006a70e0f58828bedb18690f9eecfa924c8059 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -156,8 +156,6 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
return ret;
}
-size_t coldfire_dma_base = _ramend - CONFIG_DMASIZE;
-
void __init cf_bootmem_alloc(void)
{
unsigned long memstart;
@@ -181,8 +179,10 @@ void __init cf_bootmem_alloc(void)
/* Reserve kernel text/data/bss */
memblock_reserve(_rambase, memstart - _rambase);
+#ifdef CONFIG_DMA_GLOBAL_POOL
/* Reserve DMA */
- memblock_reserve(coldfire_dma_base, CONFIG_DMASIZE);
+ memblock_reserve(CONFIG_DMABASE, CONFIG_DMASIZE);
+#endif
m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
--
2.39.5
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-21 10:54 ` [PATCH 2/2] arch: m68k: Add DMA mapping operations " Jean-Michel Hautbois
@ 2025-01-28 6:10 ` Christoph Hellwig
2025-01-28 6:33 ` Jean-Michel Hautbois
0 siblings, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2025-01-28 6:10 UTC (permalink / raw)
To: Jean-Michel Hautbois
Cc: Geert Uytterhoeven, Greg Ungerer, linux-m68k, linux-kernel
On Tue, Jan 21, 2025 at 11:54:14AM +0100, Jean-Michel Hautbois wrote:
> Introduce `dma_ops` for the Coldfire M5441x platform, enabling both
> coherent and streaming DMA operations. This addition should fill the gap
> for DMA support integrates with the existing kernel DMA framework.
Arch dma code should not implement DMA OPS, but use the generic
dma-direct code with the right helpes for handling coherency. This
variant looks like it should be using the DMA_COHERENT_POOL allocator
for dma coherent memory.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-28 6:10 ` Christoph Hellwig
@ 2025-01-28 6:33 ` Jean-Michel Hautbois
2025-01-28 6:40 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-28 6:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, Greg Ungerer, linux-m68k, linux-kernel
Hi Christoph,
On 28/01/2025 07:10, Christoph Hellwig wrote:
> On Tue, Jan 21, 2025 at 11:54:14AM +0100, Jean-Michel Hautbois wrote:
>> Introduce `dma_ops` for the Coldfire M5441x platform, enabling both
>> coherent and streaming DMA operations. This addition should fill the gap
>> for DMA support integrates with the existing kernel DMA framework.
>
> Arch dma code should not implement DMA OPS, but use the generic
> dma-direct code with the right helpes for handling coherency. This
> variant looks like it should be using the DMA_COHERENT_POOL allocator
> for dma coherent memory.
Thanks for your answer.
I am not sure to understand it though :-) because I can see a few
dma_map_ops implementations in arch code. I tried to let dma_direct do
the work, I can't remember exactly what happened but it was not great :-).
I can give it a second try.
Thanks,
JM
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-28 6:33 ` Jean-Michel Hautbois
@ 2025-01-28 6:40 ` Christoph Hellwig
2025-01-28 6:43 ` Jean-Michel Hautbois
0 siblings, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2025-01-28 6:40 UTC (permalink / raw)
To: Jean-Michel Hautbois
Cc: Christoph Hellwig, Geert Uytterhoeven, Greg Ungerer, linux-m68k,
linux-kernel
On Tue, Jan 28, 2025 at 07:33:37AM +0100, Jean-Michel Hautbois wrote:
> > Arch dma code should not implement DMA OPS, but use the generic
> > dma-direct code with the right helpes for handling coherency. This
> > variant looks like it should be using the DMA_COHERENT_POOL allocator
> > for dma coherent memory.
>
> Thanks for your answer.
> I am not sure to understand it though :-) because I can see a few
> dma_map_ops implementations in arch code.
The last one left for the direct mapping are arm32 and parisc, and
they should go away eventually.
> I tried to let dma_direct do the
> work, I can't remember exactly what happened but it was not great :-).
> I can give it a second try.
It really should not be hard. The dynamic mappings already work fine
as m68k is using the generic code. So the only thing you want is
to dip into the glonal pool for coherent allocations. For that you
need to select the DMA_GLOBAL_POOL config option and fill the pool
with dma_init_global_coherent().
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-28 6:40 ` Christoph Hellwig
@ 2025-01-28 6:43 ` Jean-Michel Hautbois
2025-01-28 6:47 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-28 6:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, Greg Ungerer, linux-m68k, linux-kernel
On 28/01/2025 07:40, Christoph Hellwig wrote:
> On Tue, Jan 28, 2025 at 07:33:37AM +0100, Jean-Michel Hautbois wrote:
>>> Arch dma code should not implement DMA OPS, but use the generic
>>> dma-direct code with the right helpes for handling coherency. This
>>> variant looks like it should be using the DMA_COHERENT_POOL allocator
>>> for dma coherent memory.
>>
>> Thanks for your answer.
>> I am not sure to understand it though :-) because I can see a few
>> dma_map_ops implementations in arch code.
>
> The last one left for the direct mapping are arm32 and parisc, and
> they should go away eventually.
>
>> I tried to let dma_direct do the
>> work, I can't remember exactly what happened but it was not great :-).
>> I can give it a second try.
>
> It really should not be hard. The dynamic mappings already work fine
> as m68k is using the generic code. So the only thing you want is
> to dip into the glonal pool for coherent allocations. For that you
> need to select the DMA_GLOBAL_POOL config option and fill the pool
> with dma_init_global_coherent().
>
Isn't it done in patch 1/2 ? Or did I miss something ?
JM
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-28 6:43 ` Jean-Michel Hautbois
@ 2025-01-28 6:47 ` Christoph Hellwig
2025-01-29 7:32 ` Jean-Michel Hautbois
0 siblings, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2025-01-28 6:47 UTC (permalink / raw)
To: Jean-Michel Hautbois
Cc: Christoph Hellwig, Geert Uytterhoeven, Greg Ungerer, linux-m68k,
linux-kernel
On Tue, Jan 28, 2025 at 07:43:23AM +0100, Jean-Michel Hautbois wrote:
> > It really should not be hard. The dynamic mappings already work fine
> > as m68k is using the generic code. So the only thing you want is
> > to dip into the glonal pool for coherent allocations. For that you
> > need to select the DMA_GLOBAL_POOL config option and fill the pool
> > with dma_init_global_coherent().
> >
>
> Isn't it done in patch 1/2 ? Or did I miss something ?
The point is that this is all you need. No need for new dma ops.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arch: m68k: Add DMA mapping operations for Coldfire M5441x
2025-01-28 6:47 ` Christoph Hellwig
@ 2025-01-29 7:32 ` Jean-Michel Hautbois
0 siblings, 0 replies; 9+ messages in thread
From: Jean-Michel Hautbois @ 2025-01-29 7:32 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, Greg Ungerer, linux-m68k, linux-kernel
Hi Christoph,
On 28/01/2025 07:47, Christoph Hellwig wrote:
> On Tue, Jan 28, 2025 at 07:43:23AM +0100, Jean-Michel Hautbois wrote:
>>> It really should not be hard. The dynamic mappings already work fine
>>> as m68k is using the generic code. So the only thing you want is
>>> to dip into the glonal pool for coherent allocations. For that you
>>> need to select the DMA_GLOBAL_POOL config option and fill the pool
>>> with dma_init_global_coherent().
>>>
>>
>> Isn't it done in patch 1/2 ? Or did I miss something ?
>
> The point is that this is all you need. No need for new dma ops.
>
Indeed, I tested it and it works fine.
I have removed the test in fec_main to be certain, but I think it would
be better to change the COLDFIRE_COHERENT_DMA conditional ?
What sounds like the most efficient way ?
I can' do:
- #if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
+ #if defined(CONFIG_COLDFIRE) && !defined(CONFIG_COLDFIRE_COHERENT_DMA)
&& !defined(CONFIG_DMA_GLOBAL_POOL)
I suppose it would be better to modify it in the Kconfig, but I can't
find a nice way to do it without having a circular dependency:
arch/m68k/Kconfig.cpu
@@ -555,6 +555,7 @@ config COLDFIRE_COHERENT_DMA
default y
depends on COLDFIRE
depends on !HAVE_CACHE_CB && !CACHE_D && !CACHE_BOTH
+ depends on DMA_GLOBAL_POOL
=>
error: recursive dependency detected!
symbol DMA_DIRECT_REMAP is selected by M68K_NONCOHERENT_DMA
symbol M68K_NONCOHERENT_DMA depends on COLDFIRE_COHERENT_DMA
symbol COLDFIRE_COHERENT_DMA depends on DMA_GLOBAL_POOL
symbol DMA_GLOBAL_POOL depends on DMA_DIRECT_REMAP
I will send a v2 with the global pool.
Thanks !
JM
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-01-29 7:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-21 10:54 [PATCH 0/2] m68k: Add basic support for DMA global coherent pool Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 1/2] m68k: Enable DMA support for Coldfire M5441x Jean-Michel Hautbois
2025-01-21 10:54 ` [PATCH 2/2] arch: m68k: Add DMA mapping operations " Jean-Michel Hautbois
2025-01-28 6:10 ` Christoph Hellwig
2025-01-28 6:33 ` Jean-Michel Hautbois
2025-01-28 6:40 ` Christoph Hellwig
2025-01-28 6:43 ` Jean-Michel Hautbois
2025-01-28 6:47 ` Christoph Hellwig
2025-01-29 7:32 ` Jean-Michel Hautbois
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox