Hi Maxime, On Mon, 2024-05-27 at 16:06 +0200, Maxime Ripard wrote: > Hi, > > On Sun, May 26, 2024 at 07:29:21AM GMT, Jason-JH.Lin wrote: > > From: Jason-jh Lin <jason-jh.lin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > > > > Memory Definitions: > > secure memory - Memory allocated in the TEE (Trusted Execution > > Environment) which is inaccessible in the REE (Rich Execution > > Environment, i.e. linux kernel/userspace). > > secure handle - Integer value which acts as reference to 'secure > > memory'. Used in communication between TEE and REE to reference > > 'secure memory'. > > secure buffer - 'secure memory' that is used to store decrypted, > > compressed video or for other general purposes in the TEE. > > secure surface - 'secure memory' that is used to store graphic > > buffers. > > > > Memory Usage in SVP: > > The overall flow of SVP starts with encrypted video coming in from > > an > > outside source into the REE. The REE will then allocate a 'secure > > buffer' and send the corresponding 'secure handle' along with the > > encrypted, compressed video data to the TEE. The TEE will then > > decrypt > > the video and store the result in the 'secure buffer'. The REE will > > then allocate a 'secure surface'. The REE will pass the 'secure > > handles' for both the 'secure buffer' and 'secure surface' into the > > TEE for video decoding. The video decoder HW will then decode the > > contents of the 'secure buffer' and place the result in the 'secure > > surface'. The REE will then attach the 'secure surface' to the > > overlay > > plane for rendering of the video. > > > > Everything relating to ensuring security of the actual contents of > > the > > 'secure buffer' and 'secure surface' is out of scope for the REE > > and > > is the responsibility of the TEE. > > > > DRM driver handles allocation of gem objects that are backed by a > > 'secure > > surface' and for displaying a 'secure surface' on the overlay > > plane. > > This introduces a new flag for object creation called > > DRM_MTK_GEM_CREATE_RESTRICTED which indicates it should be a > > 'secure > > surface'. All changes here are in MediaTek specific code. > > --- > > TODO: > > 1) Drop MTK_DRM_IOCTL_GEM_CREATE and use DMA_HEAP_IOCTL_ALLOC in > > userspace > > 2) DRM driver use secure mailbox channel to handle normal and > > secure flow > > 3) Implement setting mmsys routing table in the secure world series > > I'm not sure what you mean here. Why are you trying to upstream > something that still needs to be removed from your patch series? > Because their is too much patches need to be fixed in this series, so I list down the remaining TODO items and send to review for the other patches. Sorry for the bothering, I'll drop this at the next version. > Also, I made some comments on the previous version that have been > entirely ignored and still apply on this version: > https://lore.kernel.org/dri-devel/20240415-guppy-of-perpetual-current-3a7974@houat/ > I lost that mail in my mailbox, so I didn't reply at that time. I have imported that mail and replied to you. Hope you don't mind :) Regards, Jason-JH.Lin > Maxime
