Hi CK, Thanks for the reviews. [snip] > > > > We'll use cmdq_sec_pkt_set_data() to bring the secure scenario, > > secure > > engine flags and some secure metadata to TEE world. Then will used > > these information to make sure the pipeline is secure. > > > > We don't have the secure output feature currently, such as WiFi > > display, so we'll do it after we have to support the feature. > > > > Also there are HDMITX_HDCP and DPTX_HDCP TA will check the HDCP > > statue > > in secure world and then CMDQ TA will get that status by calling > > their > > API in TEE. > > If CMDQ TA get a HDCP checking failed sstatus, it will insert some > > instructions in the secure cmd buffer to mute the DISP HW for each > > frames. > > You enable secure path by crtc pipeline. That means it may be primary > display is secure and secondary display is non-secure. In > drivers/soc/mediatek/mt8195-mmsys.h, the primary display input could > be > routed to secondary display output. Is mmsys protected when display > is > secure? The whole mmsys is protected or partial mmsys is protected? VDOSYS0 has 2 pipelines and considering the scenario of using VDOSYS0-0 as secure and VDOSYS0-0 as normal, we can not protect mmsys path mux register. > If > the whole mmsys is protected, the non-secure display pipeline would > be > malfunctioned because the control of non-secure display is in normal > world and it may access mmsys. Please describe how this work? For this case, we'll use CMDQ PTA to block the invalid instructions and re-configure current mmsys path mux registers in every vblank interval by GCE. But we still have some works to do. The main idea would be moving mmsys configure operation to the ATF. Then protected the whole mmsys registers by DAPC. So normal world can't write mmsys registers without passing smc call cmd to ATF. ATF would check mux configure cmd is valid to current scenario, then configures the valid mmsys mux registers. Regards, Jason-JH.Lin > > Regards, > CK
