On 10/20/2023 3:29 PM, Yong Wu (吴勇) wrote:
On Thu, 2023-10-19 at 10:15 +0530, Vijayanand Jitta wrote:
External email : Please do not click links or open attachments until you have verified the sender or the content.
On 9/11/2023 8:00 AM, Yong Wu wrote:
Initialise a mtk_svp heap. Currently just add a null heap, Prepare
for
the later patches.
Signed-off-by: Yong Wu yong.wu@mediatek.com
drivers/dma-buf/heaps/Kconfig | 8 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/mtk_secure_heap.c | 99
+++++++++++++++++++++++++
3 files changed, 108 insertions(+) create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-
buf/heaps/Kconfig
index a5eef06c4226..729c0cf3eb7c 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -12,3 +12,11 @@ config DMABUF_HEAPS_CMA Choose this option to enable dma-buf CMA heap. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+config DMABUF_HEAPS_MTK_SECURE +bool "DMA-BUF MediaTek Secure Heap" +depends on DMABUF_HEAPS && TEE +help
- Choose this option to enable dma-buf MediaTek secure heap for
Secure
- Video Path. This heap is backed by TEE client interfaces. If in
- doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-
buf/heaps/Makefile
index 974467791032..df559dbe33fe 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o obj-$(CONFIG_DMABUF_HEAPS_CMA)+= cma_heap.o +obj-$(CONFIG_DMABUF_HEAPS_MTK_SECURE)+= mtk_secure_heap.o diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c b/drivers/dma-
buf/heaps/mtk_secure_heap.c
new file mode 100644 index 000000000000..bbf1c8dce23e --- /dev/null +++ b/drivers/dma-buf/heaps/mtk_secure_heap.c @@ -0,0 +1,99 @@ +// SPDX-License-Identifier: GPL-2.0 +/*
- DMABUF mtk_secure_heap exporter
- Copyright (C) 2023 MediaTek Inc.
- */
+#include <linux/dma-buf.h> +#include <linux/dma-heap.h> +#include <linux/err.h> +#include <linux/module.h> +#include <linux/slab.h>
+/*
- MediaTek secure (chunk) memory type
- @KREE_MEM_SEC_CM_TZ: static chunk memory carved out for
trustzone.
- */
+enum kree_mem_type { +KREE_MEM_SEC_CM_TZ = 1, +};
+struct mtk_secure_heap_buffer { +struct dma_heap*heap; +size_tsize; +};
+struct mtk_secure_heap { +const char*name; +const enum kree_mem_type mem_type; +};
+static struct dma_buf * +mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
unsigned long fd_flags, unsigned long heap_flags)+{ +struct mtk_secure_heap_buffer *sec_buf; +DEFINE_DMA_BUF_EXPORT_INFO(exp_info); +struct dma_buf *dmabuf; +int ret;
+sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
As we know, kzalloc can only allocate 4MB at max. So, secure heap has this limitation. can we have a way to allocate more memory in secure heap ? maybe similar to how system heap does?
This is just the size of a internal structure. I guess you mean the secure memory size here. Regarding secure memory allocating flow, our flow may be different with yours.
Let me explain our flow, we have two secure buffer types(heaps). a) mtk_svp b) mtk_svp_cma which requires the cma binding.
The memory management of both is inside the TEE. We only need to tell the TEE which type and size of buffer we want, and then the TEE will perform and return the memory handle to the kernel. The kzalloc/alloc_pages is for the normal buffers.
Regarding the CMA buffer, we only call cma_alloc once, and its management is also within the TEE.
Thanks for the details.
I see for mvp_svp, allocation is also specific to TEE, as TEE takes care of allocation as well.
I was thinking if allocation path can also be made generic ? without having dependency on TEE. For eg : A case where we want to allocate from kernel and secure that memory, the current secure heap design can't be used.
Also i suppose TEE allocates contiguous memory for mtk_svp ? or does it support scattered memory ?
Thanks, Vijay