From: Kunihiko Hayashi <hayashi.kunihiko@xxxxxxxxxxxxx> 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 <hayashi.kunihiko@xxxxxxxxxxxxx> [quic_jasksing@xxxxxxxxxxx: Use struct cma as the function argument] Signed-off-by: Jaskaran Singh <quic_jasksing@xxxxxxxxxxx> --- 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/1594948208-4739-1-git-send-email-hayashi.kunihiko@xxxxxxxxxxxxx/ [1] https://lore.kernel.org/lkml/20230911023038.30649-1-yong.wu@xxxxxxxxxxxx/T/#m5184a1e13767bb656a4a3d9bf5a1fd7450e42eb7 drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++-- include/linux/dma-heap.h | 10 ++++++++++ 2 files changed, 20 insertions(+), 2 deletions(-) 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 */ -- 2.17.1
