On Mon, 2023-09-11 at 12:12 -0400, Nicolas Dufresne wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Hi, > > Le lundi 11 septembre 2023 à 10:30 +0800, Yong Wu a écrit : > > From: John Stultz <jstultz@xxxxxxxxxx> > > > > This allows drivers who don't want to create their own > > DMA-BUF exporter to be able to allocate DMA-BUFs directly > > from existing DMA-BUF Heaps. > > > > There is some concern that the premise of DMA-BUF heaps is > > that userland knows better about what type of heap memory > > is needed for a pipeline, so it would likely be best for > > drivers to import and fill DMA-BUFs allocated by userland > > instead of allocating one themselves, but this is still > > up for debate. > > > Would be nice for the reviewers to provide the information about the > user of > this new in-kernel API. I noticed it because I was CCed, but > strangely it didn't > make it to the mailing list yet and its not clear in the cover what > this is used > with. > > I can explain in my words though, my read is that this is used to > allocate both > user visible and driver internal memory segments in MTK VCODEC > driver. > > I'm somewhat concerned that DMABuf objects are used to abstract > secure memory > allocation from tee. For framebuffers that are going to be exported > and shared > its probably fair use, but it seems that internal shared memory and > codec > specific reference buffers also endup with a dmabuf fd (often called > a secure fd > in the v4l2 patchset) for data that is not being shared, and requires > a 1:1 > mapping to a tee handle anyway. Is that the design we'd like to > follow ? Yes. basically this is right. > Can't > we directly allocate from the tee, adding needed helper to make this > as simple > as allocating from a HEAP ? If this happens, the memory will always be inside TEE. Here we create a new _CMA heap, it will cma_alloc/free dynamically. Reserve it before SVP start, and release to kernel after SVP done. Secondly. the v4l2/drm has the mature driver control flow, like drm_gem_prime_import_dev that always use dma_buf ops. So we can use the current flow as much as possible without having to re-plan a flow in the TEE. > > Nicolas > > > > > Signed-off-by: John Stultz <jstultz@xxxxxxxxxx> > > Signed-off-by: T.J. Mercier <tjmercier@xxxxxxxxxx> > > Signed-off-by: Yong Wu <yong.wu@xxxxxxxxxxxx> > > [Yong: Fix the checkpatch alignment warning] > > --- > > drivers/dma-buf/dma-heap.c | 60 ++++++++++++++++++++++++++++---- > ------ > > include/linux/dma-heap.h | 25 ++++++++++++++++ > > 2 files changed, 69 insertions(+), 16 deletions(-) > > [snip]
