On Tue, 2023-09-12 at 11:05 -0400, Nicolas Dufresne wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Le mardi 12 septembre 2023 à 08:47 +0000, Yong Wu (吴勇) a écrit : > > 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. > > Ok, I see the benefit of having a common driver then. It would add to > the > complexity, but having a driver for the tee allocator and v4l2/heaps > would be > another option? It's ok for v4l2. But our DRM also use this new heap and it will be sent upstream in the next few days. > > > > > 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. > > From what I've read from Yunfei series, this is only partially true > for V4L2. > The vb2 queue MMAP feature have dmabuf exportation as optional, but > its not a > problem to always back it up with a dmabuf object. But for internal > SHM buffers > used for firmware communication, I've never seen any driver use a > DMABuf. > > Same applies for primary decode buffers when frame buffer compression > or post- > processing it used (or reconstruction buffer in encoders), these are > not user > visible and are usually not DMABuf. If they aren't dmabuf, of course it is ok. I guess we haven't used these. The SHM buffer is got by tee_shm_register_kernel_buf in this case and we just use the existed dmabuf ops to complete SVP. In our case, the vcodec input/output/working buffers and DRM input buffer all use this new secure heap during secure video play. > > > > > > > > > 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] >
