Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On 11/6/2023 11:26 AM, Yong Wu (吴勇) wrote: > On Wed, 2023-11-01 at 11:20 +0530, Jaskaran Singh wrote: >> >> External email : Please do not click links or open attachments until >> you have verified the sender or the content. >> On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote: >>> On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote: >>>> >>>> Instead of having a vendor specific binding for cma area, How >> about >>>> retrieving >>>> >>> >> https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/ >>>> ? >>>> dma_heap_add_cma can just associate cma region and create a heap. >> So, >>>> we can reuse cma heap >>>> code for allocation instead of replicating that code here. >>>> >>> >>> Thanks for the reference. I guess we can't use it. There are two >>> reasons: >>> >>> a) The secure heap driver is a pure software driver and we have no >>> device for it, therefore we cannot call dma_heap_add_cma. >>> >> >> Hi Yong, >> >> We're considering using struct cma as the function argument to >> dma_heap_add_cma() rather than struct device. Would this help >> resolve the problem of usage with dma_heap_add_cma()? > > Yes. If we use "struct cma", I guess it works. > Great; I've posted a v2[1] for the API incorporating this change. Thanks, Jaskaran. [1] https://lore.kernel.org/lkml/20231117100337.5215-1-quic_jasks...@quicinc.com/
[PATCH v2] dma-buf: heaps: Introduce cma_heap_add() for non-default CMA heap
From: Kunihiko Hayashi
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@1000" and
specify the node for memory-region property. After the above calls
in the driver, a device file "/dev/dma_heap/linux,cma@1000"
associated with the CMA become available as dma-buf heaps.
Signed-off-by: Kunihiko Hayashi
[quic_jasks...@quicinc.com: Use struct cma as the function argument]
Signed-off-by: Jaskaran Singh
---
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@88b0". 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.kunih...@socionext.com/
[1]
https://lore.kernel.org/lkml/20230911023038.30649-1-yong...@mediatek.com/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
#include
+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
Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote: > On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote: >> >> Instead of having a vendor specific binding for cma area, How about >> retrieving >> > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/ >> ? >> dma_heap_add_cma can just associate cma region and create a heap. So, >> we can reuse cma heap >> code for allocation instead of replicating that code here. >> > > Thanks for the reference. I guess we can't use it. There are two > reasons: > > a) The secure heap driver is a pure software driver and we have no > device for it, therefore we cannot call dma_heap_add_cma. > Hi Yong, We're considering using struct cma as the function argument to dma_heap_add_cma() rather than struct device. Would this help resolve the problem of usage with dma_heap_add_cma()? > b) The CMA area here is dynamic for SVP. Normally this CMA can be used > in the kernel. In the SVP case we use cma_alloc to get it and pass the > entire CMA physical start address and size into TEE to protect the CMA > region. The original CMA heap cannot help with the TEE part. > Referring the conversation at https://lore.kernel.org/lkml/7a2995de23c24ef22c071c6976c02b97e9b50126.ca...@mediatek.com/; since we're considering abstracting secure mem ops, would it make sense to use the default CMA heap ops (cma_heap_ops), allocate buffers from it and secure each allocated buffer? Thanks, Jaskaran. > Thanks. > >> Thanks, >> Vijay >> >> >>
[PATCH] drivers: gpu: amdgpu: Remove @dev from amdgpu_gem_prime_export documentation
The function does not have a "dev" argument, so remove it from
the documentation. This fixes the following documentation
build warning:
./drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:335:
warning: Excess function parameter 'dev' description in
'amdgpu_gem_prime_export'
Signed-off-by: Jaskaran Singh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 61f108ec2b5c..4917b548b7f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -321,7 +321,6 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
/**
* amdgpu_gem_prime_export - _driver.gem_prime_export implementation
- * @dev: DRM device
* @gobj: GEM BO
* @flags: Flags such as DRM_CLOEXEC and DRM_RDWR.
*
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
