[v2] dma-buf: heaps: Introduce cma_heap_add() for non-default CMA heap

Commit Message

Jaskaran Singh Nov. 17, 2023, 10:03 a.m. UTC

From: Kunihiko Hayashi <[e-mail]>

Currently dma-buf heaps can handle only default CMA. This exposes
__add_cma_heap(), renamed to cma_heap_add(), as a public API to
initialize CMA heaps from a pointer to a CMA region.

At first, the driver calls of_reserved_mem_device_init() to set
memory-region property associated with reserved-memory defined as CMA
to the device. And when the driver calls this cma_heap_add() with the
struct cma attached to the device, the CMA will be added to dma-buf
heaps.

For example, prepare CMA node named "linux,cma@10000000" and
specify the node for memory-region property. After the above calls
in the driver, a device file "/dev/dma_heap/linux,cma@10000000"
associated with the CMA become available as dma-buf heaps.

Signed-off-by: Kunihiko Hayashi <[e-mail]>
[[e-mail]: Use struct cma as the function argument]
Signed-off-by: Jaskaran Singh <[e-mail]>
---
Reviving this patch as per discussions on the MediaTek Secure Heap patch
series[1]. There is now a potential client of the cma_heap_add() API.

An unaddressed problem in this patch is the proper parsing of heap
names. Naming convention for fixed address heaps in the devicetree is of
the format "[heap name]@[fixed address]", for example
"audio-heap@88b00000". Exposing heaps this way to userspace could
prove erroneous as the usecases fulfilled by these heaps are the same
across individual SoCs. Userspace clients of these heaps might expect a
more consistent interface. Any feedback on this is appreciated.

Changes v1->v2:
- Change the function argument for dma_heap_add_cma() from struct
  device to struct cma as per the discussion on [1].
- In lieu of the above point, discard dma_heap_add_cma() and instead
  expose the existing __add_cma_heap() as cma_heap_add().
- Make minor modifications to the commit message based on the changes in
  this version. Retain most of the original commit message.

v1: https://lore.kernel.org/lkml/[e-mail]/

[1] https://lore.kernel.org/lkml/[e-mail]/T/#m5184a1e13767bb656a4a3d9bf5a1fd7450e42eb7

 drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++--
 include/linux/dma-heap.h         | 10 ++++++++++
 2 files changed, 20 insertions(+), 2 deletions(-)

Patch

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index ee899f8e6721..b3bef8206e8b 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -367,7 +367,14 @@  static const struct dma_heap_ops cma_heap_ops = {
 	.allocate = cma_heap_allocate,
 };
 
-static int __add_cma_heap(struct cma *cma, void *data)
+/**
+ * cma_heap_add - adds a CMA heap to dmabuf heaps
+ * @cma:       pointer to the CMA pool to register the heap for
+ * @data:      unused
+ *
+ * Returns 0 on success. Else, returns errno.
+ */
+int cma_heap_add(struct cma *cma, void *data)
 {
 	struct cma_heap *cma_heap;
 	struct dma_heap_export_info exp_info;
@@ -391,6 +398,7 @@  static int __add_cma_heap(struct cma *cma, void *data)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(cma_heap_add);
 
 static int add_default_cma_heap(void)
 {
@@ -398,7 +406,7 @@  static int add_default_cma_heap(void)
 	int ret = 0;
 
 	if (default_cma)
-		ret = __add_cma_heap(default_cma, NULL);
+		ret = cma_heap_add(default_cma, NULL);
 
 	return ret;
 }
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 0c05561cad6e..adcd462825a8 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -12,6 +12,7 @@ 
 #include <linux/cdev.h>
 #include <linux/types.h>
 
+struct cma;
 struct dma_heap;
 
 /**
@@ -65,4 +66,13 @@  const char *dma_heap_get_name(struct dma_heap *heap);
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+#ifdef CONFIG_DMABUF_HEAPS_CMA
+int cma_heap_add(struct cma *cma, void *data);
+#else
+static inline int cma_heap_add(struct cma *cma, void *data)
+{
+	return -EINVAL;
+}
+#endif /* CONFIG_DMABUF_HEAPS_CMA */
+
 #endif /* _DMA_HEAPS_H */