| Message ID | 20240525232928.5524-1-jason-jh.lin@mediatek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add mediate-drm secure flow for SVP | expand |
Hi, On Sun, May 26, 2024 at 07:29:21AM GMT, Jason-JH.Lin wrote: > From: Jason-jh Lin <jason-jh.lin@mediatek.corp-partner.google.com> > > 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? 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/ Maxime
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@mediatek.corp-partner.google.com> > > > > 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
On Tue, May 28, 2024 at 07:15:34AM GMT, Jason-JH Lin (林睿祥) wrote: > 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@mediatek.corp-partner.google.com> > > > > > > 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. If you don't intend to use it, we just shouldn't add it. Removing the TODO item doesn't make sense, even more so if heaps should be the way you handle this. > > 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 :) I haven't received that answer Maxime
Hi Maxime, On Thu, 2024-05-30 at 17:01 +0200, mripard@kernel.org wrote: > On Tue, May 28, 2024 at 07:15:34AM GMT, Jason-JH Lin (林睿祥) wrote: > > 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@mediatek.corp-partner.google.com> > > > > > > > > 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. > > If you don't intend to use it, we just shouldn't add it. Removing the > TODO item doesn't make sense, even more so if heaps should be the way > you handle this. > Sorry for this misunderstanding. I mean I'll remove the DRM_IOCTL_GEM_CREATE patch and then change user space calling DMA_HEAP_IOCTL_ALLOC to allocate buffer from secure heap. > > > 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 > > :) > > I haven't received that answer I don't know why it doesn't show up at your link. Could you see it here? https://patchwork.kernel.org/project/linux-mediatek/patch/20240403102701.369-3-shawn.sung@mediatek.com/ Regards, Jason-JH.Lin > > Maxime
Hi Maxime, [snip] > > > > > --- > > > > > 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. > > > > If you don't intend to use it, we just shouldn't add it. Removing > > the > > TODO item doesn't make sense, even more so if heaps should be the > > way > > you handle this. > > > > Sorry for this misunderstanding. > > I mean I'll remove the DRM_IOCTL_GEM_CREATE patch and then change > user > space calling DMA_HEAP_IOCTL_ALLOC to allocate buffer from secure > heap. > I have changed user space to use DMA_HEAP_IOCTL_ALLOC to allocate secure buffer, but I still encounter the problem of determining whether the buffer is secure in mediatek-drm driver to add some secure configure for hardware. As the comment in [1], dma driver won't provide API for use. [1]: https://patchwork.kernel.org/project/linux-mediatek/patch/20240515112308.10171-3-yong.wu@mediatek.com/#25857255 So I use name checking at [PATCH v6 3/7] like this currently: struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev, struct dma_buf_attachment *attach, struct sg_table *sg) { struct mtk_gem_obj *mtk_gem; /* check if the entries in the sg_table are contiguous */ if (drm_prime_get_contiguous_size(sg) < attach->dmabuf->size) { DRM_ERROR("sg_table is not contiguous"); return ERR_PTR(-EINVAL); } mtk_gem = mtk_gem_init(dev, attach->dmabuf->size); if (IS_ERR(mtk_gem)) return ERR_CAST(mtk_gem); + mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted", 10)); mtk_gem->dma_addr = sg_dma_address(sg->sgl); + mtk_gem->size = attach->dmabuf->size; mtk_gem->sg = sg; return &mtk_gem->base; } But I want to change this name checking to the information brought from user space. I tried to use arg->flags to append the secure flag in user space and call drmPrimeHandleToFD() to pass it to DRM driver, but it will be blocked by at the beginning of the drm_prime_handle_to_fd_ioctl(). I can't find any other existing ioctl to pass such private information. Do you have any idea? Or should we open a new ioctl for that? Regards, Jason-JH.Lin > > > > 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 > > > :) > > > > I haven't received that answer > > I don't know why it doesn't show up at your link. > > Could you see it here? > > https://patchwork.kernel.org/project/linux-mediatek/patch/20240403102701.369-3-shawn.sung@mediatek.com/ > > > > Regards, > Jason-JH.Lin > > > > Maxime
Hi, On Tue, Jun 11, 2024 at 09:13:03AM GMT, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, > > [snip] > > > > > > > --- > > > > > > 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. > > > > > > If you don't intend to use it, we just shouldn't add it. Removing > > > the > > > TODO item doesn't make sense, even more so if heaps should be the > > > way > > > you handle this. > > > > > > > Sorry for this misunderstanding. > > > > I mean I'll remove the DRM_IOCTL_GEM_CREATE patch and then change > > user > > space calling DMA_HEAP_IOCTL_ALLOC to allocate buffer from secure > > heap. > > > > I have changed user space to use DMA_HEAP_IOCTL_ALLOC to allocate > secure buffer, but I still encounter the problem of determining whether > the buffer is secure in mediatek-drm driver to add some secure > configure for hardware. > > > As the comment in [1], dma driver won't provide API for use. > [1]: > https://patchwork.kernel.org/project/linux-mediatek/patch/20240515112308.10171-3-yong.wu@mediatek.com/#25857255 > > > So I use name checking at [PATCH v6 3/7] like this currently: > > struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device > *dev, > struct dma_buf_attachment *attach, struct sg_table *sg) > { > struct mtk_gem_obj *mtk_gem; > > /* check if the entries in the sg_table are contiguous */ > if (drm_prime_get_contiguous_size(sg) < attach->dmabuf->size) { > DRM_ERROR("sg_table is not contiguous"); > return ERR_PTR(-EINVAL); > } > > mtk_gem = mtk_gem_init(dev, attach->dmabuf->size); > if (IS_ERR(mtk_gem)) > return ERR_CAST(mtk_gem); > > + mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted", > 10)); > mtk_gem->dma_addr = sg_dma_address(sg->sgl); > + mtk_gem->size = attach->dmabuf->size; > mtk_gem->sg = sg; > > return &mtk_gem->base; > } > > But I want to change this name checking to the information brought from > user space. > I tried to use arg->flags to append the secure flag in user space and > call drmPrimeHandleToFD() to pass it to DRM driver, but it will be > blocked by at the beginning of the drm_prime_handle_to_fd_ioctl(). I agree with you, it's something to discuss mostly with the dma-buf maintainers but it would be better to just set a flag on the dma-buf, and use that flag whenever necessary. It might be related to the recent work I did to introduce allocation flags too: https://lore.kernel.org/linux-media/20240515-dma-buf-ecc-heap-v1-0-54cbbd049511@kernel.org/ Maxime
Hi Maxime, On Fri, 2024-06-21 at 11:00 +0200, mripard@kernel.org wrote: > Hi, > > On Tue, Jun 11, 2024 at 09:13:03AM GMT, Jason-JH Lin (林睿祥) wrote: > > Hi Maxime, > > [snip] > > I have changed user space to use DMA_HEAP_IOCTL_ALLOC to allocate > > secure buffer, but I still encounter the problem of determining > > whether > > the buffer is secure in mediatek-drm driver to add some secure > > configure for hardware. > > > > > > As the comment in [1], dma driver won't provide API for use. > > [1]: > > https://patchwork.kernel.org/project/linux-mediatek/patch/20240515112308.10171-3-yong.wu@mediatek.com/#25857255 > > > > > > So I use name checking at [PATCH v6 3/7] like this currently: > > > > struct drm_gem_object *mtk_gem_prime_import_sg_table(struct > > drm_device > > *dev, > > struct dma_buf_attachment *attach, struct sg_table *sg) > > { > > struct mtk_gem_obj *mtk_gem; > > > > /* check if the entries in the sg_table are contiguous */ > > if (drm_prime_get_contiguous_size(sg) < attach->dmabuf->size) { > > DRM_ERROR("sg_table is not contiguous"); > > return ERR_PTR(-EINVAL); > > } > > > > mtk_gem = mtk_gem_init(dev, attach->dmabuf->size); > > if (IS_ERR(mtk_gem)) > > return ERR_CAST(mtk_gem); > > > > + mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, > > "restricted", > > 10)); > > mtk_gem->dma_addr = sg_dma_address(sg->sgl); > > + mtk_gem->size = attach->dmabuf->size; > > mtk_gem->sg = sg; > > > > return &mtk_gem->base; > > } > > > > But I want to change this name checking to the information brought > > from > > user space. > > I tried to use arg->flags to append the secure flag in user space > > and > > call drmPrimeHandleToFD() to pass it to DRM driver, but it will be > > blocked by at the beginning of the drm_prime_handle_to_fd_ioctl(). > > I agree with you, it's something to discuss mostly with the dma-buf > maintainers but it would be better to just set a flag on the dma-buf, > and use that flag whenever necessary. > > It might be related to the recent work I did to introduce allocation > flags too: > https://lore.kernel.org/linux-media/20240515-dma-buf-ecc-heap-v1-0-54cbbd049511@kernel.org/ > Thanks for your information! I'll discuss with dma-buf maintainer in series [1]. Regards, Jason-JH Lin > Maxime
From: Jason-jh Lin <jason-jh.lin@mediatek.corp-partner.google.com> 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 --- Based on 3 series: [1] v3 dma-buf: heaps: Add MediaTek secure heap - https://patchwork.kernel.org/project/linux-mediatek/list/?series=809023 [2] v6 media: mediatek: add driver to support secure video decoder - https://patchwork.kernel.org/project/linux-mediatek/list/?series=853689 [3] v6 Add CMDQ secure driver for SVP - https://patchwork.kernel.org/project/linux-mediatek/list/?series=855884 --- Change in v6: 1. Rebase to linux-next then rebased on 3 series [1][2][3] 2. Remove some parameter and security settings in normal world 3. Drop secure port related patches 4. Fix some build error and warning Changes in v5: 1. Sync the local changes Changes in v4: 1. Rebase on mediatek-drm-next(278640d4d74cd) and fix the conflicts 2. This series is based on 20240129063025.29251-1-yunfei.dong@mediatek.com 3. This series is based on 20240322052829.9893-1-shawn.sung@mediatek.com 4. This series is based on 20240403065603.21920-1-shawn.sung@mediatek.com Changes in v3: 1. fix kerneldoc problems 2. fix typo in title and commit message 3. adjust naming for secure variable 4. add the missing part for is_suecure plane implementation 5. use BIT_ULL macro to replace bit shifting 6. move modification of ovl_adaptor part to the correct patch 7. add TODO list in commit message 8. add commit message for using share memory to store execute count Changes in v2: 1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl 2. move cmdq_insert_backup_cookie into client driver 3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi --- CK Hu (1): drm/mediatek: Add interface to allocate MediaTek GEM buffer Jason-JH.Lin (6): drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_RESTRICTED flag drm/mediatek: Add secure buffer control flow to mtk_drm_gem drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane drm/mediatek: Add mtk_ddp_sec_write() to config secure buffer info drm/mediatek: Add secure flow support to mediatek-drm drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize drivers/gpu/drm/mediatek/mtk_crtc.c | 263 +++++++++++++++++- drivers/gpu/drm/mediatek/mtk_crtc.h | 1 + drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 14 + drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 5 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 +- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 +- drivers/gpu/drm/mediatek/mtk_gem.c | 114 ++++++++ drivers/gpu/drm/mediatek/mtk_gem.h | 12 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 8 +- drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 1 + drivers/gpu/drm/mediatek/mtk_plane.c | 25 ++ drivers/gpu/drm/mediatek/mtk_plane.h | 2 + include/uapi/drm/mediatek_drm.h | 47 ++++ 14 files changed, 500 insertions(+), 15 deletions(-) create mode 100644 include/uapi/drm/mediatek_drm.h