* [PATCH v3 0/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
@ 2024-04-09 12:06 Pascal FONTAIN
2024-04-09 12:06 ` [PATCH v3 1/2] misc: sram: Move probe of sram subsystem Pascal FONTAIN
2024-04-09 12:06 ` [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
0 siblings, 2 replies; 8+ messages in thread
From: Pascal FONTAIN @ 2024-04-09 12:06 UTC (permalink / raw
To: linux-kernel; +Cc: afd, Pascal Fontain
From: Pascal Fontain <pascal.fontain@bachmann.info>
Changes from v2:
- Move sram initialization to device phase
- Solve compile problems found by kernel test robot
Andrew Davis (1):
misc: sram: Add DMA-BUF Heap exporting of SRAM areas
Pascal Fontain (1):
misc: sram: Move probe of sram subsystem
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++
drivers/misc/sram.c | 8 +-
drivers/misc/sram.h | 16 +++
5 files changed, 277 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/sram-dma-heap.c
--
2.39.2
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3 1/2] misc: sram: Move probe of sram subsystem
2024-04-09 12:06 [PATCH v3 0/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
@ 2024-04-09 12:06 ` Pascal FONTAIN
2024-04-09 12:10 ` Arnd Bergmann
2024-04-09 12:06 ` [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
1 sibling, 1 reply; 8+ messages in thread
From: Pascal FONTAIN @ 2024-04-09 12:06 UTC (permalink / raw
To: linux-kernel, Arnd Bergmann, Greg Kroah-Hartman; +Cc: afd, Pascal Fontain
From: Pascal Fontain <pascal.fontain@bachmann.info>
The sram subsystem might use the dma-buf subsystem which only gets
initialized in subsys_initcall phase. Because of this we move the sram
initcall into the device phase.
Signed-off-by: Pascal Fontain <pascal.fontain@bachmann.info>
---
drivers/misc/sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index e248c0a8882f..632f90d9bcea 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -461,4 +461,4 @@ static int __init sram_init(void)
return platform_driver_register(&sram_driver);
}
-postcore_initcall(sram_init);
+device_initcall(sram_init);
--
2.39.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
2024-04-09 12:06 [PATCH v3 0/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
2024-04-09 12:06 ` [PATCH v3 1/2] misc: sram: Move probe of sram subsystem Pascal FONTAIN
@ 2024-04-09 12:06 ` Pascal FONTAIN
2024-04-09 12:14 ` Greg Kroah-Hartman
2024-04-09 14:38 ` Andrew Davis
1 sibling, 2 replies; 8+ messages in thread
From: Pascal FONTAIN @ 2024-04-09 12:06 UTC (permalink / raw
To: linux-kernel, Derek Kiernan, Dragan Cvetic, Arnd Bergmann,
Greg Kroah-Hartman, Sumit Semwal, Christian König
Cc: afd, Pascal Fontain, linux-media, dri-devel, linaro-mm-sig
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>
---
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 pool
+ and exportable to userspace using the DMA-Heaps interface.
+
config DW_XDATA_PCIE
depends on PCI
tristate "Synopsys DesignWare xData PCIe driver"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index cdc6405584e3..63effdde5163 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
+obj-$(CONFIG_SRAM_DMA_HEAP) += sram-dma-heap.o
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c
new file mode 100644
index 000000000000..e5a0bafe8cb9
--- /dev/null
+++ b/drivers/misc/sram-dma-heap.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SRAM DMA-Heap userspace exporter
+ *
+ * Copyright (C) 2019-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Andrew Davis <afd@ti.com>
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/genalloc.h>
+#include <linux/io.h>
+#include <linux/mm.h>
+#include <linux/scatterlist.h>
+#include <linux/slab.h>
+#include <linux/dma-buf.h>
+#include <linux/dma-heap.h>
+
+#include "sram.h"
+
+struct sram_dma_heap {
+ struct dma_heap *heap;
+ struct gen_pool *pool;
+};
+
+struct sram_dma_heap_buffer {
+ struct gen_pool *pool;
+ struct list_head attachments;
+ struct mutex attachments_lock;
+ unsigned long len;
+ void *vaddr;
+ phys_addr_t paddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static int dma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = kmalloc(sizeof(*table), GFP_KERNEL);
+ if (!table) {
+ kfree(a);
+ return -ENOMEM;
+ }
+ if (sg_alloc_table(table, 1, GFP_KERNEL)) {
+ kfree(table);
+ kfree(a);
+ return -ENOMEM;
+ }
+ sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)), buffer->len, 0);
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(&a->list);
+
+ attachment->priv = a;
+
+ mutex_lock(&buffer->attachments_lock);
+ list_add(&a->list, &buffer->attachments);
+ mutex_unlock(&buffer->attachments_lock);
+
+ return 0;
+}
+
+static void dma_heap_detatch(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(&buffer->attachments_lock);
+ list_del(&a->list);
+ mutex_unlock(&buffer->attachments_lock);
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
+
+static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment *attachment,
+ enum dma_data_direction direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = a->table;
+
+ /*
+ * As this heap is backed by uncached SRAM memory we do not need to
+ * perform any sync operations on the buffer before allowing device
+ * domain access. For this reason we use SKIP_CPU_SYNC and also do
+ * not use or provide begin/end_cpu_access() dma-buf functions.
+ */
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC))
+ return ERR_PTR(-ENOMEM);
+
+ return table;
+}
+
+static void dma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+ struct sg_table *table,
+ enum dma_data_direction direction)
+{
+ dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC);
+}
+
+static void dma_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+
+ gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len);
+ kfree(buffer);
+}
+
+static int dma_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+ int ret;
+
+ /* SRAM mappings are not cached */
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
+ ret = vm_iomap_memory(vma, buffer->paddr, buffer->len);
+ if (ret)
+ pr_err("Could not map buffer to userspace\n");
+
+ return ret;
+}
+
+static int dma_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
+{
+ struct sram_dma_heap_buffer *buffer = dmabuf->priv;
+
+ iosys_map_set_vaddr(map, buffer->vaddr);
+
+ return 0;
+}
+
+static const struct dma_buf_ops sram_dma_heap_buf_ops = {
+ .attach = dma_heap_attach,
+ .detach = dma_heap_detatch,
+ .map_dma_buf = dma_heap_map_dma_buf,
+ .unmap_dma_buf = dma_heap_unmap_dma_buf,
+ .release = dma_heap_dma_buf_release,
+ .mmap = dma_heap_mmap,
+ .vmap = dma_heap_vmap,
+};
+
+static struct dma_buf *sram_dma_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct sram_dma_heap *sram_dma_heap = dma_heap_get_drvdata(heap);
+ struct sram_dma_heap_buffer *buffer;
+
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ struct dma_buf *dmabuf;
+ int ret;
+
+ buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+ buffer->pool = sram_dma_heap->pool;
+ INIT_LIST_HEAD(&buffer->attachments);
+ mutex_init(&buffer->attachments_lock);
+ buffer->len = len;
+
+ buffer->vaddr = (void *)gen_pool_alloc(buffer->pool, buffer->len);
+ if (!buffer->vaddr) {
+ ret = -ENOMEM;
+ goto free_buffer;
+ }
+
+ buffer->paddr = gen_pool_virt_to_phys(buffer->pool, (unsigned long)buffer->vaddr);
+ if (buffer->paddr == -1) {
+ ret = -ENOMEM;
+ goto free_pool;
+ }
+
+ /* create the dmabuf */
+ exp_info.exp_name = dma_heap_get_name(heap);
+ exp_info.ops = &sram_dma_heap_buf_ops;
+ exp_info.size = buffer->len;
+ exp_info.flags = fd_flags;
+ exp_info.priv = buffer;
+ dmabuf = dma_buf_export(&exp_info);
+ if (IS_ERR(dmabuf)) {
+ ret = PTR_ERR(dmabuf);
+ goto free_pool;
+ }
+
+ return dmabuf;
+
+free_pool:
+ gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len);
+free_buffer:
+ kfree(buffer);
+
+ return ERR_PTR(ret);
+}
+
+static struct dma_heap_ops sram_dma_heap_ops = {
+ .allocate = sram_dma_heap_allocate,
+};
+
+int sram_add_dma_heap(struct sram_dev *sram,
+ struct sram_reserve *block,
+ phys_addr_t start,
+ struct sram_partition *part)
+{
+ struct sram_dma_heap *sram_dma_heap;
+ struct dma_heap_export_info exp_info;
+
+ dev_info(sram->dev, "Exporting SRAM Heap '%s'\n", block->label);
+
+ sram_dma_heap = kzalloc(sizeof(*sram_dma_heap), GFP_KERNEL);
+ if (!sram_dma_heap)
+ return -ENOMEM;
+ sram_dma_heap->pool = part->pool;
+
+ exp_info.name = kasprintf(GFP_KERNEL, "sram_%s", block->label);
+ exp_info.ops = &sram_dma_heap_ops;
+ exp_info.priv = sram_dma_heap;
+ sram_dma_heap->heap = dma_heap_add(&exp_info);
+ if (IS_ERR(sram_dma_heap->heap)) {
+ int ret = PTR_ERR(sram_dma_heap->heap);
+
+ kfree(sram_dma_heap);
+ return ret;
+ }
+
+ return 0;
+}
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 632f90d9bcea..643c77598beb 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -120,6 +120,12 @@ static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block,
ret = sram_add_pool(sram, block, start, part);
if (ret)
return ret;
+
+ if (block->export) {
+ ret = sram_add_dma_heap(sram, block, start, part);
+ if (ret)
+ return ret;
+ }
}
if (block->export) {
ret = sram_add_export(sram, block, start, part);
diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h
index 397205b8bf6f..062bdd25fa06 100644
--- a/drivers/misc/sram.h
+++ b/drivers/misc/sram.h
@@ -60,4 +60,20 @@ static inline int sram_add_protect_exec(struct sram_partition *part)
return -ENODEV;
}
#endif /* CONFIG_SRAM_EXEC */
+
+#ifdef CONFIG_SRAM_DMA_HEAP
+int sram_add_dma_heap(struct sram_dev *sram,
+ struct sram_reserve *block,
+ phys_addr_t start,
+ struct sram_partition *part);
+#else
+static inline int sram_add_dma_heap(struct sram_dev *sram,
+ struct sram_reserve *block,
+ phys_addr_t start,
+ struct sram_partition *part)
+{
+ return 0;
+}
+#endif /* CONFIG_SRAM_DMA_HEAP */
+
#endif /* __SRAM_H */
--
2.39.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v3 1/2] misc: sram: Move probe of sram subsystem
2024-04-09 12:06 ` [PATCH v3 1/2] misc: sram: Move probe of sram subsystem Pascal FONTAIN
@ 2024-04-09 12:10 ` Arnd Bergmann
0 siblings, 0 replies; 8+ messages in thread
From: Arnd Bergmann @ 2024-04-09 12:10 UTC (permalink / raw
To: Pascal FONTAIN, linux-kernel, Greg Kroah-Hartman; +Cc: Andrew Davis
On Tue, Apr 9, 2024, at 14:06, Pascal FONTAIN wrote:
> From: Pascal Fontain <pascal.fontain@bachmann.info>
>
> The sram subsystem might use the dma-buf subsystem which only gets
> initialized in subsys_initcall phase. Because of this we move the sram
> initcall into the device phase.
>
> Signed-off-by: Pascal Fontain <pascal.fontain@bachmann.info>
This does not look safe unless you check all users of the sram
driver to ensure they are not needed early and they can handle
deferred probing.
Arnd
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
2024-04-09 12:06 ` [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
@ 2024-04-09 12:14 ` Greg Kroah-Hartman
2024-04-19 16:57 ` Christian Gmeiner
2024-04-09 14:38 ` Andrew Davis
1 sibling, 1 reply; 8+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-09 12:14 UTC (permalink / raw
To: Pascal FONTAIN
Cc: linux-kernel, Derek Kiernan, Dragan Cvetic, Arnd Bergmann,
Sumit Semwal, Christian König, afd, linux-media, dri-devel,
linaro-mm-sig
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 pool
> + and exportable to userspace using the DMA-Heaps interface.
What will use this in userspace?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
2024-04-09 12:06 ` [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
2024-04-09 12:14 ` Greg Kroah-Hartman
@ 2024-04-09 14:38 ` Andrew Davis
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Davis @ 2024-04-09 14:38 UTC (permalink / raw
To: Pascal FONTAIN, linux-kernel, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Greg Kroah-Hartman, Sumit Semwal,
Christian König, Robin Murphy
Cc: linux-media, dri-devel, linaro-mm-sig
On 4/9/24 7:06 AM, 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>
> ---
The last time I posted this I got this comment[0], for which I
didn't really have a good response and so haven't reposted this
since then.
Bacically this driver is backed by something other than "normal"
memory. So we really need to be careful here, the page pointer is
really just a cookie to keep track for the real mappings. We might
be able to use something similar to dma_get_sgtable() to hide that,
but under the hood it would still a bit unsafe[1].
Andrew
[0] https://patchwork.kernel.org/project/linux-media/patch/20230713191316.116019-1-afd@ti.com/#25475464
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/dma/mapping.c#n388
> 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 pool
> + and exportable to userspace using the DMA-Heaps interface.
> +
> config DW_XDATA_PCIE
> depends on PCI
> tristate "Synopsys DesignWare xData PCIe driver"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index cdc6405584e3..63effdde5163 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
> obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
> obj-$(CONFIG_SRAM) += sram.o
> obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
> +obj-$(CONFIG_SRAM_DMA_HEAP) += sram-dma-heap.o
> obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_CXL_BASE) += cxl/
> diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c
> new file mode 100644
> index 000000000000..e5a0bafe8cb9
> --- /dev/null
> +++ b/drivers/misc/sram-dma-heap.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * SRAM DMA-Heap userspace exporter
> + *
> + * Copyright (C) 2019-2022 Texas Instruments Incorporated - https://www.ti.com/
> + * Andrew Davis <afd@ti.com>
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/genalloc.h>
> +#include <linux/io.h>
> +#include <linux/mm.h>
> +#include <linux/scatterlist.h>
> +#include <linux/slab.h>
> +#include <linux/dma-buf.h>
> +#include <linux/dma-heap.h>
> +
> +#include "sram.h"
> +
> +struct sram_dma_heap {
> + struct dma_heap *heap;
> + struct gen_pool *pool;
> +};
> +
> +struct sram_dma_heap_buffer {
> + struct gen_pool *pool;
> + struct list_head attachments;
> + struct mutex attachments_lock;
> + unsigned long len;
> + void *vaddr;
> + phys_addr_t paddr;
> +};
> +
> +struct dma_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> +};
> +
> +static int dma_heap_attach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attachment)
> +{
> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
> + struct dma_heap_attachment *a;
> + struct sg_table *table;
> +
> + a = kzalloc(sizeof(*a), GFP_KERNEL);
> + if (!a)
> + return -ENOMEM;
> +
> + table = kmalloc(sizeof(*table), GFP_KERNEL);
> + if (!table) {
> + kfree(a);
> + return -ENOMEM;
> + }
> + if (sg_alloc_table(table, 1, GFP_KERNEL)) {
> + kfree(table);
> + kfree(a);
> + return -ENOMEM;
> + }
> + sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)), buffer->len, 0);
> +
> + a->table = table;
> + a->dev = attachment->dev;
> + INIT_LIST_HEAD(&a->list);
> +
> + attachment->priv = a;
> +
> + mutex_lock(&buffer->attachments_lock);
> + list_add(&a->list, &buffer->attachments);
> + mutex_unlock(&buffer->attachments_lock);
> +
> + return 0;
> +}
> +
> +static void dma_heap_detatch(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attachment)
> +{
> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
> + struct dma_heap_attachment *a = attachment->priv;
> +
> + mutex_lock(&buffer->attachments_lock);
> + list_del(&a->list);
> + mutex_unlock(&buffer->attachments_lock);
> +
> + sg_free_table(a->table);
> + kfree(a->table);
> + kfree(a);
> +}
> +
> +static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment *attachment,
> + enum dma_data_direction direction)
> +{
> + struct dma_heap_attachment *a = attachment->priv;
> + struct sg_table *table = a->table;
> +
> + /*
> + * As this heap is backed by uncached SRAM memory we do not need to
> + * perform any sync operations on the buffer before allowing device
> + * domain access. For this reason we use SKIP_CPU_SYNC and also do
> + * not use or provide begin/end_cpu_access() dma-buf functions.
> + */
> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> + direction, DMA_ATTR_SKIP_CPU_SYNC))
> + return ERR_PTR(-ENOMEM);
> +
> + return table;
> +}
> +
> +static void dma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
> + struct sg_table *table,
> + enum dma_data_direction direction)
> +{
> + dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
> + direction, DMA_ATTR_SKIP_CPU_SYNC);
> +}
> +
> +static void dma_heap_dma_buf_release(struct dma_buf *dmabuf)
> +{
> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
> +
> + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len);
> + kfree(buffer);
> +}
> +
> +static int dma_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> +{
> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
> + int ret;
> +
> + /* SRAM mappings are not cached */
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> +
> + ret = vm_iomap_memory(vma, buffer->paddr, buffer->len);
> + if (ret)
> + pr_err("Could not map buffer to userspace\n");
> +
> + return ret;
> +}
> +
> +static int dma_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
> +{
> + struct sram_dma_heap_buffer *buffer = dmabuf->priv;
> +
> + iosys_map_set_vaddr(map, buffer->vaddr);
> +
> + return 0;
> +}
> +
> +static const struct dma_buf_ops sram_dma_heap_buf_ops = {
> + .attach = dma_heap_attach,
> + .detach = dma_heap_detatch,
> + .map_dma_buf = dma_heap_map_dma_buf,
> + .unmap_dma_buf = dma_heap_unmap_dma_buf,
> + .release = dma_heap_dma_buf_release,
> + .mmap = dma_heap_mmap,
> + .vmap = dma_heap_vmap,
> +};
> +
> +static struct dma_buf *sram_dma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> + struct sram_dma_heap *sram_dma_heap = dma_heap_get_drvdata(heap);
> + struct sram_dma_heap_buffer *buffer;
> +
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret;
> +
> + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> + buffer->pool = sram_dma_heap->pool;
> + INIT_LIST_HEAD(&buffer->attachments);
> + mutex_init(&buffer->attachments_lock);
> + buffer->len = len;
> +
> + buffer->vaddr = (void *)gen_pool_alloc(buffer->pool, buffer->len);
> + if (!buffer->vaddr) {
> + ret = -ENOMEM;
> + goto free_buffer;
> + }
> +
> + buffer->paddr = gen_pool_virt_to_phys(buffer->pool, (unsigned long)buffer->vaddr);
> + if (buffer->paddr == -1) {
> + ret = -ENOMEM;
> + goto free_pool;
> + }
> +
> + /* create the dmabuf */
> + exp_info.exp_name = dma_heap_get_name(heap);
> + exp_info.ops = &sram_dma_heap_buf_ops;
> + exp_info.size = buffer->len;
> + exp_info.flags = fd_flags;
> + exp_info.priv = buffer;
> + dmabuf = dma_buf_export(&exp_info);
> + if (IS_ERR(dmabuf)) {
> + ret = PTR_ERR(dmabuf);
> + goto free_pool;
> + }
> +
> + return dmabuf;
> +
> +free_pool:
> + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len);
> +free_buffer:
> + kfree(buffer);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static struct dma_heap_ops sram_dma_heap_ops = {
> + .allocate = sram_dma_heap_allocate,
> +};
> +
> +int sram_add_dma_heap(struct sram_dev *sram,
> + struct sram_reserve *block,
> + phys_addr_t start,
> + struct sram_partition *part)
> +{
> + struct sram_dma_heap *sram_dma_heap;
> + struct dma_heap_export_info exp_info;
> +
> + dev_info(sram->dev, "Exporting SRAM Heap '%s'\n", block->label);
> +
> + sram_dma_heap = kzalloc(sizeof(*sram_dma_heap), GFP_KERNEL);
> + if (!sram_dma_heap)
> + return -ENOMEM;
> + sram_dma_heap->pool = part->pool;
> +
> + exp_info.name = kasprintf(GFP_KERNEL, "sram_%s", block->label);
> + exp_info.ops = &sram_dma_heap_ops;
> + exp_info.priv = sram_dma_heap;
> + sram_dma_heap->heap = dma_heap_add(&exp_info);
> + if (IS_ERR(sram_dma_heap->heap)) {
> + int ret = PTR_ERR(sram_dma_heap->heap);
> +
> + kfree(sram_dma_heap);
> + return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index 632f90d9bcea..643c77598beb 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -120,6 +120,12 @@ static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block,
> ret = sram_add_pool(sram, block, start, part);
> if (ret)
> return ret;
> +
> + if (block->export) {
> + ret = sram_add_dma_heap(sram, block, start, part);
> + if (ret)
> + return ret;
> + }
> }
> if (block->export) {
> ret = sram_add_export(sram, block, start, part);
> diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h
> index 397205b8bf6f..062bdd25fa06 100644
> --- a/drivers/misc/sram.h
> +++ b/drivers/misc/sram.h
> @@ -60,4 +60,20 @@ static inline int sram_add_protect_exec(struct sram_partition *part)
> return -ENODEV;
> }
> #endif /* CONFIG_SRAM_EXEC */
> +
> +#ifdef CONFIG_SRAM_DMA_HEAP
> +int sram_add_dma_heap(struct sram_dev *sram,
> + struct sram_reserve *block,
> + phys_addr_t start,
> + struct sram_partition *part);
> +#else
> +static inline int sram_add_dma_heap(struct sram_dev *sram,
> + struct sram_reserve *block,
> + phys_addr_t start,
> + struct sram_partition *part)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_SRAM_DMA_HEAP */
> +
> #endif /* __SRAM_H */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
2024-04-09 12:14 ` Greg Kroah-Hartman
@ 2024-04-19 16:57 ` Christian Gmeiner
2024-04-20 6:36 ` Greg Kroah-Hartman
0 siblings, 1 reply; 8+ messages in thread
From: Christian Gmeiner @ 2024-04-19 16:57 UTC (permalink / raw
To: Greg Kroah-Hartman
Cc: Pascal FONTAIN, linux-kernel, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Sumit Semwal, Christian König, afd,
linux-media, dri-devel, linaro-mm-sig
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 && SRAM
> > + help
> > + This driver allows the export of on-chip SRAM marked as both pool
> > + and 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.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas
2024-04-19 16:57 ` Christian Gmeiner
@ 2024-04-20 6:36 ` Greg Kroah-Hartman
0 siblings, 0 replies; 8+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-20 6:36 UTC (permalink / raw
To: Christian Gmeiner
Cc: Pascal FONTAIN, linux-kernel, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Sumit Semwal, Christian König, afd,
linux-media, dri-devel, linaro-mm-sig
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 && SRAM
> > > + help
> > > + This driver allows the export of on-chip SRAM marked as both pool
> > > + and 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-04-20 6:36 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-09 12:06 [PATCH v3 0/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
2024-04-09 12:06 ` [PATCH v3 1/2] misc: sram: Move probe of sram subsystem Pascal FONTAIN
2024-04-09 12:10 ` Arnd Bergmann
2024-04-09 12:06 ` [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas Pascal FONTAIN
2024-04-09 12:14 ` Greg Kroah-Hartman
2024-04-19 16:57 ` Christian Gmeiner
2024-04-20 6:36 ` Greg Kroah-Hartman
2024-04-09 14:38 ` Andrew Davis
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.