| Message ID | 20231023044549.21412-11-jason-jh.lin@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| 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: > Add cmdq_insert_backup_cookie to append some commands before EOC: > 1. Get GCE HW thread execute count from the GCE HW register. > 2. Add 1 to the execute count and then store into a shared memory. I think when cmdq driver handler interrupt, it could simply call into TEE with an API to query status. The status not only the execute count, but also other message including error information. So it's not necessary to use such non-tricky way to get execute count. One more question. The command buffer is not secure. Does the GCE hardware execute this non-secure command buffer? Regards, CK > 3. Set a software event siganl as secure irq to GCE HW. > > Since the value of execute count + 1 is stored in a shared memory, > CMDQ driver in the normal world can use it to handle task done in irq > handler and CMDQ driver in the secure world will use it to schedule > the task slot for each secure thread. > > Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> > --- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > index 6c2cf339b923..399aa6bb2f8d 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > @@ -177,7 +177,7 @@ void mtk_crtc_disable_secure_state(struct > drm_crtc *crtc) > sec_scn = CMDQ_SEC_SUB_DISP_DISABLE; > > cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle, sec_engine, > sec_engine, sec_scn); > - > + cmdq_sec_insert_backup_cookie(&mtk_crtc->sec_cmdq_handle); > cmdq_pkt_finalize(&mtk_crtc->sec_cmdq_handle); > dma_sync_single_for_device(mtk_crtc->sec_cmdq_client.chan- > >mbox->dev, > mtk_crtc->sec_cmdq_handle.pa_base, > @@ -786,6 +786,8 @@ static void mtk_drm_crtc_update_config(struct > mtk_drm_crtc *mtk_crtc, > cmdq_pkt_clear_event(cmdq_handle, mtk_crtc- > >cmdq_event); > cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false); > mtk_crtc_ddp_config(crtc, cmdq_handle); > + if (cmdq_handle->sec_data) > + cmdq_sec_insert_backup_cookie(cmdq_handle); > cmdq_pkt_finalize(cmdq_handle); > dma_sync_single_for_device(cmdq_client.chan->mbox->dev, > cmdq_handle->pa_base,
Hi CK, On Thu, 2023-10-26 at 02:26 +0000, CK Hu (胡俊光) wrote: > Hi, Jason: > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > Add cmdq_insert_backup_cookie to append some commands before EOC: > > 1. Get GCE HW thread execute count from the GCE HW register. > > 2. Add 1 to the execute count and then store into a shared memory. > > I think when cmdq driver handler interrupt, it could simply call into > TEE with an API to query status. The status not only the execute > count, > but also other message including error information. So it's not > necessary to use such non-tricky way to get execute count. The reason why we use shared memory to record execute count here is: 1. normal world can not access the register of secure GCE thread in normal world. 2. calling TEE invoke cmd in the irq handler would be expensive and not stable. I've tested that a single TEE invloke cmd to CMDQ PTA costs 19~53 us. Maybe it would cost more during the scenario that needs more CPU loading. > > One more question. The command buffer is not secure. Does the GCE > hardware execute this non-secure command buffer? > GCE command buffer is generate in the normal world first. Then it will be copied to the shared memory and pass to the secure world. All the instruction in command buffer will be verified in secure world then they will be copied to the secure command buffer and executed by GCE secure thread. I'll add this information to the cover letter at the next version. Regards Jason-JH.Lin > Regards, > CK >
On Sun, 2023-11-05 at 13:35 +0000, Jason-JH Lin (林睿祥) wrote: > Hi CK, > > On Thu, 2023-10-26 at 02:26 +0000, CK Hu (胡俊光) wrote: > > Hi, Jason: > > > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > > Add cmdq_insert_backup_cookie to append some commands before EOC: > > > 1. Get GCE HW thread execute count from the GCE HW register. > > > 2. Add 1 to the execute count and then store into a shared > > > memory. > > > > I think when cmdq driver handler interrupt, it could simply call > > into > > TEE with an API to query status. The status not only the execute > > count, > > but also other message including error information. So it's not > > necessary to use such non-tricky way to get execute count. > > The reason why we use shared memory to record execute count here is: > 1. normal world can not access the register of secure GCE thread in > normal world. > 2. calling TEE invoke cmd in the irq handler would be expensive and > not > stable. I've tested that a single TEE invloke cmd to CMDQ PTA costs > 19~53 us. Maybe it would cost more during the scenario that needs > more > CPU loading. Add this to comment. > > > > > One more question. The command buffer is not secure. Does the GCE > > hardware execute this non-secure command buffer? > > > > GCE command buffer is generate in the normal world first. Then it > will > be copied to the shared memory and pass to the secure world. All the > instruction in command buffer will be verified in secure world then > they will be copied to the secure command buffer and executed by GCE > secure thread. I'll add this information to the cover letter at the > next version. > > Regards > Jason-JH.Lin > > > Regards, > > CK > >
On Mon, 2023-11-06 at 01:36 +0000, CK Hu (胡俊光) wrote: > On Sun, 2023-11-05 at 13:35 +0000, Jason-JH Lin (林睿祥) wrote: > > Hi CK, > > > > On Thu, 2023-10-26 at 02:26 +0000, CK Hu (胡俊光) wrote: > > > Hi, Jason: > > > > > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote: > > > > Add cmdq_insert_backup_cookie to append some commands before > > > > EOC: > > > > 1. Get GCE HW thread execute count from the GCE HW register. > > > > 2. Add 1 to the execute count and then store into a shared > > > > memory. > > > > > > I think when cmdq driver handler interrupt, it could simply call > > > into > > > TEE with an API to query status. The status not only the execute > > > count, > > > but also other message including error information. So it's not > > > necessary to use such non-tricky way to get execute count. > > > > The reason why we use shared memory to record execute count here > > is: > > 1. normal world can not access the register of secure GCE thread in > > normal world. > > 2. calling TEE invoke cmd in the irq handler would be expensive and > > not > > stable. I've tested that a single TEE invloke cmd to CMDQ PTA costs > > 19~53 us. Maybe it would cost more during the scenario that needs > > more > > CPU loading. > > Add this to comment. > OK, I'll add this to comment. Regards, Jason-JH.Lin > > > > > > > > One more question. The command buffer is not secure. Does the GCE > > > hardware execute this non-secure command buffer? > > > > > > > GCE command buffer is generate in the normal world first. Then it > > will > > be copied to the shared memory and pass to the secure world. All > > the > > instruction in command buffer will be verified in secure world then > > they will be copied to the secure command buffer and executed by > > GCE > > secure thread. I'll add this information to the cover letter at the > > next version. > > > > Regards > > Jason-JH.Lin > > > > > Regards, > > > CK > > >
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index 6c2cf339b923..399aa6bb2f8d 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -177,7 +177,7 @@ void mtk_crtc_disable_secure_state(struct drm_crtc *crtc) sec_scn = CMDQ_SEC_SUB_DISP_DISABLE; cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle, sec_engine, sec_engine, sec_scn); - + cmdq_sec_insert_backup_cookie(&mtk_crtc->sec_cmdq_handle); cmdq_pkt_finalize(&mtk_crtc->sec_cmdq_handle); dma_sync_single_for_device(mtk_crtc->sec_cmdq_client.chan->mbox->dev, mtk_crtc->sec_cmdq_handle.pa_base, @@ -786,6 +786,8 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc, cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event); cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false); mtk_crtc_ddp_config(crtc, cmdq_handle); + if (cmdq_handle->sec_data) + cmdq_sec_insert_backup_cookie(cmdq_handle); cmdq_pkt_finalize(cmdq_handle); dma_sync_single_for_device(cmdq_client.chan->mbox->dev, cmdq_handle->pa_base,
Add cmdq_insert_backup_cookie to append some commands before EOC: 1. Get GCE HW thread execute count from the GCE HW register. 2. Add 1 to the execute count and then store into a shared memory. 3. Set a software event siganl as secure irq to GCE HW. Since the value of execute count + 1 is stored in a shared memory, CMDQ driver in the normal world can use it to handle task done in irq handler and CMDQ driver in the secure world will use it to schedule the task slot for each secure thread. Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)