| Message ID | 20231023044549.21412-1-jason-jh.lin@mediatek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add mediate-drm secure flow for SVP | expand |
Hi, Jason: On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > The patch series provides drm driver support for enabling secure > video > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > 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_ENCRYPTED which indicates it should be a 'secure > surface'. All changes here are in MediaTek specific code. > > --- > Based on 3 series and 1 patch: > [1] dma-buf: heaps: Add MediaTek secure heap > - > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSQXcbgPU$ > > > [2] add driver to support secure video decoder > - > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782922__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSIPyCQxI$ > > > [3] soc: mediatek: Add register definitions for GCE > - > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung@mediatek.com/__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSrO8gmbI$ > > > [4] Add CMDQ secure driver for SVP > - > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=795502__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSposD2Rk$ > Secure display depend on secure mmsys. Routing control should be secure so mmsys driver should have some modification that call into secure world to change routing. Add mmsys series in this dependency list. Regards, CK > --- > Change 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 (10): > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED 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 get_sec_port interface to mtk_ddp_comp > drm/mediatek: Add secure layer config support for ovl > drm/mediatek: Add secure layer config support for ovl_adaptor > drm/mediatek: Add secure flow support to mediatek-drm > drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt > finalize > arm64: dts: mt8195: Add secure mbox settings for vdosys > > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 274 > +++++++++++++++++- > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 + > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 + > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > include/uapi/drm/mediatek_drm.h | 59 ++++ > 16 files changed, 570 insertions(+), 18 deletions(-) > create mode 100644 include/uapi/drm/mediatek_drm.h >
Hi CK, Thanks for the reviews. On Tue, 2023-10-31 at 02:12 +0000, CK Hu (胡俊光) wrote: > Hi, Jason: > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > The patch series provides drm driver support for enabling secure > > video > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > 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_ENCRYPTED which indicates it should be a 'secure > > surface'. All changes here are in MediaTek specific code. > > > > --- > > Based on 3 series and 1 patch: > > [1] dma-buf: heaps: Add MediaTek secure heap > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSQXcbgPU$ > > > > > > [2] add driver to support secure video decoder > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782922__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSIPyCQxI$ > > > > > > [3] soc: mediatek: Add register definitions for GCE > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung@mediatek.com/__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSrO8gmbI$ > > > > > > [4] Add CMDQ secure driver for SVP > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=795502__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSposD2Rk$ > > > > Secure display depend on secure mmsys. Routing control should be > secure > so mmsys driver should have some modification that call into secure > world to change routing. Add mmsys series in this dependency list. Yes, I'll move the route settings to the secure world for those SVP supported SoC. The mmsys modifications are still in progress. It will be send after a few version. Regards Jason-JH.Lin > > Regards, > CK > > > --- > > Change 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 (10): > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED 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 get_sec_port interface to mtk_ddp_comp > > drm/mediatek: Add secure layer config support for ovl > > drm/mediatek: Add secure layer config support for ovl_adaptor > > drm/mediatek: Add secure flow support to mediatek-drm > > drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt > > finalize > > arm64: dts: mt8195: Add secure mbox settings for vdosys > > > > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 274 > > +++++++++++++++++- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 + > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 + > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > > include/uapi/drm/mediatek_drm.h | 59 ++++ > > 16 files changed, 570 insertions(+), 18 deletions(-) > > create mode 100644 include/uapi/drm/mediatek_drm.h > >
On Sun, 2023-11-05 at 13:44 +0000, Jason-JH Lin (林睿祥) wrote: > Hi CK, > > Thanks for the reviews. > > On Tue, 2023-10-31 at 02:12 +0000, CK Hu (胡俊光) wrote: > > Hi, Jason: > > > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > > The patch series provides drm driver support for enabling secure > > > video > > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > > > 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_ENCRYPTED which indicates it should be a > > > 'secure > > > surface'. All changes here are in MediaTek specific code. > > > > > > --- > > > Based on 3 series and 1 patch: > > > [1] dma-buf: heaps: Add MediaTek secure heap > > > - > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSQXcbgPU$ > > > > > > > > > [2] add driver to support secure video decoder > > > - > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782922__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSIPyCQxI$ > > > > > > > > > [3] soc: mediatek: Add register definitions for GCE > > > - > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung@mediatek.com/__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSrO8gmbI$ > > > > > > > > > [4] Add CMDQ secure driver for SVP > > > - > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=795502__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSposD2Rk$ > > > > > > > Secure display depend on secure mmsys. Routing control should be > > secure > > so mmsys driver should have some modification that call into secure > > world to change routing. Add mmsys series in this dependency list. > > Yes, I'll move the route settings to the secure world for those SVP > supported SoC. The mmsys modifications are still in progress. It will > be send after a few version. Add TODO information so that we would not forget this. > > Regards > Jason-JH.Lin > > > > > Regards, > > CK > > > > > --- > > > Change 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 (10): > > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED 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 get_sec_port interface to mtk_ddp_comp > > > drm/mediatek: Add secure layer config support for ovl > > > drm/mediatek: Add secure layer config support for ovl_adaptor > > > drm/mediatek: Add secure flow support to mediatek-drm > > > drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt > > > finalize > > > arm64: dts: mt8195: Add secure mbox settings for vdosys > > > > > > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- > > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 274 > > > +++++++++++++++++- > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 + > > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > > > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 + > > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > > > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > > > include/uapi/drm/mediatek_drm.h | 59 ++++ > > > 16 files changed, 570 insertions(+), 18 deletions(-) > > > create mode 100644 include/uapi/drm/mediatek_drm.h > > >
On Mon, 2023-11-06 at 01:37 +0000, CK Hu (胡俊光) wrote: > On Sun, 2023-11-05 at 13:44 +0000, Jason-JH Lin (林睿祥) wrote: > > Hi CK, > > > > Thanks for the reviews. > > > > On Tue, 2023-10-31 at 02:12 +0000, CK Hu (胡俊光) wrote: > > > Hi, Jason: > > > > > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > > > The patch series provides drm driver support for enabling > > > > secure > > > > video > > > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > > > > > 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_ENCRYPTED which indicates it should be a > > > > 'secure > > > > surface'. All changes here are in MediaTek specific code. > > > > > > > > --- > > > > Based on 3 series and 1 patch: > > > > [1] dma-buf: heaps: Add MediaTek secure heap > > > > - > > > > > > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSQXcbgPU$ > > > > > > > > > > > > [2] add driver to support secure video decoder > > > > - > > > > > > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782922__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSIPyCQxI$ > > > > > > > > > > > > [3] soc: mediatek: Add register definitions for GCE > > > > - > > > > > > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung@mediatek.com/__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSrO8gmbI$ > > > > > > > > > > > > [4] Add CMDQ secure driver for SVP > > > > - > > > > > > > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=795502__;!!CTRNKA9wMg0ARbw!mFKxGfpXLEF8-AzhljGG_N12bk-h7W0-JZeTZZkqxJgB5WFbMTxeEjalrslLrAJ3iwYF6-k273jgzXKSposD2Rk$ > > > > > > > > > > Secure display depend on secure mmsys. Routing control should be > > > secure > > > so mmsys driver should have some modification that call into > > > secure > > > world to change routing. Add mmsys series in this dependency > > > list. > > > > Yes, I'll move the route settings to the secure world for those SVP > > supported SoC. The mmsys modifications are still in progress. It > > will > > be send after a few version. > > Add TODO information so that we would not forget this. > OK, I'll add TODO to the commit message. Regards, Jason-JH.Lin > > > > Regards > > Jason-JH.Lin > > > > > > > > Regards, > > > CK > > > > > > > --- > > > > Change 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 (10): > > > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED 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 get_sec_port interface to mtk_ddp_comp > > > > drm/mediatek: Add secure layer config support for ovl > > > > drm/mediatek: Add secure layer config support for ovl_adaptor > > > > drm/mediatek: Add secure flow support to mediatek-drm > > > > drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt > > > > finalize > > > > arm64: dts: mt8195: Add secure mbox settings for vdosys > > > > > > > > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- > > > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 274 > > > > +++++++++++++++++- > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 + > > > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 121 ++++++++ > > > > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 + > > > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 + > > > > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + > > > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- > > > > drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + > > > > include/uapi/drm/mediatek_drm.h | 59 ++++ > > > > 16 files changed, 570 insertions(+), 18 deletions(-) > > > > create mode 100644 include/uapi/drm/mediatek_drm.h > > > >