On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote:
From: Andrew Davis afd@ti.com
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap, this allows for allocations of DMA-BUFs that can be consumed by various DMA-BUF supporting devices.
Signed-off-by: Andrew Davis afd@ti.com Tested-by: Pascal Fontain pascal.fontain@bachmann.info
When sending on a patch from someone else, you too must sign off on it as per our documenation. Please read it and understand what you are agreeing to when you do that for a new version please.
drivers/misc/Kconfig | 7 + drivers/misc/Makefile | 1 + drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++ drivers/misc/sram.c | 6 + drivers/misc/sram.h | 16 +++ 5 files changed, 276 insertions(+) create mode 100644 drivers/misc/sram-dma-heap.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 9e4ad4d61f06..e6674e913168 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -448,6 +448,13 @@ config SRAM config SRAM_EXEC bool +config SRAM_DMA_HEAP
- bool "Export on-chip SRAM pools using DMA-Heaps"
- depends on DMABUF_HEAPS && SRAM
- help
This driver allows the export of on-chip SRAM marked as both pooland exportable to userspace using the DMA-Heaps interface.
What will use this in userspace?
thanks,
greg k-h
Am Di., 9. Apr. 2024 um 14:14 Uhr schrieb Greg Kroah-Hartman gregkh@linuxfoundation.org:
On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote:
From: Andrew Davis afd@ti.com
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap, this allows for allocations of DMA-BUFs that can be consumed by various DMA-BUF supporting devices.
Signed-off-by: Andrew Davis afd@ti.com Tested-by: Pascal Fontain pascal.fontain@bachmann.info
When sending on a patch from someone else, you too must sign off on it as per our documenation. Please read it and understand what you are agreeing to when you do that for a new version please.
drivers/misc/Kconfig | 7 + drivers/misc/Makefile | 1 + drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++ drivers/misc/sram.c | 6 + drivers/misc/sram.h | 16 +++ 5 files changed, 276 insertions(+) create mode 100644 drivers/misc/sram-dma-heap.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 9e4ad4d61f06..e6674e913168 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -448,6 +448,13 @@ config SRAM config SRAM_EXEC bool
+config SRAM_DMA_HEAP
bool "Export on-chip SRAM pools using DMA-Heaps"depends on DMABUF_HEAPS && SRAMhelpThis driver allows the export of on-chip SRAM marked as both pooland exportable to userspace using the DMA-Heaps interface.What will use this in userspace?
I could imagine a way it might be used.
Imagine a SoC like TI's AM64x series, where some cores (A53) run Linux and others (R5F) are managed by remoteproc to execute a RTOS. When it comes to efficiently exchanging large data sets, the conventional method involves using rpmsg, which has limitations due to message size and could potentially slow down data transfer. However, an alternative approach could be to allocate a sizable chunk of SRAM memory in userspace. By utilizing memcpy() to copy data into this memory, followed by a single rpmsg signal to notify the RTOS that the data is ready, we can leverage the faster access speed of SRAM compared to DDR from the remoteproc.
On Fri, Apr 19, 2024 at 06:57:47PM +0200, Christian Gmeiner wrote:
Am Di., 9. Apr. 2024 um 14:14 Uhr schrieb Greg Kroah-Hartman gregkh@linuxfoundation.org:
On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote:
From: Andrew Davis afd@ti.com
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap, this allows for allocations of DMA-BUFs that can be consumed by various DMA-BUF supporting devices.
Signed-off-by: Andrew Davis afd@ti.com Tested-by: Pascal Fontain pascal.fontain@bachmann.info
When sending on a patch from someone else, you too must sign off on it as per our documenation. Please read it and understand what you are agreeing to when you do that for a new version please.
drivers/misc/Kconfig | 7 + drivers/misc/Makefile | 1 + drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++ drivers/misc/sram.c | 6 + drivers/misc/sram.h | 16 +++ 5 files changed, 276 insertions(+) create mode 100644 drivers/misc/sram-dma-heap.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 9e4ad4d61f06..e6674e913168 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -448,6 +448,13 @@ config SRAM config SRAM_EXEC bool
+config SRAM_DMA_HEAP
bool "Export on-chip SRAM pools using DMA-Heaps"depends on DMABUF_HEAPS && SRAMhelpThis driver allows the export of on-chip SRAM marked as both pooland exportable to userspace using the DMA-Heaps interface.What will use this in userspace?
I could imagine a way it might be used.
This implies it is not needed because no one actually has actually used it for anything, so why make this change?
Imagine a SoC like TI's AM64x series, where some cores (A53) run Linux and others (R5F) are managed by remoteproc to execute a RTOS. When it comes to efficiently exchanging large data sets, the conventional method involves using rpmsg, which has limitations due to message size and could potentially slow down data transfer. However, an alternative approach could be to allocate a sizable chunk of SRAM memory in userspace. By utilizing memcpy() to copy data into this memory, followed by a single rpmsg signal to notify the RTOS that the data is ready, we can leverage the faster access speed of SRAM compared to DDR from the remoteproc.
Why is virtio not used instead?
thanks,
greg k-h
linaro-mm-sig@lists.linaro.org
-
Christian Gmeiner -
Greg Kroah-Hartman