[PATCH 00/14] add driver to support secure video decoder

[PATCH 00/14] add driver to support secure video decoder

[Yunfei Dong]

In order to support secure video decoder for mt8195/mt8188 h264 driver,
need to use tee client interface to communicate with optee-os. Firstly,
open tee context and tee session for each hardware.

Secondly, allocate two shared memory msg and vsi, msg used to send ipi to
optee-os and get ack msg from optee-os, vsi used to store syntax for
hardware decoder.

Thirdly, adding two CID controls: V4L2_CID_MPEG_MTK_SET_SECURE_MODE and
V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, get secure handle used for user space
to convert secure fd to secure handle, set secure mode used to tell decoder
driver to initialize tee interface to decode secure video.

Lastly, re-construct h264 driver to support secure video decoder.

Patch 1~4  initialize tee related interface and parameters.
Patch 5~6  allocate/free secure memory.
Patch 7    map vsi for secure mode.
Patch 8    support one plane capture buffer.
Patch 9~10 re-construct h264 driver to support secure mode.
patch 11   used to convert secure fd to secure handle.
Patch 12   used to set secure decoder mode.
Patch 13   disable interrupt.
Patch 14   support tee decode
---
Reference series:
[1]: v1 of this series is submitted by Yong Wu.
	message-id: 20230911023038.30649-1-yong.wu@mediatek.com

Yunfei Dong (14):
  media: mediatek: vcodec: add tee client interface to communiate with
    optee-os
  media: mediatek: vcodec: allocate tee share memory
  media: mediatek: vcodec: send share memory data to optee
  media: mediatek: vcodec: initialize msg and vsi information
  media: mediatek: vcodec: using encoder's device to alloc/free memory
  media: mediatek: vcodec: add interface to allocate/free secure memory
  media: mediatek: vcodec: using shared memory as vsi address
  media: medkatek: vcodec: support one plane capture buffer
  media: medkatek: vcodec: re-construct h264 driver to support svp mode
  media: medkatek: vcodec: remove parse nal_info in kernel
  media: medkatek: vcodec: covert secure fd to secure handle
  media: medkatek: vcodec: set secure mode to decoder driver
  media: medkatek: vcodec: disable wait interrupt for svp mode
  media: medkatek: vcodec: support tee decoder

 .../media/platform/mediatek/vcodec/Kconfig    |   1 +
 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 177 ++++++++-
 .../mediatek/vcodec/common/mtk_vcodec_util.h  |   3 +
 .../platform/mediatek/vcodec/decoder/Makefile |   1 +
 .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  |  24 +-
 .../vcodec/decoder/mtk_vcodec_dec_drv.c       |   9 +
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |   7 +
 .../vcodec/decoder/mtk_vcodec_dec_hw.c        |  34 +-
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 373 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     | 156 ++++++++
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c |  80 +++-
 .../decoder/vdec/vdec_h264_req_common.c       |  16 +-
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 334 +++++++++-------
 .../mediatek/vcodec/decoder/vdec_drv_if.c     |   4 +-
 .../mediatek/vcodec/decoder/vdec_msg_queue.c  |   9 +-
 .../mediatek/vcodec/decoder/vdec_vpu_if.c     |  54 ++-
 .../mediatek/vcodec/decoder/vdec_vpu_if.h     |   4 +
 drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  10 +
 include/uapi/linux/v4l2-controls.h            |   5 +
 19 files changed, 1110 insertions(+), 191 deletions(-)
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h

-- 
2.18.0

[PATCH 01/14] media: mediatek: vcodec: add tee client interface to communiate with optee-os

[Yunfei Dong]

Open tee context to initialize the environment in order to communiate
with optee-os, then open tee session as the communiation pipeline for
lat and core to send data for hardware decode.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../platform/mediatek/vcodec/decoder/Makefile |   1 +
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |   5 +
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 157 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  73 ++++++++
 4 files changed, 236 insertions(+)
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/Makefile b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
index 904cd22def84..1624933dfd5e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/Makefile
+++ b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
@@ -21,5 +21,6 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
 		mtk_vcodec_dec_stateful.o \
 		mtk_vcodec_dec_stateless.o \
 		mtk_vcodec_dec_pm.o \
+		mtk_vcodec_dec_optee.o \
 
 mtk-vcodec-dec-hw-y := mtk_vcodec_dec_hw.o
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
index 7e36b2c69b7d..061542c3852c 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
@@ -11,6 +11,7 @@
 #include "../common/mtk_vcodec_dbgfs.h"
 #include "../common/mtk_vcodec_fw_priv.h"
 #include "../common/mtk_vcodec_util.h"
+#include "mtk_vcodec_dec_optee.h"
 #include "vdec_msg_queue.h"
 
 #define MTK_VCODEC_DEC_NAME	"mtk-vcodec-dec"
@@ -249,6 +250,8 @@ struct mtk_vcodec_dec_ctx {
  * @vdec_racing_info: record register value
  * @dec_racing_info_mutex: mutex lock used for inner racing mode
  * @dbgfs: debug log related information
+ *
+ * @tee_private: optee private data
  */
 struct mtk_vcodec_dec_dev {
 	struct v4l2_device v4l2_dev;
@@ -289,6 +292,8 @@ struct mtk_vcodec_dec_dev {
 	/* Protects access to vdec_racing_info data */
 	struct mutex dec_racing_info_mutex;
 	struct mtk_vcodec_dbgfs dbgfs;
+
+	struct mtk_vdec_optee_private *optee_private;
 };
 
 static inline struct mtk_vcodec_dec_ctx *fh_to_dec_ctx(struct v4l2_fh *fh)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
new file mode 100644
index 000000000000..3ee9039d2a5b
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Yunfei Dong <yunfei.dong@mediatek.com>
+ */
+
+#include "mtk_vcodec_dec_drv.h"
+#include "mtk_vcodec_dec_optee.h"
+
+/*
+ * Randomly generated, and must correspond to the GUID on the TA side.
+ */
+static const uuid_t mtk_vdec_lat_uuid =
+	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x90);
+
+static const uuid_t mtk_vdec_core_uuid =
+	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x91);
+
+/*
+ * Check whether this driver supports decoder TA in the TEE instance,
+ * represented by the params (ver/data) of this function.
+ */
+static int mtk_vcodec_dec_optee_match(struct tee_ioctl_version_data *ver_data, const void *not_used)
+{
+	if (ver_data->impl_id == TEE_IMPL_ID_OPTEE)
+		return 1;
+	else
+		return 0;
+}
+
+int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
+{
+	vcodec_dev->optee_private = devm_kzalloc(&vcodec_dev->plat_dev->dev,
+						 sizeof(*vcodec_dev->optee_private),
+						 GFP_KERNEL);
+	if (!vcodec_dev->optee_private)
+		return -ENOMEM;
+
+	vcodec_dev->optee_private->vcodec_dev = vcodec_dev;
+
+	atomic_set(&vcodec_dev->optee_private->tee_active_cnt, 0);
+	mutex_init(&vcodec_dev->optee_private->tee_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
+
+static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
+					     enum mtk_vdec_hw_id hardware_index)
+{
+	struct tee_ioctl_open_session_arg session_arg;
+	struct mtk_vdec_optee_ca_info *ca_info;
+	int err = 0, session_func;
+
+	/* Open lat and core session with vdec TA. */
+	if (hardware_index == MTK_VDEC_LAT0) {
+		export_uuid(session_arg.uuid, &mtk_vdec_lat_uuid);
+		session_func = MTK_VDEC_OPTEE_TA_LAT_SUBMIT_COMMAND;
+		ca_info = &optee_private->lat_ca;
+	} else {
+		export_uuid(session_arg.uuid, &mtk_vdec_core_uuid);
+		session_func = MTK_VDEC_OPTEE_TA_CORE_SUBMIT_COMMAND;
+		ca_info = &optee_private->core_ca;
+	}
+
+	session_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+	session_arg.num_params = 0;
+
+	err = tee_client_open_session(optee_private->tee_vdec_ctx, &session_arg, NULL);
+	if (err < 0 || session_arg.ret != 0) {
+		pr_err(MTK_DBG_VCODEC_STR "open vdec tee session failed: hw_id(%d) err=%x.\n",
+		       hardware_index, session_arg.ret);
+		return -EINVAL;
+	}
+	ca_info->vdec_session_id = session_arg.session;
+	ca_info->hw_id = hardware_index;
+	ca_info->vdec_session_func = session_func;
+
+	pr_debug(MTK_DBG_VCODEC_STR "open vdec tee session: hw_id(%d) session_id=%x.\n",
+		 hardware_index, ca_info->vdec_session_id);
+
+	return err;
+}
+
+static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *optee_private,
+						enum mtk_vdec_hw_id hw_id)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
+}
+
+int mtk_vcodec_dec_optee_open(struct mtk_vdec_optee_private *optee_private)
+{
+	int err = 0;
+
+	mutex_lock(&optee_private->tee_mutex);
+	if (atomic_inc_return(&optee_private->tee_active_cnt) > 1) {
+		mutex_unlock(&optee_private->tee_mutex);
+		pr_debug(MTK_DBG_VCODEC_STR "already init vdec optee private data!\n");
+		return err;
+	}
+
+	/* Open context with TEE driver */
+	optee_private->tee_vdec_ctx = tee_client_open_context(NULL, mtk_vcodec_dec_optee_match,
+							      NULL, NULL);
+	if (IS_ERR(optee_private->tee_vdec_ctx)) {
+		pr_err(MTK_DBG_VCODEC_STR "optee vdec tee context failed.\n");
+		mutex_unlock(&optee_private->tee_mutex);
+		return -ENODEV;
+	}
+
+	err = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_LAT0);
+	if (err < 0)
+		goto err_lat_init;
+
+	if (IS_VDEC_LAT_ARCH(optee_private->vcodec_dev->vdec_pdata->hw_arch)) {
+		err = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_CORE);
+		if (err < 0)
+			goto err_core_init;
+	}
+
+	mutex_unlock(&optee_private->tee_mutex);
+	return 0;
+err_core_init:
+	mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_LAT0);
+err_lat_init:
+	tee_client_close_context(optee_private->tee_vdec_ctx);
+
+	mutex_unlock(&optee_private->tee_mutex);
+	return err;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_open);
+
+void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private)
+{
+	mutex_lock(&optee_private->tee_mutex);
+	if (!atomic_dec_and_test(&optee_private->tee_active_cnt)) {
+		mutex_unlock(&optee_private->tee_mutex);
+		return;
+	}
+
+	mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_LAT0);
+	if (IS_VDEC_LAT_ARCH(optee_private->vcodec_dev->vdec_pdata->hw_arch))
+		mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_CORE);
+
+	tee_client_close_context(optee_private->tee_vdec_ctx);
+	mutex_unlock(&optee_private->tee_mutex);
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_release);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
new file mode 100644
index 000000000000..8b1dca49331e
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Yunfei Dong <yunfei.dong@mediatek.com>
+ */
+
+#ifndef _MTK_VCODEC_DEC_OPTEE_H_
+#define _MTK_VCODEC_DEC_OPTEE_H_
+
+#include <linux/tee_drv.h>
+#include <linux/uuid.h>
+
+#include "mtk_vcodec_dec_drv.h"
+
+/* The TA ID implemented in this TA */
+#define MTK_VDEC_OPTEE_TA_LAT_SUBMIT_COMMAND  (0x10)
+#define MTK_VDEC_OPTEE_TA_CORE_SUBMIT_COMMAND  (0x20)
+
+#define MTK_OPTEE_MAX_TEE_PARAMS 4
+
+/**
+ * struct mtk_vdec_optee_ca_info - ca related param
+ * @vdec_session_id:   optee TA session identifier.
+ * @hw_id:             hardware index.
+ * @vdec_session_func: trusted application function id used specific to the TA.
+ */
+struct mtk_vdec_optee_ca_info {
+	u32 vdec_session_id;
+	enum mtk_vdec_hw_id hw_id;
+	u32 vdec_session_func;
+};
+
+/**
+ * struct mtk_vdec_optee_private - optee private data
+ * @vcodec_dev:     pointer to the mtk_vcodec_dev of the device
+ * @tee_vdec_ctx:   decoder TEE context handler.
+ * @lat_ca:         lat hardware information used to communicate with TA.
+ * @core_ca:        core hardware information used to communicate with TA.
+ *
+ * @tee_active_cnt: used to mark whether need to init optee
+ * @tee_mutex:      mutex lock used for optee
+ */
+struct mtk_vdec_optee_private {
+	struct mtk_vcodec_dec_dev *vcodec_dev;
+	struct tee_context *tee_vdec_ctx;
+
+	struct mtk_vdec_optee_ca_info lat_ca;
+	struct mtk_vdec_optee_ca_info core_ca;
+
+	atomic_t tee_active_cnt;
+	/* mutext used to lock optee open and release information. */
+	struct mutex tee_mutex;
+};
+
+/**
+ * mtk_vcodec_dec_optee_open - setup the communication channels with TA.
+ * @optee_private: optee private context
+ */
+int mtk_vcodec_dec_optee_open(struct mtk_vdec_optee_private *optee_private);
+
+/**
+ * mtk_vcodec_dec_optee_private_init - init optee parameters.
+ * @vcodec_dev: pointer to the mtk_vcodec_dev of the device
+ */
+int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev);
+
+/**
+ * mtk_vcodec_dec_optee_release - close the communication channels with TA.
+ * @optee_private: optee private context
+ */
+void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private);
+
+#endif /* _MTK_VCODEC_FW_OPTEE_H_ */
-- 
2.18.0

Re: [PATCH 01/14] media: mediatek: vcodec: add tee client interface to communiate with optee-os

[AngeloGioacchino Del Regno]

Il 11/09/23 14:59, Yunfei Dong ha scritto:
> Open tee context to initialize the environment in order to communiate
> with optee-os, then open tee session as the communiation pipeline for
> lat and core to send data for hardware decode.
> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>   .../platform/mediatek/vcodec/decoder/Makefile |   1 +
>   .../vcodec/decoder/mtk_vcodec_dec_drv.h       |   5 +
>   .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 157 ++++++++++++++++++
>   .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  73 ++++++++
>   4 files changed, 236 insertions(+)
>   create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
>   create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/Makefile b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
> index 904cd22def84..1624933dfd5e 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/Makefile
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
> @@ -21,5 +21,6 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
>   		mtk_vcodec_dec_stateful.o \
>   		mtk_vcodec_dec_stateless.o \
>   		mtk_vcodec_dec_pm.o \
> +		mtk_vcodec_dec_optee.o \
>   
>   mtk-vcodec-dec-hw-y := mtk_vcodec_dec_hw.o
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> index 7e36b2c69b7d..061542c3852c 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> @@ -11,6 +11,7 @@
>   #include "../common/mtk_vcodec_dbgfs.h"
>   #include "../common/mtk_vcodec_fw_priv.h"
>   #include "../common/mtk_vcodec_util.h"
> +#include "mtk_vcodec_dec_optee.h"
>   #include "vdec_msg_queue.h"
>   
>   #define MTK_VCODEC_DEC_NAME	"mtk-vcodec-dec"
> @@ -249,6 +250,8 @@ struct mtk_vcodec_dec_ctx {
>    * @vdec_racing_info: record register value
>    * @dec_racing_info_mutex: mutex lock used for inner racing mode
>    * @dbgfs: debug log related information
> + *
> + * @tee_private: optee private data

This should be @optee_private

>    */
>   struct mtk_vcodec_dec_dev {
>   	struct v4l2_device v4l2_dev;
> @@ -289,6 +292,8 @@ struct mtk_vcodec_dec_dev {
>   	/* Protects access to vdec_racing_info data */
>   	struct mutex dec_racing_info_mutex;
>   	struct mtk_vcodec_dbgfs dbgfs;
> +
> +	struct mtk_vdec_optee_private *optee_private;
>   };
>   
>   static inline struct mtk_vcodec_dec_ctx *fh_to_dec_ctx(struct v4l2_fh *fh)
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> new file mode 100644
> index 000000000000..3ee9039d2a5b
> --- /dev/null
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Yunfei Dong <yunfei.dong@mediatek.com>
> + */
> +
> +#include "mtk_vcodec_dec_drv.h"
> +#include "mtk_vcodec_dec_optee.h"
> +
> +/*
> + * Randomly generated, and must correspond to the GUID on the TA side.
> + */
> +static const uuid_t mtk_vdec_lat_uuid =
> +	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
> +		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x90);
> +
> +static const uuid_t mtk_vdec_core_uuid =
> +	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
> +		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x91);
> +
> +/*
> + * Check whether this driver supports decoder TA in the TEE instance,
> + * represented by the params (ver/data) of this function.
> + */
> +static int mtk_vcodec_dec_optee_match(struct tee_ioctl_version_data *ver_data, const void *not_used)
> +{
> +	if (ver_data->impl_id == TEE_IMPL_ID_OPTEE)
> +		return 1;
> +	else
> +		return 0;
> +}
> +
> +int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
> +{
> +	vcodec_dev->optee_private = devm_kzalloc(&vcodec_dev->plat_dev->dev,
> +						 sizeof(*vcodec_dev->optee_private),
> +						 GFP_KERNEL);
> +	if (!vcodec_dev->optee_private)
> +		return -ENOMEM;
> +
> +	vcodec_dev->optee_private->vcodec_dev = vcodec_dev;
> +
> +	atomic_set(&vcodec_dev->optee_private->tee_active_cnt, 0);
> +	mutex_init(&vcodec_dev->optee_private->tee_mutex);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
> +
> +static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
> +					     enum mtk_vdec_hw_id hardware_index)
> +{
> +	struct tee_ioctl_open_session_arg session_arg;
> +	struct mtk_vdec_optee_ca_info *ca_info;
> +	int err = 0, session_func;
> +
> +	/* Open lat and core session with vdec TA. */

I assume that anything else than CORE or LAT0 cannot use secure sessions, so...

	switch (hardware_index) {
	case MTK_VDEC_CORE:
		export_uuid
		.....
		break;
	case MTK_VDEC_LAT0:
		export_uuid(...
		......
		break;
	default:
		return -EINVAL;
	}

> +	if (hardware_index == MTK_VDEC_LAT0) {
> +		export_uuid(session_arg.uuid, &mtk_vdec_lat_uuid);
> +		session_func = MTK_VDEC_OPTEE_TA_LAT_SUBMIT_COMMAND;
> +		ca_info = &optee_private->lat_ca;
> +	} else {
> +		export_uuid(session_arg.uuid, &mtk_vdec_core_uuid);
> +		session_func = MTK_VDEC_OPTEE_TA_CORE_SUBMIT_COMMAND;
> +		ca_info = &optee_private->core_ca;
> +	}
> +
> +	session_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
> +	session_arg.num_params = 0;
> +
> +	err = tee_client_open_session(optee_private->tee_vdec_ctx, &session_arg, NULL);
> +	if (err < 0 || session_arg.ret != 0) {
> +		pr_err(MTK_DBG_VCODEC_STR "open vdec tee session failed: hw_id(%d) err=%x.\n",
> +		       hardware_index, session_arg.ret);

Can we use dev_err() please?

> +		return -EINVAL;
> +	}
> +	ca_info->vdec_session_id = session_arg.session;
> +	ca_info->hw_id = hardware_index;
> +	ca_info->vdec_session_func = session_func;
> +
> +	pr_debug(MTK_DBG_VCODEC_STR "open vdec tee session: hw_id(%d) session_id=%x.\n",
> +		 hardware_index, ca_info->vdec_session_id);
> +
> +	return err;
> +}
> +
> +static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *optee_private,
> +						enum mtk_vdec_hw_id hw_id)
> +{
> +	struct mtk_vdec_optee_ca_info *ca_info;
> +
> +	if (hw_id == MTK_VDEC_LAT0)
> +		ca_info = &optee_private->lat_ca;
> +	else
> +		ca_info = &optee_private->core_ca;
> +
> +	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
> +}
> +
> +int mtk_vcodec_dec_optee_open(struct mtk_vdec_optee_private *optee_private)
> +{
> +	int err = 0;

int err; (but I'd prefer this to be called "ret" instead)

> +
> +	mutex_lock(&optee_private->tee_mutex);
> +	if (atomic_inc_return(&optee_private->tee_active_cnt) > 1) {
> +		mutex_unlock(&optee_private->tee_mutex);
> +		pr_debug(MTK_DBG_VCODEC_STR "already init vdec optee private data!\n");

dev_dbg()?

> +		return err;

Did you really want to return 0? In that case, don't return err, but just 0.

> +	}
> +
> +	/* Open context with TEE driver */
> +	optee_private->tee_vdec_ctx = tee_client_open_context(NULL, mtk_vcodec_dec_optee_match,
> +							      NULL, NULL);
> +	if (IS_ERR(optee_private->tee_vdec_ctx)) {
> +		pr_err(MTK_DBG_VCODEC_STR "optee vdec tee context failed.\n");

dev_err()?
		err = PTR_ERR(optee_private->tee_vdec_ctx);
		goto err_ctx_open;
	}
> +		mutex_unlock(&optee_private->tee_mutex);
> +		return -ENODEV;
> +	}
> +
> +	err = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_LAT0);
> +	if (err < 0)
> +		goto err_lat_init;
> +
> +	if (IS_VDEC_LAT_ARCH(optee_private->vcodec_dev->vdec_pdata->hw_arch)) {
> +		err = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_CORE);
> +		if (err < 0)
> +			goto err_core_init;
> +	}
> +
> +	mutex_unlock(&optee_private->tee_mutex);
> +	return 0;
> +err_core_init:
> +	mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_LAT0);
> +err_lat_init:
> +	tee_client_close_context(optee_private->tee_vdec_ctx);
> +

err_ctx_open:

> +	mutex_unlock(&optee_private->tee_mutex);
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_open);
> +

Regards,
Angelo

[PATCH 02/14] media: mediatek: vcodec: allocate tee share memory

[Yunfei Dong]

Allocate two share memory for each lat and core hardware used to share
information with optee-os. Msg buffer used to send ipi command and get ack
command with optee-os, data buffer used to store vsi information which
used for hardware decode.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 79 ++++++++++++++++++-
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     | 32 ++++++++
 2 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
index 3ee9039d2a5b..806ca87c8de7 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -47,12 +47,67 @@ int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
 }
 EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
 
+static void mtk_vcodec_dec_optee_deinit_memref(struct mtk_vdec_optee_ca_info *ca_info,
+					       enum mtk_vdec_optee_data_index data_index)
+{
+	tee_shm_free(ca_info->shm_memref[data_index].msg_shm);
+}
+
+static int mtk_vcodec_dec_optee_init_memref(struct tee_context *tee_vdec_ctx,
+					    struct mtk_vdec_optee_ca_info *ca_info,
+					    enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_shm_memref *shm_memref;
+	int alloc_size = 0, err = 0;
+	u64 shm_param_type = 0;
+	bool copy_buffer;
+
+	if (data_index >= OPTEE_MAX_INDEX) {
+		pr_err(MTK_DBG_VCODEC_STR "tee invalid data_index: %d.\n", data_index);
+		return -EINVAL;
+	} else if (data_index == OPTEE_MSG_INDEX) {
+		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
+		alloc_size = MTK_VDEC_OPTEE_MSG_SIZE;
+		copy_buffer = true;
+	} else {
+		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
+		alloc_size = MTK_VDEC_OPTEE_HW_SIZE;
+		copy_buffer = false;
+	}
+
+	shm_memref = &ca_info->shm_memref[data_index];
+
+	/* Allocate dynamic shared memory with decoder TA */
+	shm_memref->msg_shm_size = alloc_size;
+	shm_memref->param_type = shm_param_type;
+	shm_memref->copy_to_ta = copy_buffer;
+	shm_memref->msg_shm =
+		tee_shm_alloc_kernel_buf(tee_vdec_ctx, shm_memref->msg_shm_size);
+	if (IS_ERR(shm_memref->msg_shm)) {
+		pr_err(MTK_DBG_VCODEC_STR "tee alloc buf fail: data_index:%d.\n", data_index);
+		return -ENOMEM;
+	}
+
+	shm_memref->msg_shm_ca_buf = tee_shm_get_va(shm_memref->msg_shm, 0);
+	if (IS_ERR(shm_memref->msg_shm_ca_buf)) {
+		pr_err(MTK_DBG_VCODEC_STR "tee get shm va fail: data_index:%d.\n", data_index);
+		err = PTR_ERR(shm_memref->msg_shm_ca_buf);
+		goto err_get_msg_va;
+	}
+
+	return err;
+
+err_get_msg_va:
+	tee_shm_free(shm_memref->msg_shm);
+	return err;
+}
+
 static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
 					     enum mtk_vdec_hw_id hardware_index)
 {
 	struct tee_ioctl_open_session_arg session_arg;
 	struct mtk_vdec_optee_ca_info *ca_info;
-	int err = 0, session_func;
+	int err = 0, i = 0, j = 0, session_func;
 
 	/* Open lat and core session with vdec TA. */
 	if (hardware_index == MTK_VDEC_LAT0) {
@@ -81,6 +136,24 @@ static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *opte
 	pr_debug(MTK_DBG_VCODEC_STR "open vdec tee session: hw_id(%d) session_id=%x.\n",
 		 hardware_index, ca_info->vdec_session_id);
 
+	/* Allocate dynamic shared memory with decoder TA */
+	for (; i < OPTEE_MAX_INDEX; i++) {
+		err = mtk_vcodec_dec_optee_init_memref(optee_private->tee_vdec_ctx, ca_info, i);
+		if (err) {
+			pr_err(MTK_DBG_VCODEC_STR "init vdec memref failed: %d.\n", i);
+			goto err_init_memref;
+		}
+	}
+
+	return err;
+err_init_memref:
+	if (i != 0) {
+		for (; j < i; j++)
+			mtk_vcodec_dec_optee_deinit_memref(ca_info, j);
+	}
+
+	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
+
 	return err;
 }
 
@@ -88,12 +161,16 @@ static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *o
 						enum mtk_vdec_hw_id hw_id)
 {
 	struct mtk_vdec_optee_ca_info *ca_info;
+	int i = 0;
 
 	if (hw_id == MTK_VDEC_LAT0)
 		ca_info = &optee_private->lat_ca;
 	else
 		ca_info = &optee_private->core_ca;
 
+	for (; i < OPTEE_MAX_INDEX; i++)
+		mtk_vcodec_dec_optee_deinit_memref(ca_info, i);
+
 	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
 }
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
index 8b1dca49331e..79b4ec890655 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -18,16 +18,48 @@
 
 #define MTK_OPTEE_MAX_TEE_PARAMS 4
 
+#define MTK_VDEC_OPTEE_MSG_SIZE     128
+#define MTK_VDEC_OPTEE_HW_SIZE      (8 * SZ_1K)
+
+/**
+ * struct mtk_vdec_optee_shm_memref - share memory reference params
+ * @msg_shm:        message shared with TA in TEE.
+ * @msg_shm_ca_buf: ca buffer.
+ *
+ * @msg_shm_size:   share message size.
+ * @param_type:     each tee param types.
+ * @copy_to_ta:     need to copy data from ca to share memory.
+ */
+struct mtk_vdec_optee_shm_memref {
+	struct tee_shm *msg_shm;
+	u8 *msg_shm_ca_buf;
+
+	u32 msg_shm_size;
+	u64 param_type;
+	bool copy_to_ta;
+};
+
 /**
  * struct mtk_vdec_optee_ca_info - ca related param
  * @vdec_session_id:   optee TA session identifier.
  * @hw_id:             hardware index.
  * @vdec_session_func: trusted application function id used specific to the TA.
+ * @shm_memref:        share memory reference params.
  */
 struct mtk_vdec_optee_ca_info {
 	u32 vdec_session_id;
 	enum mtk_vdec_hw_id hw_id;
 	u32 vdec_session_func;
+	struct mtk_vdec_optee_shm_memref shm_memref[MTK_OPTEE_MAX_TEE_PARAMS];
+};
+
+/*
+ * enum mtk_vdec_optee_data_index - used to indentify each share memory informaiton
+ */
+enum mtk_vdec_optee_data_index {
+	OPTEE_MSG_INDEX = 0,
+	OPTEE_DATA_INDEX,
+	OPTEE_MAX_INDEX,
 };
 
 /**
-- 
2.18.0

Re: [PATCH 02/14] media: mediatek: vcodec: allocate tee share memory

[AngeloGioacchino Del Regno]

Il 11/09/23 14:59, Yunfei Dong ha scritto:
> Allocate two share memory for each lat and core hardware used to share
> information with optee-os. Msg buffer used to send ipi command and get ack
> command with optee-os, data buffer used to store vsi information which
> used for hardware decode.
> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>   .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 79 ++++++++++++++++++-
>   .../vcodec/decoder/mtk_vcodec_dec_optee.h     | 32 ++++++++
>   2 files changed, 110 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> index 3ee9039d2a5b..806ca87c8de7 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> @@ -47,12 +47,67 @@ int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
>   }
>   EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
>   
> +static void mtk_vcodec_dec_optee_deinit_memref(struct mtk_vdec_optee_ca_info *ca_info,
> +					       enum mtk_vdec_optee_data_index data_index)
> +{
> +	tee_shm_free(ca_info->shm_memref[data_index].msg_shm);
> +}
> +
> +static int mtk_vcodec_dec_optee_init_memref(struct tee_context *tee_vdec_ctx,
> +					    struct mtk_vdec_optee_ca_info *ca_info,
> +					    enum mtk_vdec_optee_data_index data_index)
> +{
> +	struct mtk_vdec_optee_shm_memref *shm_memref;
> +	int alloc_size = 0, err = 0;
> +	u64 shm_param_type = 0;
> +	bool copy_buffer;
> +
> +	if (data_index >= OPTEE_MAX_INDEX) {
> +		pr_err(MTK_DBG_VCODEC_STR "tee invalid data_index: %d.\n", data_index);
> +		return -EINVAL;
> +	} else if (data_index == OPTEE_MSG_INDEX) {
> +		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
> +		alloc_size = MTK_VDEC_OPTEE_MSG_SIZE;
> +		copy_buffer = true;
> +	} else {
> +		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
> +		alloc_size = MTK_VDEC_OPTEE_HW_SIZE;
> +		copy_buffer = false;
> +	}

This is another good usecase for a switch.

	switch (data_index) {
	case OPTEE_MSG_INDEX:
		......
	case OPTEE_DATA_INDEX:
		......
	default:
		invalid data_index; return....
	}

> +
> +	shm_memref = &ca_info->shm_memref[data_index];
> +
> +	/* Allocate dynamic shared memory with decoder TA */
> +	shm_memref->msg_shm_size = alloc_size;
> +	shm_memref->param_type = shm_param_type;
> +	shm_memref->copy_to_ta = copy_buffer;
> +	shm_memref->msg_shm =
> +		tee_shm_alloc_kernel_buf(tee_vdec_ctx, shm_memref->msg_shm_size);

That'd be 96 columns, one line is ok.

> +	if (IS_ERR(shm_memref->msg_shm)) {
> +		pr_err(MTK_DBG_VCODEC_STR "tee alloc buf fail: data_index:%d.\n", data_index);
> +		return -ENOMEM;
> +	}
> +
> +	shm_memref->msg_shm_ca_buf = tee_shm_get_va(shm_memref->msg_shm, 0);
> +	if (IS_ERR(shm_memref->msg_shm_ca_buf)) {
> +		pr_err(MTK_DBG_VCODEC_STR "tee get shm va fail: data_index:%d.\n", data_index);
> +		err = PTR_ERR(shm_memref->msg_shm_ca_buf);
> +		goto err_get_msg_va;
> +	}
> +
> +	return err;
> +
> +err_get_msg_va:
> +	tee_shm_free(shm_memref->msg_shm);
> +	return err;
> +}
> +
>   static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
>   					     enum mtk_vdec_hw_id hardware_index)
>   {
>   	struct tee_ioctl_open_session_arg session_arg;
>   	struct mtk_vdec_optee_ca_info *ca_info;
> -	int err = 0, session_func;
> +	int err = 0, i = 0, j = 0, session_func;

Please don't initialize `i` and `j` here, you can do that in the for loop as
per common practice.

>   
>   	/* Open lat and core session with vdec TA. */
>   	if (hardware_index == MTK_VDEC_LAT0) {
> @@ -81,6 +136,24 @@ static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *opte
>   	pr_debug(MTK_DBG_VCODEC_STR "open vdec tee session: hw_id(%d) session_id=%x.\n",
>   		 hardware_index, ca_info->vdec_session_id);
>   
> +	/* Allocate dynamic shared memory with decoder TA */
> +	for (; i < OPTEE_MAX_INDEX; i++) {
> +		err = mtk_vcodec_dec_optee_init_memref(optee_private->tee_vdec_ctx, ca_info, i);
> +		if (err) {
> +			pr_err(MTK_DBG_VCODEC_STR "init vdec memref failed: %d.\n", i);
> +			goto err_init_memref;
> +		}
> +	}
> +
> +	return err;
> +err_init_memref:
> +	if (i != 0) {
> +		for (; j < i; j++)
> +			mtk_vcodec_dec_optee_deinit_memref(ca_info, j);
> +	}
> +
> +	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
> +
>   	return err;
>   }
>   
> @@ -88,12 +161,16 @@ static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *o
>   						enum mtk_vdec_hw_id hw_id)
>   {
>   	struct mtk_vdec_optee_ca_info *ca_info;
> +	int i = 0;

int i;

>   
>   	if (hw_id == MTK_VDEC_LAT0)
>   		ca_info = &optee_private->lat_ca;
>   	else
>   		ca_info = &optee_private->core_ca;
>   
> +	for (; i < OPTEE_MAX_INDEX; i++)

for (i = 0; i < OPTEE_MAX_INDEX; i++)

> +		mtk_vcodec_dec_optee_deinit_memref(ca_info, i);
> +
>   	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
>   }
>   
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
> index 8b1dca49331e..79b4ec890655 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
> @@ -18,16 +18,48 @@
>   
>   #define MTK_OPTEE_MAX_TEE_PARAMS 4
>   
> +#define MTK_VDEC_OPTEE_MSG_SIZE     128
> +#define MTK_VDEC_OPTEE_HW_SIZE      (8 * SZ_1K)
> +
> +/**
> + * struct mtk_vdec_optee_shm_memref - share memory reference params
> + * @msg_shm:        message shared with TA in TEE.
> + * @msg_shm_ca_buf: ca buffer.
> + *
> + * @msg_shm_size:   share message size.
> + * @param_type:     each tee param types.
> + * @copy_to_ta:     need to copy data from ca to share memory.
> + */
> +struct mtk_vdec_optee_shm_memref {
> +	struct tee_shm *msg_shm;
> +	u8 *msg_shm_ca_buf;
> +
> +	u32 msg_shm_size;
> +	u64 param_type;
> +	bool copy_to_ta;
> +};
> +
>   /**
>    * struct mtk_vdec_optee_ca_info - ca related param
>    * @vdec_session_id:   optee TA session identifier.
>    * @hw_id:             hardware index.
>    * @vdec_session_func: trusted application function id used specific to the TA.
> + * @shm_memref:        share memory reference params.
>    */
>   struct mtk_vdec_optee_ca_info {
>   	u32 vdec_session_id;
>   	enum mtk_vdec_hw_id hw_id;
>   	u32 vdec_session_func;
> +	struct mtk_vdec_optee_shm_memref shm_memref[MTK_OPTEE_MAX_TEE_PARAMS];
> +};
> +
> +/*
> + * enum mtk_vdec_optee_data_index - used to indentify each share memory informaiton

Typo: informaiton -> information

> + */
> +enum mtk_vdec_optee_data_index {
> +	OPTEE_MSG_INDEX = 0,
> +	OPTEE_DATA_INDEX,
> +	OPTEE_MAX_INDEX,
>   };
>   
>   /**

Regards,
Angelo

[PATCH 03/14] media: mediatek: vcodec: send share memory data to optee

[Yunfei Dong]

Setting msg and vsi information to shared buffer, then call tee invoke
function to send it to optee-os.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 139 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  51 +++++++
 2 files changed, 190 insertions(+)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
index 806ca87c8de7..d16496003a39 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -232,3 +232,142 @@ void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private)
 	mutex_unlock(&optee_private->tee_mutex);
 }
 EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_release);
+
+static int mtk_vcodec_dec_optee_fill_shm(struct tee_param *command_params,
+					 struct mtk_vdec_optee_shm_memref *shm_memref,
+					 struct mtk_vdec_optee_data_to_shm *data,
+					 int index)
+{
+	if (!data->msg_buf_size[index] || !data->msg_buf[index]) {
+		pr_err(MTK_DBG_VCODEC_STR "tee invalid buf param: %d.\n", index);
+		return -EINVAL;
+	}
+
+	*command_params = (struct tee_param) {
+		.attr = shm_memref->param_type,
+		.u.memref = {
+			.shm = shm_memref->msg_shm,
+			.size = data->msg_buf_size[index],
+			.shm_offs = 0,
+		},
+	};
+
+	if (!shm_memref->copy_to_ta) {
+		pr_debug(MTK_DBG_VCODEC_STR "share memref data: 0x%x param_type:%llu.\n",
+			 *((unsigned int *)shm_memref->msg_shm_ca_buf), shm_memref->param_type);
+		return 0;
+	}
+
+	memset(shm_memref->msg_shm_ca_buf, 0, shm_memref->msg_shm_size);
+	memcpy(shm_memref->msg_shm_ca_buf, data->msg_buf[index], data->msg_buf_size[index]);
+
+	pr_debug(MTK_DBG_VCODEC_STR "share memref data => msg id:0x%x 0x%x param_type:%llu.\n",
+		 *((unsigned int *)data->msg_buf[index]),
+		 *((unsigned int *)shm_memref->msg_shm_ca_buf),
+		 shm_memref->param_type);
+
+	return 0;
+}
+
+void mtk_vcodec_dec_optee_set_data(struct mtk_vdec_optee_data_to_shm *data,
+				   void *buf, int buf_size,
+				   enum mtk_vdec_optee_data_index index)
+{
+	data->msg_buf[index] = buf;
+	data->msg_buf_size[index] = buf_size;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_set_data);
+
+int mtk_vcodec_dec_optee_invokd_cmd(struct mtk_vdec_optee_private *optee_private,
+				    enum mtk_vdec_hw_id hw_id,
+				    struct mtk_vdec_optee_data_to_shm *data)
+{
+	struct tee_ioctl_invoke_arg trans_args;
+	struct tee_param command_params[MTK_OPTEE_MAX_TEE_PARAMS];
+	struct mtk_vdec_optee_ca_info *ca_info;
+	struct mtk_vdec_optee_shm_memref *shm_memref;
+	int ret = 0, index;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	memset(&trans_args, 0, sizeof(trans_args));
+	memset(command_params, 0, sizeof(command_params));
+
+	trans_args = (struct tee_ioctl_invoke_arg) {
+		.func = ca_info->vdec_session_func,
+		.session = ca_info->vdec_session_id,
+		.num_params = MTK_OPTEE_MAX_TEE_PARAMS,
+	};
+
+	/* Fill msg command parameters */
+	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
+		shm_memref = &ca_info->shm_memref[index];
+
+		if (shm_memref->param_type == TEE_IOCTL_PARAM_ATTR_TYPE_NONE ||
+		    data->msg_buf_size[index] == 0)
+			continue;
+
+		pr_debug(MTK_DBG_VCODEC_STR "tee share memory data size: %d -> %d.\n",
+			 data->msg_buf_size[index], shm_memref->msg_shm_size);
+
+		if (data->msg_buf_size[index] > shm_memref->msg_shm_size) {
+			pr_err(MTK_DBG_VCODEC_STR "tee buf size big then shm size(%d -> %d).\n",
+			       data->msg_buf_size[index], shm_memref->msg_shm_size);
+			return -EINVAL;
+		}
+
+		ret = mtk_vcodec_dec_optee_fill_shm(&command_params[index], shm_memref,
+						    data, index);
+		if (ret)
+			return ret;
+	}
+
+	ret = tee_client_invoke_func(optee_private->tee_vdec_ctx, &trans_args, command_params);
+	if (ret < 0 || trans_args.ret != 0) {
+		pr_err(MTK_DBG_VCODEC_STR "tee submit command fail: 0x%x 0x%x.\n",
+		       trans_args.ret, ret);
+		return (ret < 0) ? ret : trans_args.ret;
+	}
+
+	/* clear all attrs, set all command param to unused */
+	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
+		data->msg_buf[index] = NULL;
+		data->msg_buf_size[index] = 0;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_invokd_cmd);
+
+void *mtk_vcodec_dec_get_shm_buffer_va(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	return ca_info->shm_memref[data_index].msg_shm_ca_buf;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_get_shm_buffer_va);
+
+int mtk_vcodec_dec_get_shm_buffer_size(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	return ca_info->shm_memref[data_index].msg_shm_size;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_get_shm_buffer_size);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
index 79b4ec890655..3905db856376 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -62,6 +62,16 @@ enum mtk_vdec_optee_data_index {
 	OPTEE_MAX_INDEX,
 };
 
+/**
+ * struct mtk_vdec_optee_data_to_shm - shm data used for TA
+ * @msg_buf:     msg information to TA.
+ * @msg_buf_len: length of msg information.
+ */
+struct mtk_vdec_optee_data_to_shm {
+	void *msg_buf[MTK_OPTEE_MAX_TEE_PARAMS];
+	int msg_buf_size[MTK_OPTEE_MAX_TEE_PARAMS];
+};
+
 /**
  * struct mtk_vdec_optee_private - optee private data
  * @vcodec_dev:     pointer to the mtk_vcodec_dev of the device
@@ -102,4 +112,45 @@ int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev);
  */
 void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private);
 
+/**
+ * mtk_vcodec_dec_optee_set_data - set buffer to share memref.
+ * @vcodec_dev: normal world data used to init optee share memory
+ * @buf: normal world buffer address
+ * @buf_size: buf size
+ * @data_index: indentify each share memory informaiton
+ */
+void mtk_vcodec_dec_optee_set_data(struct mtk_vdec_optee_data_to_shm *data,
+				   void *buf, int buf_size,
+				   enum mtk_vdec_optee_data_index data_index);
+
+/**
+ * mtk_vcodec_dec_optee_invokd_cmd - send share memory data to optee .
+ * @optee_private: optee private context
+ * @hw_id: hardware index
+ * @data: normal world data used to init optee share memory
+ */
+int mtk_vcodec_dec_optee_invokd_cmd(struct mtk_vdec_optee_private *optee_private,
+				    enum mtk_vdec_hw_id hw_id,
+				    struct mtk_vdec_optee_data_to_shm *data);
+
+/**
+ * mtk_vcodec_dec_get_shm_buffer_va - close the communication channels with TA.
+ * @optee_private: optee private context
+ * @hw_id:         hardware index
+ * @@data_index: indentify each share memory informaiton
+ */
+void *mtk_vcodec_dec_get_shm_buffer_va(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index);
+
+/**
+ * mtk_vcodec_dec_get_shm_buffer_size - close the communication channels with TA.
+ * @optee_private: optee private context
+ * @hw_id:         hardware index
+ * @@data_index: indentify each share memory informaiton
+ */
+int mtk_vcodec_dec_get_shm_buffer_size(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index);
+
 #endif /* _MTK_VCODEC_FW_OPTEE_H_ */
-- 
2.18.0

Re: [PATCH 03/14] media: mediatek: vcodec: send share memory data to optee

[AngeloGioacchino Del Regno]

Il 11/09/23 14:59, Yunfei Dong ha scritto:
> Setting msg and vsi information to shared buffer, then call tee invoke
> function to send it to optee-os.
> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>   .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 139 ++++++++++++++++++
>   .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  51 +++++++
>   2 files changed, 190 insertions(+)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> index 806ca87c8de7..d16496003a39 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
> @@ -232,3 +232,142 @@ void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private)
>   	mutex_unlock(&optee_private->tee_mutex);
>   }
>   EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_release);
> +
> +static int mtk_vcodec_dec_optee_fill_shm(struct tee_param *command_params,
> +					 struct mtk_vdec_optee_shm_memref *shm_memref,
> +					 struct mtk_vdec_optee_data_to_shm *data,
> +					 int index)
> +{
> +	if (!data->msg_buf_size[index] || !data->msg_buf[index]) {
> +		pr_err(MTK_DBG_VCODEC_STR "tee invalid buf param: %d.\n", index);
> +		return -EINVAL;
> +	}
> +
> +	*command_params = (struct tee_param) {
> +		.attr = shm_memref->param_type,
> +		.u.memref = {
> +			.shm = shm_memref->msg_shm,
> +			.size = data->msg_buf_size[index],
> +			.shm_offs = 0,
> +		},
> +	};
> +
> +	if (!shm_memref->copy_to_ta) {
> +		pr_debug(MTK_DBG_VCODEC_STR "share memref data: 0x%x param_type:%llu.\n",
> +			 *((unsigned int *)shm_memref->msg_shm_ca_buf), shm_memref->param_type);
> +		return 0;
> +	}
> +
> +	memset(shm_memref->msg_shm_ca_buf, 0, shm_memref->msg_shm_size);
> +	memcpy(shm_memref->msg_shm_ca_buf, data->msg_buf[index], data->msg_buf_size[index]);
> +
> +	pr_debug(MTK_DBG_VCODEC_STR "share memref data => msg id:0x%x 0x%x param_type:%llu.\n",
> +		 *((unsigned int *)data->msg_buf[index]),
> +		 *((unsigned int *)shm_memref->msg_shm_ca_buf),
> +		 shm_memref->param_type);

dev_dbg()?

> +
> +	return 0;
> +}
> +
> +void mtk_vcodec_dec_optee_set_data(struct mtk_vdec_optee_data_to_shm *data,
> +				   void *buf, int buf_size,
> +				   enum mtk_vdec_optee_data_index index)
> +{
> +	data->msg_buf[index] = buf;
> +	data->msg_buf_size[index] = buf_size;
> +}
> +EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_set_data);
> +
> +int mtk_vcodec_dec_optee_invokd_cmd(struct mtk_vdec_optee_private *optee_private,
> +				    enum mtk_vdec_hw_id hw_id,
> +				    struct mtk_vdec_optee_data_to_shm *data)
> +{
> +	struct tee_ioctl_invoke_arg trans_args;
> +	struct tee_param command_params[MTK_OPTEE_MAX_TEE_PARAMS];
> +	struct mtk_vdec_optee_ca_info *ca_info;
> +	struct mtk_vdec_optee_shm_memref *shm_memref;
> +	int ret = 0, index;

int i, ret;

> +
> +	if (hw_id == MTK_VDEC_LAT0)
> +		ca_info = &optee_private->lat_ca;
> +	else
> +		ca_info = &optee_private->core_ca;
> +
> +	memset(&trans_args, 0, sizeof(trans_args));
> +	memset(command_params, 0, sizeof(command_params));
> +
> +	trans_args = (struct tee_ioctl_invoke_arg) {
> +		.func = ca_info->vdec_session_func,
> +		.session = ca_info->vdec_session_id,
> +		.num_params = MTK_OPTEE_MAX_TEE_PARAMS,
> +	};
> +
> +	/* Fill msg command parameters */
> +	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
> +		shm_memref = &ca_info->shm_memref[index];
> +
> +		if (shm_memref->param_type == TEE_IOCTL_PARAM_ATTR_TYPE_NONE ||
> +		    data->msg_buf_size[index] == 0)
> +			continue;
> +
> +		pr_debug(MTK_DBG_VCODEC_STR "tee share memory data size: %d -> %d.\n",
> +			 data->msg_buf_size[index], shm_memref->msg_shm_size);
> +

dev_dbg()

> +		if (data->msg_buf_size[index] > shm_memref->msg_shm_size) {
> +			pr_err(MTK_DBG_VCODEC_STR "tee buf size big then shm size(%d -> %d).\n",
> +			       data->msg_buf_size[index], shm_memref->msg_shm_size);

dev_err()

> +			return -EINVAL;
> +		}
> +
> +		ret = mtk_vcodec_dec_optee_fill_shm(&command_params[index], shm_memref,
> +						    data, index);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	ret = tee_client_invoke_func(optee_private->tee_vdec_ctx, &trans_args, command_params);
> +	if (ret < 0 || trans_args.ret != 0) {
> +		pr_err(MTK_DBG_VCODEC_STR "tee submit command fail: 0x%x 0x%x.\n",
> +		       trans_args.ret, ret);

dev_err()

> +		return (ret < 0) ? ret : trans_args.ret;
> +	}
> +
> +	/* clear all attrs, set all command param to unused */
> +	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
> +		data->msg_buf[index] = NULL;
> +		data->msg_buf_size[index] = 0;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_invokd_cmd);
> +

Regards,
Angelo

[PATCH 04/14] media: mediatek: vcodec: initialize msg and vsi information

[Yunfei Dong]

Need to initialize msg and vsi information before sending to optee-os, then
calling optee invoke command to send the information to optee-os.

For the optee communication interface is different with scp, using
flag to separate them.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |  2 +
 .../mediatek/vcodec/decoder/vdec_vpu_if.c     | 46 ++++++++++++++++---
 .../mediatek/vcodec/decoder/vdec_vpu_if.h     |  4 ++
 3 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
index 061542c3852c..20e534151f69 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
@@ -165,6 +165,7 @@ struct mtk_vcodec_dec_pdata {
  * @vpu_inst: vpu instance pointer.
  *
  * @is_10bit_bitstream: set to true if it's 10bit bitstream
+ * @is_svp_mode: secure video playback
  */
 struct mtk_vcodec_dec_ctx {
 	enum mtk_instance_type type;
@@ -210,6 +211,7 @@ struct mtk_vcodec_dec_ctx {
 	void *vpu_inst;
 
 	bool is_10bit_bitstream;
+	bool is_svp_mode;
 };
 
 /**
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index 82e57ae983d5..c1a1bddf99d8 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -148,7 +148,10 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len, void *priv)
 
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 {
-	int err, id, msgid;
+	int err, id, hw_id, msgid;
+	struct mtk_vdec_optee_data_to_shm *optee_data;
+	void *ack_msg, *data_msg;
+	int data_size;
 
 	msgid = *(uint32_t *)msg;
 	mtk_vdec_debug(vpu->ctx, "id=%X", msgid);
@@ -158,16 +161,46 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 
 	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
 		if (msgid == AP_IPIMSG_DEC_CORE ||
-		    msgid == AP_IPIMSG_DEC_CORE_END)
+		    msgid == AP_IPIMSG_DEC_CORE_END) {
+			optee_data = &vpu->core_optee_info;
 			id = vpu->core_id;
-		else
+		} else {
+			optee_data = &vpu->lat_optee_info;
 			id = vpu->id;
+		}
 	} else {
+		optee_data = &vpu->lat_optee_info;
 		id = vpu->id;
 	}
 
-	err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
-				     len, 2000);
+	if (!vpu->ctx->is_svp_mode) {
+		err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg, len, 2000);
+	} else {
+		hw_id = (id == SCP_IPI_VDEC_LAT) ? MTK_VDEC_LAT0 : MTK_VDEC_CORE;
+
+		mtk_vcodec_dec_optee_set_data(optee_data, msg, len, OPTEE_MSG_INDEX);
+
+		/* No need copy data(vsi) msg to share memory, set the buffer size to non zero
+		 * value.
+		 */
+		if (msgid == AP_IPIMSG_DEC_CORE || msgid == AP_IPIMSG_DEC_START) {
+			data_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private,
+								    hw_id, OPTEE_DATA_INDEX);
+			data_size = mtk_vcodec_dec_get_shm_buffer_size(vpu->ctx->dev->optee_private,
+								       hw_id, OPTEE_DATA_INDEX);
+			mtk_vcodec_dec_optee_set_data(optee_data, data_msg, data_size,
+						      OPTEE_DATA_INDEX);
+		}
+
+		err = mtk_vcodec_dec_optee_invokd_cmd(vpu->ctx->dev->optee_private,
+						      hw_id, optee_data);
+		vpu->failure = err;
+
+		ack_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private, hw_id,
+							   OPTEE_MSG_INDEX);
+		vpu_dec_ipi_handler(ack_msg, 0, vpu->ctx->dev);
+	}
+
 	if (err) {
 		mtk_vdec_err(vpu->ctx, "send fail vpu_id=%d msg_id=%X status=%d",
 			     id, msgid, err);
@@ -213,7 +246,8 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
 		return err;
 	}
 
-	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE &&
+	    !vpu->ctx->is_svp_mode) {
 		err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
 						 vpu->core_id, vpu->handler,
 						 "vdec", vpu->ctx->dev);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
index fbb3f34a73f0..946e5abcc7d3 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
@@ -28,6 +28,8 @@ struct mtk_vcodec_dec_ctx;
  * @codec_type     : use codec type to separate different codecs
  * @capture_type:	used capture type to separate different capture format
  * @fb_sz  : frame buffer size of each plane
+ * @lat_optee_info  : used to send msg to optee shm buffer
+ * @core_optee_info  : used to send msg to optee shm buffer
  */
 struct vdec_vpu_inst {
 	int id;
@@ -44,6 +46,8 @@ struct vdec_vpu_inst {
 	unsigned int codec_type;
 	unsigned int capture_type;
 	unsigned int fb_sz[2];
+	struct mtk_vdec_optee_data_to_shm lat_optee_info;
+	struct mtk_vdec_optee_data_to_shm core_optee_info;
 };
 
 /**
-- 
2.18.0

Re: [PATCH 04/14] media: mediatek: vcodec: initialize msg and vsi information

[AngeloGioacchino Del Regno]

Il 11/09/23 14:59, Yunfei Dong ha scritto:
> Need to initialize msg and vsi information before sending to optee-os, then
> calling optee invoke command to send the information to optee-os.
> 
> For the optee communication interface is different with scp, using
> flag to separate them.
> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>   .../vcodec/decoder/mtk_vcodec_dec_drv.h       |  2 +
>   .../mediatek/vcodec/decoder/vdec_vpu_if.c     | 46 ++++++++++++++++---
>   .../mediatek/vcodec/decoder/vdec_vpu_if.h     |  4 ++
>   3 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> index 061542c3852c..20e534151f69 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
> @@ -165,6 +165,7 @@ struct mtk_vcodec_dec_pdata {
>    * @vpu_inst: vpu instance pointer.
>    *
>    * @is_10bit_bitstream: set to true if it's 10bit bitstream
> + * @is_svp_mode: secure video playback
>    */
>   struct mtk_vcodec_dec_ctx {
>   	enum mtk_instance_type type;
> @@ -210,6 +211,7 @@ struct mtk_vcodec_dec_ctx {
>   	void *vpu_inst;
>   
>   	bool is_10bit_bitstream;
> +	bool is_svp_mode;

This looks clearer:

@is_secure_playback: Secure Video Playback (SVP) mode

bool is_secure_playback;

>   };
>   
>   /**
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> index 82e57ae983d5..c1a1bddf99d8 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> @@ -148,7 +148,10 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len, void *priv)
>   
>   static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
>   {
> -	int err, id, msgid;
> +	int err, id, hw_id, msgid;
> +	struct mtk_vdec_optee_data_to_shm *optee_data;
> +	void *ack_msg, *data_msg;
> +	int data_size;

	struct mtk_vdec_optee_data_to_shm *optee_data;
	int data_size, id, hw_id, msgid;
	void *ack_msg, *data_msg;
	int err;

>   
>   	msgid = *(uint32_t *)msg;
>   	mtk_vdec_debug(vpu->ctx, "id=%X", msgid);
> @@ -158,16 +161,46 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
>   
>   	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
>   		if (msgid == AP_IPIMSG_DEC_CORE ||
> -		    msgid == AP_IPIMSG_DEC_CORE_END)
> +		    msgid == AP_IPIMSG_DEC_CORE_END) {
> +			optee_data = &vpu->core_optee_info;
>   			id = vpu->core_id;
> -		else
> +		} else {
> +			optee_data = &vpu->lat_optee_info;
>   			id = vpu->id;
> +		}
>   	} else {
> +		optee_data = &vpu->lat_optee_info;
>   		id = vpu->id;
>   	}
>   
> -	err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
> -				     len, 2000);
> +	if (!vpu->ctx->is_svp_mode) {
> +		err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg, len, 2000);
> +	} else {
> +		hw_id = (id == SCP_IPI_VDEC_LAT) ? MTK_VDEC_LAT0 : MTK_VDEC_CORE;
> +
> +		mtk_vcodec_dec_optee_set_data(optee_data, msg, len, OPTEE_MSG_INDEX);
> +
> +		/* No need copy data(vsi) msg to share memory, set the buffer size to non zero
> +		 * value.
> +		 */

/*
  * There is no need to copy the data (VSI) message to shared memory,
  * but we still need to set the buffer size to a non-zero value.
  */

> +		if (msgid == AP_IPIMSG_DEC_CORE || msgid == AP_IPIMSG_DEC_START) {
> +			data_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private,
> +								    hw_id, OPTEE_DATA_INDEX);
> +			data_size = mtk_vcodec_dec_get_shm_buffer_size(vpu->ctx->dev->optee_private,
> +								       hw_id, OPTEE_DATA_INDEX);
> +			mtk_vcodec_dec_optee_set_data(optee_data, data_msg, data_size,
> +						      OPTEE_DATA_INDEX);
> +		}
> +
> +		err = mtk_vcodec_dec_optee_invokd_cmd(vpu->ctx->dev->optee_private,
> +						      hw_id, optee_data);
> +		vpu->failure = err;
> +
> +		ack_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private, hw_id,
> +							   OPTEE_MSG_INDEX);
> +		vpu_dec_ipi_handler(ack_msg, 0, vpu->ctx->dev);
> +	}
> +
>   	if (err) {
>   		mtk_vdec_err(vpu->ctx, "send fail vpu_id=%d msg_id=%X status=%d",
>   			     id, msgid, err);
> @@ -213,7 +246,8 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
>   		return err;
>   	}
>   
> -	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
> +	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE &&
> +	    !vpu->ctx->is_svp_mode) {

Please add a comment explaining why no fw_ipi is necessary here for SVP.

Regards,
Angelo

>   		err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
>   						 vpu->core_id, vpu->handler,
>   						 "vdec", vpu->ctx->dev);
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
> index fbb3f34a73f0..946e5abcc7d3 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
> @@ -28,6 +28,8 @@ struct mtk_vcodec_dec_ctx;
>    * @codec_type     : use codec type to separate different codecs
>    * @capture_type:	used capture type to separate different capture format
>    * @fb_sz  : frame buffer size of each plane
> + * @lat_optee_info  : used to send msg to optee shm buffer
> + * @core_optee_info  : used to send msg to optee shm buffer
>    */
>   struct vdec_vpu_inst {
>   	int id;
> @@ -44,6 +46,8 @@ struct vdec_vpu_inst {
>   	unsigned int codec_type;
>   	unsigned int capture_type;
>   	unsigned int fb_sz[2];
> +	struct mtk_vdec_optee_data_to_shm lat_optee_info;
> +	struct mtk_vdec_optee_data_to_shm core_optee_info;
>   };
>   
>   /**

[PATCH 05/14] media: mediatek: vcodec: using encoder's device to alloc/free memory

[Yunfei Dong]

Using encoder's device to allocate/free secure memory calling:
mtk_vcodec_mem_alloc/mtk_vcodec_mem_free, not decoder's.

'Fixes: 01abf5fbb081c ("media: mediatek: vcodec: separate struct 'mtk_vcodec_ctx'")'
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 66 ++++++++++++++++++-
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 908602031fd0..62bb7290c56d 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -45,7 +45,7 @@ int mtk_vcodec_write_vdecsys(struct mtk_vcodec_dec_ctx *ctx, unsigned int reg,
 }
 EXPORT_SYMBOL(mtk_vcodec_write_vdecsys);
 
-int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
+static int mtk_vcodec_mem_dec_alloc(void *priv, struct mtk_vcodec_mem *mem)
 {
 	unsigned long size = mem->size;
 	struct mtk_vcodec_dec_ctx *ctx = priv;
@@ -64,9 +64,39 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 
 	return 0;
 }
+
+static int mtk_vcodec_mem_enc_alloc(void *priv, struct mtk_vcodec_mem *mem)
+{
+	unsigned long size = mem->size;
+	struct mtk_vcodec_enc_ctx *ctx = priv;
+	struct device *dev = &ctx->dev->plat_dev->dev;
+
+	mem->va = dma_alloc_coherent(dev, size, &mem->dma_addr, GFP_KERNEL);
+	if (!mem->va) {
+		mtk_v4l2_venc_err(ctx, "%s dma_alloc size=%ld failed!", dev_name(dev), size);
+		return -ENOMEM;
+	}
+
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]  - va      = %p", ctx->id, mem->va);
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]  - dma     = 0x%lx", ctx->id,
+			  (unsigned long)mem->dma_addr);
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]    size = 0x%lx", ctx->id, size);
+
+	return 0;
+}
+
+int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
+{
+	enum mtk_instance_type inst_type = *((unsigned int *)priv);
+
+	if (inst_type == MTK_INST_ENCODER)
+		return mtk_vcodec_mem_enc_alloc(priv, mem);
+	else
+		return mtk_vcodec_mem_dec_alloc(priv, mem);
+}
 EXPORT_SYMBOL(mtk_vcodec_mem_alloc);
 
-void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
+static void mtk_vcodec_mem_dec_free(void *priv, struct mtk_vcodec_mem *mem)
 {
 	unsigned long size = mem->size;
 	struct mtk_vcodec_dec_ctx *ctx = priv;
@@ -87,6 +117,38 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 	mem->dma_addr = 0;
 	mem->size = 0;
 }
+
+static void mtk_vcodec_mem_enc_free(void *priv, struct mtk_vcodec_mem *mem)
+{
+	unsigned long size = mem->size;
+	struct mtk_vcodec_enc_ctx *ctx = priv;
+	struct device *dev = &ctx->dev->plat_dev->dev;
+
+	if (!mem->va) {
+		mtk_v4l2_venc_err(ctx, "%s dma_free size=%ld failed!", dev_name(dev), size);
+		return;
+	}
+
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]  - va      = %p", ctx->id, mem->va);
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]  - dma     = 0x%lx", ctx->id,
+			  (unsigned long)mem->dma_addr);
+	mtk_v4l2_venc_dbg(3, ctx, "[%d]    size = 0x%lx", ctx->id, size);
+
+	dma_free_coherent(dev, size, mem->va, mem->dma_addr);
+	mem->va = NULL;
+	mem->dma_addr = 0;
+	mem->size = 0;
+}
+
+void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
+{
+	enum mtk_instance_type inst_type = *((unsigned int *)priv);
+
+	if (inst_type == MTK_INST_ENCODER)
+		mtk_vcodec_mem_enc_free(priv, mem);
+	else
+		mtk_vcodec_mem_dec_free(priv, mem);
+}
 EXPORT_SYMBOL(mtk_vcodec_mem_free);
 
 void *mtk_vcodec_get_hw_dev(struct mtk_vcodec_dec_dev *dev, int hw_idx)
-- 
2.18.0

[PATCH 06/14] media: mediatek: vcodec: add interface to allocate/free secure memory

[Yunfei Dong]

Need to call dma heap interface to allocate/free secure memory when playing
secure video.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../media/platform/mediatek/vcodec/Kconfig    |   1 +
 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 123 ++++++++++++++++--
 .../mediatek/vcodec/common/mtk_vcodec_util.h  |   3 +
 3 files changed, 118 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/Kconfig b/drivers/media/platform/mediatek/vcodec/Kconfig
index 74b00eb1bc97..182fd95c9fda 100644
--- a/drivers/media/platform/mediatek/vcodec/Kconfig
+++ b/drivers/media/platform/mediatek/vcodec/Kconfig
@@ -17,6 +17,7 @@ config VIDEO_MEDIATEK_VCODEC
 	depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
 	depends on MTK_SCP || !MTK_SCP
 	depends on MTK_SMI || (COMPILE_TEST && MTK_SMI=n)
+	depends on DMABUF_HEAPS
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
 	select VIDEO_MEDIATEK_VCODEC_VPU if VIDEO_MEDIATEK_VPU
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 62bb7290c56d..9bac6a90c5c5 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -8,6 +8,8 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/regmap.h>
+#include <linux/dma-heap.h>
+#include <uapi/linux/dma-heap.h>
 
 #include "../decoder/mtk_vcodec_dec_drv.h"
 #include "../encoder/mtk_vcodec_enc_drv.h"
@@ -45,11 +47,11 @@ int mtk_vcodec_write_vdecsys(struct mtk_vcodec_dec_ctx *ctx, unsigned int reg,
 }
 EXPORT_SYMBOL(mtk_vcodec_write_vdecsys);
 
-static int mtk_vcodec_mem_dec_alloc(void *priv, struct mtk_vcodec_mem *mem)
+static int mtk_vcodec_mem_dec_alloc_nor(struct mtk_vcodec_dec_ctx *ctx,
+					struct mtk_vcodec_mem *mem)
 {
-	unsigned long size = mem->size;
-	struct mtk_vcodec_dec_ctx *ctx = priv;
 	struct device *dev = &ctx->dev->plat_dev->dev;
+	unsigned long size = mem->size;
 
 	mem->va = dma_alloc_coherent(dev, size, &mem->dma_addr, GFP_KERNEL);
 	if (!mem->va) {
@@ -57,12 +59,89 @@ static int mtk_vcodec_mem_dec_alloc(void *priv, struct mtk_vcodec_mem *mem)
 		return -ENOMEM;
 	}
 
+	return 0;
+}
+
+static int mtk_vcodec_mem_dec_alloc_sec(struct mtk_vcodec_dec_ctx *ctx,
+					struct mtk_vcodec_mem *mem)
+{
+	struct device *dev = &ctx->dev->plat_dev->dev;
+	struct dma_buf *dma_buffer;
+	struct dma_heap *vdec_heap;
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
+	unsigned long size = mem->size;
+	int ret = 0;
+
+	if (!size)
+		return -EINVAL;
+
+	vdec_heap = dma_heap_find("mtk_svp");
+	if (!vdec_heap) {
+		mtk_v4l2_vdec_err(ctx, "dma heap find failed!");
+		return -EPERM;
+	}
+
+	dma_buffer = dma_heap_buffer_alloc(vdec_heap, size, DMA_HEAP_VALID_FD_FLAGS,
+					   DMA_HEAP_VALID_HEAP_FLAGS);
+	if (IS_ERR_OR_NULL(dma_buffer)) {
+		mtk_v4l2_vdec_err(ctx, "dma heap alloc size=0x%lx failed!", size);
+		return PTR_ERR(dma_buffer);
+	}
+
+	attach = dma_buf_attach(dma_buffer, dev);
+	if (IS_ERR_OR_NULL(attach)) {
+		mtk_v4l2_vdec_err(ctx, "dma attach size=0x%lx failed!", size);
+		ret = PTR_ERR(attach);
+		goto err_attach;
+	}
+
+	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+	if (IS_ERR_OR_NULL(sgt)) {
+		mtk_v4l2_vdec_err(ctx, "dma map attach size=0x%lx failed!", size);
+		ret = PTR_ERR(sgt);
+		goto err_sgt;
+	}
+
+	mem->va = dma_buffer;
+	mem->dma_addr = (dma_addr_t)sg_dma_address((sgt)->sgl);
+
+	if (!mem->va || !mem->dma_addr) {
+		mtk_v4l2_vdec_err(ctx, "dma buffer size=0x%lx failed!", size);
+		ret = -EPERM;
+		goto err_addr;
+	}
+
+	mem->attach = attach;
+	mem->sgt = sgt;
+
+	return 0;
+err_addr:
+	dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+err_sgt:
+	dma_buf_detach(dma_buffer, attach);
+err_attach:
+	dma_buf_put(dma_buffer);
+
+	return ret;
+}
+
+static int mtk_vcodec_mem_dec_alloc(void *priv, struct mtk_vcodec_mem *mem)
+{
+	struct mtk_vcodec_dec_ctx *ctx = priv;
+	int ret;
+
+	if (ctx->is_svp_mode)
+		ret = mtk_vcodec_mem_dec_alloc_sec(ctx, mem);
+	else
+		ret = mtk_vcodec_mem_dec_alloc_nor(ctx, mem);
+
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d]  - va      = %p", ctx->id, mem->va);
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d]  - dma     = 0x%lx", ctx->id,
 			  (unsigned long)mem->dma_addr);
-	mtk_v4l2_vdec_dbg(3, ctx, "[%d]    size = 0x%lx", ctx->id, size);
+	mtk_v4l2_vdec_dbg(3, ctx, "[%d]    size = 0x%lx", ctx->id, (unsigned long)mem->size);
 
-	return 0;
+	return ret;
 }
 
 static int mtk_vcodec_mem_enc_alloc(void *priv, struct mtk_vcodec_mem *mem)
@@ -96,6 +175,31 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 }
 EXPORT_SYMBOL(mtk_vcodec_mem_alloc);
 
+static void mtk_vcodec_mem_dec_free_nor(struct mtk_vcodec_dec_ctx *ctx,
+					struct mtk_vcodec_mem *mem)
+{
+	struct device *dev = &ctx->dev->plat_dev->dev;
+
+	dma_free_coherent(dev, mem->size, mem->va, mem->dma_addr);
+
+	mem->va = NULL;
+	mem->dma_addr = 0;
+	mem->size = 0;
+}
+
+static void mtk_vcodec_mem_dec_free_sec(struct mtk_vcodec_mem *mem)
+{
+	dma_buf_unmap_attachment(mem->attach, mem->sgt, DMA_BIDIRECTIONAL);
+	dma_buf_detach((struct dma_buf *)mem->va, mem->attach);
+	dma_buf_put((struct dma_buf *)mem->va);
+
+	mem->attach = NULL;
+	mem->sgt = NULL;
+	mem->va = NULL;
+	mem->dma_addr = 0;
+	mem->size = 0;
+}
+
 static void mtk_vcodec_mem_dec_free(void *priv, struct mtk_vcodec_mem *mem)
 {
 	unsigned long size = mem->size;
@@ -112,10 +216,10 @@ static void mtk_vcodec_mem_dec_free(void *priv, struct mtk_vcodec_mem *mem)
 			  (unsigned long)mem->dma_addr);
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d]    size = 0x%lx", ctx->id, size);
 
-	dma_free_coherent(dev, size, mem->va, mem->dma_addr);
-	mem->va = NULL;
-	mem->dma_addr = 0;
-	mem->size = 0;
+	if (ctx->is_svp_mode)
+		mtk_vcodec_mem_dec_free_sec(mem);
+	else
+		mtk_vcodec_mem_dec_free_nor(ctx, mem);
 }
 
 static void mtk_vcodec_mem_enc_free(void *priv, struct mtk_vcodec_mem *mem)
@@ -210,3 +314,4 @@ EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("Mediatek video codec driver");
+MODULE_IMPORT_NS(DMA_BUF);
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
index 85f615cdd4d3..22078e757ed0 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
@@ -18,6 +18,9 @@ struct mtk_vcodec_mem {
 	size_t size;
 	void *va;
 	dma_addr_t dma_addr;
+
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
 };
 
 struct mtk_vcodec_fb {
-- 
2.18.0

[PATCH 07/14] media: mediatek: vcodec: using shared memory as vsi address

[Yunfei Dong]

The vsi buffer is allocated by tee share memory for svp mode, need to
use the share memory as the vsi address to store vsi data.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c         | 9 +++++++--
 .../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 8 ++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 0e741e0dc8ba..7017217022b1 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -417,8 +417,13 @@ static int vdec_h264_slice_init(struct mtk_vcodec_dec_ctx *ctx)
 
 	vsi_size = round_up(sizeof(struct vdec_h264_slice_vsi), VCODEC_DEC_ALIGNED_64);
 	inst->vsi = inst->vpu.vsi;
-	inst->vsi_core =
-		(struct vdec_h264_slice_vsi *)(((char *)inst->vpu.vsi) + vsi_size);
+	if (ctx->is_svp_mode)
+		inst->vsi_core =
+			mtk_vcodec_dec_get_shm_buffer_va(ctx->dev->optee_private, MTK_VDEC_CORE,
+							 OPTEE_DATA_INDEX);
+	else
+		inst->vsi_core =
+			(struct vdec_h264_slice_vsi *)(((char *)inst->vpu.vsi) + vsi_size);
 	inst->resolution_changed = true;
 	inst->realloc_mv_buf = true;
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index c1a1bddf99d8..d63ba20214fb 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -18,8 +18,12 @@ static void handle_init_ack_msg(const struct vdec_vpu_ipi_init_ack *msg)
 
 	/* mapping VPU address to kernel virtual address */
 	/* the content in vsi is initialized to 0 in VPU */
-	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
-					     msg->vpu_inst_addr);
+	if (vpu->ctx->is_svp_mode)
+		vpu->vsi = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private,
+							    MTK_VDEC_LAT0, OPTEE_DATA_INDEX);
+	else
+		vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
+						     msg->vpu_inst_addr);
 	vpu->inst_addr = msg->vpu_inst_addr;
 
 	mtk_vdec_debug(vpu->ctx, "- vpu_inst_addr = 0x%x", vpu->inst_addr);
-- 
2.18.0

[PATCH 08/14] media: medkatek: vcodec: support one plane capture buffer

[Yunfei Dong]

The capture buffer has two planes for format MM21, but user space only
allocate secure memory for plane[0], and the size is Y data + uv data.
The driver need to support one plane decoder for svp mode.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 24 ++++++++++++-------
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 13 ++++++----
 .../decoder/vdec/vdec_h264_req_common.c       | 16 +++++++------
 .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 ++--
 4 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index 91ed576d6821..457c3e2979c9 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -541,14 +541,15 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
 			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
 				ctx->picinfo.buf_w;
 		} else {
-			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
-				ctx->picinfo.fb_sz[0];
-			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
-				ctx->picinfo.buf_w;
-			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
-				ctx->picinfo.fb_sz[1];
-			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
-				ctx->picinfo.buf_w;
+			if (ctx->is_svp_mode)
+				ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+					ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
+			else
+				ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] = ctx->picinfo.fb_sz[0];
+
+			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = ctx->picinfo.buf_w;
+			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] = ctx->picinfo.fb_sz[1];
+			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] = ctx->picinfo.buf_w;
 		}
 
 		ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx->picinfo.buf_w;
@@ -673,7 +674,12 @@ static int vidioc_vdec_g_fmt(struct file *file, void *priv,
 		 * So we just return picinfo yet, and update picinfo in
 		 * stop_streaming hook function
 		 */
-		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
+
+		if (ctx->is_svp_mode)
+			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
+		else
+			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
+
 		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
 		q_data->bytesperline[0] = ctx->last_decoded_picinfo.buf_w;
 		q_data->bytesperline[1] = ctx->last_decoded_picinfo.buf_w;
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
index e29c9c58f3da..2ea517883a86 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
@@ -256,11 +256,12 @@ static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
 	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
 
 	pfb = &framebuf->frame_buffer;
-	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
+	if (!ctx->is_svp_mode)
+		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
 	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
 	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
 
-	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
+	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx->is_svp_mode) {
 		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
 		pfb->base_c.dma_addr =
 			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
@@ -310,16 +311,18 @@ static void mtk_vdec_worker(struct work_struct *work)
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
 			  vb2_src->vb2_queue->type, vb2_src->index, vb2_src);
 
-	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
-	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
-	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
+	if (!ctx->is_svp_mode) {
+		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
 	if (!bs_src->va) {
 		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
 		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
 				  vb2_src->index);
 		return;
+		}
 	}
 
+	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
+	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
 			  ctx->id, bs_src->va, &bs_src->dma_addr, bs_src->size, vb2_src);
 	/* Apply request controls. */
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
index 5ca20d75dc8e..838f0eeea6e2 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
@@ -81,13 +81,15 @@ void mtk_vdec_h264_fill_dpb_info(struct mtk_vcodec_dec_ctx *ctx,
 
 		h264_dpb_info[index].y_dma_addr =
 			vb2_dma_contig_plane_dma_addr(vb, 0);
-		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
-			h264_dpb_info[index].c_dma_addr =
-				vb2_dma_contig_plane_dma_addr(vb, 1);
-		else
-			h264_dpb_info[index].c_dma_addr =
-				h264_dpb_info[index].y_dma_addr +
-				ctx->picinfo.fb_sz[0];
+		if (!ctx->is_svp_mode) {
+			if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+				h264_dpb_info[index].c_dma_addr =
+					vb2_dma_contig_plane_dma_addr(vb, 1);
+			else
+				h264_dpb_info[index].c_dma_addr =
+					h264_dpb_info[index].y_dma_addr +
+					ctx->picinfo.fb_sz[0];
+		}
 	}
 }
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
index d0b459b1603f..c7d33e540a13 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
@@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx *ctx, struct mtk_vcodec_mem *bs,
 {
 	int ret = 0;
 
-	if (bs) {
+	if (bs && !ctx->is_svp_mode) {
 		if ((bs->dma_addr & 63) != 0) {
 			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64 byte align");
 			return -EINVAL;
 		}
 	}
 
-	if (fb) {
+	if (fb && !ctx->is_svp_mode) {
 		if (((fb->base_y.dma_addr & 511) != 0) ||
 		    ((fb->base_c.dma_addr & 511) != 0)) {
 			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr should 512 byte align");
-- 
2.18.0

Re: [PATCH 08/14] media: medkatek: vcodec: support one plane capture buffer

[Nicolas Dufresne]

Hi,

Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> The capture buffer has two planes for format MM21, but user space only
> allocate secure memory for plane[0], and the size is Y data + uv data.
> The driver need to support one plane decoder for svp mode.

I'm sorry, but in current V4L2 status, you must introduce a new format. Assuming
the second M means MPLANE, this format would be MT21 (though you already used
that fourcc for MT21C) ?

Nicolas

> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>  .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 24 ++++++++++++-------
>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 13 ++++++----
>  .../decoder/vdec/vdec_h264_req_common.c       | 16 +++++++------
>  .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 ++--
>  4 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 91ed576d6821..457c3e2979c9 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -541,14 +541,15 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
>  			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
>  				ctx->picinfo.buf_w;
>  		} else {
> -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> -				ctx->picinfo.fb_sz[0];
> -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> -				ctx->picinfo.buf_w;
> -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
> -				ctx->picinfo.fb_sz[1];
> -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
> -				ctx->picinfo.buf_w;
> +			if (ctx->is_svp_mode)
> +				ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> +					ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
> +			else
> +				ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] = ctx->picinfo.fb_sz[0];
> +
> +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = ctx->picinfo.buf_w;
> +			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] = ctx->picinfo.fb_sz[1];
> +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] = ctx->picinfo.buf_w;
>  		}
>  
>  		ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx->picinfo.buf_w;
> @@ -673,7 +674,12 @@ static int vidioc_vdec_g_fmt(struct file *file, void *priv,
>  		 * So we just return picinfo yet, and update picinfo in
>  		 * stop_streaming hook function
>  		 */
> -		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> +
> +		if (ctx->is_svp_mode)
> +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
> +		else
> +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> +
>  		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
>  		q_data->bytesperline[0] = ctx->last_decoded_picinfo.buf_w;
>  		q_data->bytesperline[1] = ctx->last_decoded_picinfo.buf_w;
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index e29c9c58f3da..2ea517883a86 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -256,11 +256,12 @@ static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
>  	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
>  
>  	pfb = &framebuf->frame_buffer;
> -	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> +	if (!ctx->is_svp_mode)
> +		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
>  	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
>  	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
>  
> -	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> +	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx->is_svp_mode) {
>  		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
>  		pfb->base_c.dma_addr =
>  			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
> @@ -310,16 +311,18 @@ static void mtk_vdec_worker(struct work_struct *work)
>  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
>  			  vb2_src->vb2_queue->type, vb2_src->index, vb2_src);
>  
> -	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> -	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> -	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> +	if (!ctx->is_svp_mode) {
> +		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
>  	if (!bs_src->va) {
>  		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
>  		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
>  				  vb2_src->index);
>  		return;
> +		}
>  	}
>  
> +	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> +	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
>  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
>  			  ctx->id, bs_src->va, &bs_src->dma_addr, bs_src->size, vb2_src);
>  	/* Apply request controls. */
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> index 5ca20d75dc8e..838f0eeea6e2 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> @@ -81,13 +81,15 @@ void mtk_vdec_h264_fill_dpb_info(struct mtk_vcodec_dec_ctx *ctx,
>  
>  		h264_dpb_info[index].y_dma_addr =
>  			vb2_dma_contig_plane_dma_addr(vb, 0);
> -		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> -			h264_dpb_info[index].c_dma_addr =
> -				vb2_dma_contig_plane_dma_addr(vb, 1);
> -		else
> -			h264_dpb_info[index].c_dma_addr =
> -				h264_dpb_info[index].y_dma_addr +
> -				ctx->picinfo.fb_sz[0];
> +		if (!ctx->is_svp_mode) {
> +			if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> +				h264_dpb_info[index].c_dma_addr =
> +					vb2_dma_contig_plane_dma_addr(vb, 1);
> +			else
> +				h264_dpb_info[index].c_dma_addr =
> +					h264_dpb_info[index].y_dma_addr +
> +					ctx->picinfo.fb_sz[0];
> +		}
>  	}
>  }
>  
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> index d0b459b1603f..c7d33e540a13 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> @@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx *ctx, struct mtk_vcodec_mem *bs,
>  {
>  	int ret = 0;
>  
> -	if (bs) {
> +	if (bs && !ctx->is_svp_mode) {
>  		if ((bs->dma_addr & 63) != 0) {
>  			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64 byte align");
>  			return -EINVAL;
>  		}
>  	}
>  
> -	if (fb) {
> +	if (fb && !ctx->is_svp_mode) {
>  		if (((fb->base_y.dma_addr & 511) != 0) ||
>  		    ((fb->base_c.dma_addr & 511) != 0)) {
>  			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr should 512 byte align");

Re: [PATCH 08/14] media: medkatek: vcodec: support one plane capture buffer

[Yunfei Dong (董云飞)]

Hi Nicolas,

Thanks for your advice.
On Mon, 2023-09-11 at 11:44 -0400, Nicolas Dufresne wrote:
> Hi,
> 
> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > The capture buffer has two planes for format MM21, but user space
> > only
> > allocate secure memory for plane[0], and the size is Y data + uv
> > data.
> > The driver need to support one plane decoder for svp mode.
> 
> I'm sorry, but in current V4L2 status, you must introduce a new
> format. Assuming
> the second M means MPLANE, this format would be MT21 (though you
> already used
> that fourcc for MT21C) ?
> 

Just using the first plane for format MM21 in order to support svp mode
according google's suggestion. The plane[1] won't be used to allocate
memory. Whether it's better to add one format to support one plane? Not
using MM21.

Best Regards,
Yunfei Dong
> Nicolas
> 
> > 
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> >  .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 24 ++++++++++++---
> > ----
> >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 13 ++++++----
> >  .../decoder/vdec/vdec_h264_req_common.c       | 16 +++++++------
> >  .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 ++--
> >  4 files changed, 34 insertions(+), 23 deletions(-)
> > 
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > index 91ed576d6821..457c3e2979c9 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > @@ -541,14 +541,15 @@ static int vidioc_vdec_s_fmt(struct file
> > *file, void *priv,
> >  			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> >  				ctx->picinfo.buf_w;
> >  		} else {
> > -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> > -				ctx->picinfo.fb_sz[0];
> > -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> > -				ctx->picinfo.buf_w;
> > -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
> > -				ctx->picinfo.fb_sz[1];
> > -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
> > -				ctx->picinfo.buf_w;
> > +			if (ctx->is_svp_mode)
> > +				ctx-
> > >q_data[MTK_Q_DATA_DST].sizeimage[0] =
> > +					ctx->picinfo.fb_sz[0] + ctx-
> > >picinfo.fb_sz[1];
> > +			else
> > +				ctx-
> > >q_data[MTK_Q_DATA_DST].sizeimage[0] = ctx->picinfo.fb_sz[0];
> > +
> > +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> > ctx->picinfo.buf_w;
> > +			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] = ctx-
> > >picinfo.fb_sz[1];
> > +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
> > ctx->picinfo.buf_w;
> >  		}
> >  
> >  		ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx-
> > >picinfo.buf_w;
> > @@ -673,7 +674,12 @@ static int vidioc_vdec_g_fmt(struct file
> > *file, void *priv,
> >  		 * So we just return picinfo yet, and update picinfo in
> >  		 * stop_streaming hook function
> >  		 */
> > -		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> > +
> > +		if (ctx->is_svp_mode)
> > +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] +
> > ctx->picinfo.fb_sz[1];
> > +		else
> > +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> > +
> >  		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
> >  		q_data->bytesperline[0] = ctx-
> > >last_decoded_picinfo.buf_w;
> >  		q_data->bytesperline[1] = ctx-
> > >last_decoded_picinfo.buf_w;
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > index e29c9c58f3da..2ea517883a86 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > @@ -256,11 +256,12 @@ static struct vdec_fb
> > *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
> >  	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf,
> > m2m_buf.vb);
> >  
> >  	pfb = &framebuf->frame_buffer;
> > -	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> > +	if (!ctx->is_svp_mode)
> > +		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> >  	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf,
> > 0);
> >  	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
> >  
> > -	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> > +	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx-
> > >is_svp_mode) {
> >  		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
> >  		pfb->base_c.dma_addr =
> >  			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
> > @@ -310,16 +311,18 @@ static void mtk_vdec_worker(struct
> > work_struct *work)
> >  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
> >  			  vb2_src->vb2_queue->type, vb2_src->index,
> > vb2_src);
> >  
> > -	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> > -	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> > -	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> > +	if (!ctx->is_svp_mode) {
> > +		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> >  	if (!bs_src->va) {
> >  		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> >  		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is
> > NULL", ctx->id,
> >  				  vb2_src->index);
> >  		return;
> > +		}
> >  	}
> >  
> > +	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> > +	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> >  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad
> > Size=%zx vb=%p",
> >  			  ctx->id, bs_src->va, &bs_src->dma_addr,
> > bs_src->size, vb2_src);
> >  	/* Apply request controls. */
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _common.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _common.c
> > index 5ca20d75dc8e..838f0eeea6e2 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _common.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _common.c
> > @@ -81,13 +81,15 @@ void mtk_vdec_h264_fill_dpb_info(struct
> > mtk_vcodec_dec_ctx *ctx,
> >  
> >  		h264_dpb_info[index].y_dma_addr =
> >  			vb2_dma_contig_plane_dma_addr(vb, 0);
> > -		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> > -			h264_dpb_info[index].c_dma_addr =
> > -				vb2_dma_contig_plane_dma_addr(vb, 1);
> > -		else
> > -			h264_dpb_info[index].c_dma_addr =
> > -				h264_dpb_info[index].y_dma_addr +
> > -				ctx->picinfo.fb_sz[0];
> > +		if (!ctx->is_svp_mode) {
> > +			if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes 
> > == 2)
> > +				h264_dpb_info[index].c_dma_addr =
> > +					vb2_dma_contig_plane_dma_addr(v
> > b, 1);
> > +			else
> > +				h264_dpb_info[index].c_dma_addr =
> > +					h264_dpb_info[index].y_dma_addr
> > +
> > +					ctx->picinfo.fb_sz[0];
> > +		}
> >  	}
> >  }
> >  
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > index d0b459b1603f..c7d33e540a13 100644
> > --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > @@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx
> > *ctx, struct mtk_vcodec_mem *bs,
> >  {
> >  	int ret = 0;
> >  
> > -	if (bs) {
> > +	if (bs && !ctx->is_svp_mode) {
> >  		if ((bs->dma_addr & 63) != 0) {
> >  			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64
> > byte align");
> >  			return -EINVAL;
> >  		}
> >  	}
> >  
> > -	if (fb) {
> > +	if (fb && !ctx->is_svp_mode) {
> >  		if (((fb->base_y.dma_addr & 511) != 0) ||
> >  		    ((fb->base_c.dma_addr & 511) != 0)) {
> >  			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr
> > should 512 byte align");
> 
> 

Re: [PATCH 08/14] media: medkatek: vcodec: support one plane capture buffer

[Nicolas Dufresne]

Le mardi 12 septembre 2023 à 02:08 +0000, Yunfei Dong (董云飞) a écrit :
> Hi Nicolas,
> 
> Thanks for your advice.
> On Mon, 2023-09-11 at 11:44 -0400, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > The capture buffer has two planes for format MM21, but user space
> > > only
> > > allocate secure memory for plane[0], and the size is Y data + uv
> > > data.
> > > The driver need to support one plane decoder for svp mode.
> > 
> > I'm sorry, but in current V4L2 status, you must introduce a new
> > format. Assuming
> > the second M means MPLANE, this format would be MT21 (though you
> > already used
> > that fourcc for MT21C) ?
> > 
> 
> Just using the first plane for format MM21 in order to support svp mode
> according google's suggestion. The plane[1] won't be used to allocate
> memory. Whether it's better to add one format to support one plane? Not
> using MM21.

Userspace will be confused and will need to have special casing for this
platform if you do that. MM21 has been defined as 2 planes, 2 allocations, you
cannot use it for 1 plane/allocation.

Nicolas

> 
> Best Regards,
> Yunfei Dong
> > Nicolas
> > 
> > > 
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > >  .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 24 ++++++++++++---
> > > ----
> > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 13 ++++++----
> > >  .../decoder/vdec/vdec_h264_req_common.c       | 16 +++++++------
> > >  .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 ++--
> > >  4 files changed, 34 insertions(+), 23 deletions(-)
> > > 
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > > index 91ed576d6821..457c3e2979c9 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> > > @@ -541,14 +541,15 @@ static int vidioc_vdec_s_fmt(struct file
> > > *file, void *priv,
> > >  			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> > >  				ctx->picinfo.buf_w;
> > >  		} else {
> > > -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> > > -				ctx->picinfo.fb_sz[0];
> > > -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> > > -				ctx->picinfo.buf_w;
> > > -			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
> > > -				ctx->picinfo.fb_sz[1];
> > > -			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
> > > -				ctx->picinfo.buf_w;
> > > +			if (ctx->is_svp_mode)
> > > +				ctx-
> > > > q_data[MTK_Q_DATA_DST].sizeimage[0] =
> > > +					ctx->picinfo.fb_sz[0] + ctx-
> > > > picinfo.fb_sz[1];
> > > +			else
> > > +				ctx-
> > > > q_data[MTK_Q_DATA_DST].sizeimage[0] = ctx->picinfo.fb_sz[0];
> > > +
> > > +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
> > > ctx->picinfo.buf_w;
> > > +			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] = ctx-
> > > > picinfo.fb_sz[1];
> > > +			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
> > > ctx->picinfo.buf_w;
> > >  		}
> > >  
> > >  		ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx-
> > > > picinfo.buf_w;
> > > @@ -673,7 +674,12 @@ static int vidioc_vdec_g_fmt(struct file
> > > *file, void *priv,
> > >  		 * So we just return picinfo yet, and update picinfo in
> > >  		 * stop_streaming hook function
> > >  		 */
> > > -		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> > > +
> > > +		if (ctx->is_svp_mode)
> > > +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] +
> > > ctx->picinfo.fb_sz[1];
> > > +		else
> > > +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> > > +
> > >  		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
> > >  		q_data->bytesperline[0] = ctx-
> > > > last_decoded_picinfo.buf_w;
> > >  		q_data->bytesperline[1] = ctx-
> > > > last_decoded_picinfo.buf_w;
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > index e29c9c58f3da..2ea517883a86 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > @@ -256,11 +256,12 @@ static struct vdec_fb
> > > *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
> > >  	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf,
> > > m2m_buf.vb);
> > >  
> > >  	pfb = &framebuf->frame_buffer;
> > > -	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> > > +	if (!ctx->is_svp_mode)
> > > +		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> > >  	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf,
> > > 0);
> > >  	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
> > >  
> > > -	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> > > +	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx-
> > > > is_svp_mode) {
> > >  		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
> > >  		pfb->base_c.dma_addr =
> > >  			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
> > > @@ -310,16 +311,18 @@ static void mtk_vdec_worker(struct
> > > work_struct *work)
> > >  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
> > >  			  vb2_src->vb2_queue->type, vb2_src->index,
> > > vb2_src);
> > >  
> > > -	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> > > -	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> > > -	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> > > +	if (!ctx->is_svp_mode) {
> > > +		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> > >  	if (!bs_src->va) {
> > >  		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> > >  		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is
> > > NULL", ctx->id,
> > >  				  vb2_src->index);
> > >  		return;
> > > +		}
> > >  	}
> > >  
> > > +	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> > > +	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> > >  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad
> > > Size=%zx vb=%p",
> > >  			  ctx->id, bs_src->va, &bs_src->dma_addr,
> > > bs_src->size, vb2_src);
> > >  	/* Apply request controls. */
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > > _common.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > > _common.c
> > > index 5ca20d75dc8e..838f0eeea6e2 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > > _common.c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > > _common.c
> > > @@ -81,13 +81,15 @@ void mtk_vdec_h264_fill_dpb_info(struct
> > > mtk_vcodec_dec_ctx *ctx,
> > >  
> > >  		h264_dpb_info[index].y_dma_addr =
> > >  			vb2_dma_contig_plane_dma_addr(vb, 0);
> > > -		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> > > -			h264_dpb_info[index].c_dma_addr =
> > > -				vb2_dma_contig_plane_dma_addr(vb, 1);
> > > -		else
> > > -			h264_dpb_info[index].c_dma_addr =
> > > -				h264_dpb_info[index].y_dma_addr +
> > > -				ctx->picinfo.fb_sz[0];
> > > +		if (!ctx->is_svp_mode) {
> > > +			if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes 
> > > == 2)
> > > +				h264_dpb_info[index].c_dma_addr =
> > > +					vb2_dma_contig_plane_dma_addr(v
> > > b, 1);
> > > +			else
> > > +				h264_dpb_info[index].c_dma_addr =
> > > +					h264_dpb_info[index].y_dma_addr
> > > +
> > > +					ctx->picinfo.fb_sz[0];
> > > +		}
> > >  	}
> > >  }
> > >  
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > > index d0b459b1603f..c7d33e540a13 100644
> > > --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> > > @@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx
> > > *ctx, struct mtk_vcodec_mem *bs,
> > >  {
> > >  	int ret = 0;
> > >  
> > > -	if (bs) {
> > > +	if (bs && !ctx->is_svp_mode) {
> > >  		if ((bs->dma_addr & 63) != 0) {
> > >  			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64
> > > byte align");
> > >  			return -EINVAL;
> > >  		}
> > >  	}
> > >  
> > > -	if (fb) {
> > > +	if (fb && !ctx->is_svp_mode) {
> > >  		if (((fb->base_y.dma_addr & 511) != 0) ||
> > >  		    ((fb->base_c.dma_addr & 511) != 0)) {
> > >  			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr
> > > should 512 byte align");
> > 
> > 

[PATCH 09/14] media: medkatek: vcodec: re-construct h264 driver to support svp mode

[Yunfei Dong]

Need secure buffer size to convert secure handle to secure
pa in optee-os, re-construct the vsi struct to store each
secure buffer size.

Separate svp and normal wait interrupt condition for svp mode
waiting hardware interrupt in optee-os.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 261 +++++++++++-------
 .../mediatek/vcodec/decoder/vdec_msg_queue.c  |   9 +-
 2 files changed, 168 insertions(+), 102 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 7017217022b1..fe63a745be87 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -60,14 +60,36 @@ struct vdec_h264_slice_lat_dec_param {
  * @crc:		Used to check whether hardware's status is right
  */
 struct vdec_h264_slice_info {
+	u64 wdma_end_addr_offset;
 	u16 nal_info;
 	u16 timeout;
-	u32 bs_buf_size;
-	u64 bs_buf_addr;
-	u64 y_fb_dma;
-	u64 c_fb_dma;
 	u64 vdec_fb_va;
 	u32 crc[8];
+	u32 reserved;
+};
+
+/*
+ * struct vdec_h264_slice_mem - memory address and size
+ */
+struct vdec_h264_slice_mem {
+	union {
+		u64 buf;
+		u64 dma_addr;
+	};
+	union {
+		size_t size;
+		u64 dma_addr_end;
+	};
+};
+
+/**
+ * struct vdec_h264_slice_fb - frame buffer for decoding
+ * @y:  current y buffer address info
+ * @c:  current c buffer address info
+ */
+struct vdec_h264_slice_fb {
+	struct vdec_h264_slice_mem y;
+	struct vdec_h264_slice_mem c;
 };
 
 /**
@@ -92,18 +114,16 @@ struct vdec_h264_slice_info {
  */
 struct vdec_h264_slice_vsi {
 	/* LAT dec addr */
-	u64 wdma_err_addr;
-	u64 wdma_start_addr;
-	u64 wdma_end_addr;
-	u64 slice_bc_start_addr;
-	u64 slice_bc_end_addr;
-	u64 row_info_start_addr;
-	u64 row_info_end_addr;
-	u64 trans_start;
-	u64 trans_end;
-	u64 wdma_end_addr_offset;
+	struct vdec_h264_slice_mem bs;
+	struct vdec_h264_slice_fb fb;
 
-	u64 mv_buf_dma[H264_MAX_MV_NUM];
+	struct vdec_h264_slice_mem ube;
+	struct vdec_h264_slice_mem trans;
+	struct vdec_h264_slice_mem row_info;
+	struct vdec_h264_slice_mem err_map;
+	struct vdec_h264_slice_mem slice_bc;
+
+	struct vdec_h264_slice_mem mv_buf_dma[H264_MAX_MV_NUM];
 	struct vdec_h264_slice_info dec;
 	struct vdec_h264_slice_lat_dec_param h264_slice_params;
 };
@@ -392,6 +412,100 @@ static void vdec_h264_slice_get_crop_info(struct vdec_h264_slice_inst *inst,
 		       cr->left, cr->top, cr->width, cr->height);
 }
 
+static void vdec_h264_slice_setup_lat_buffer(struct vdec_h264_slice_inst *inst,
+					     struct mtk_vcodec_mem *bs,
+					     struct vdec_lat_buf *lat_buf)
+{
+	struct mtk_vcodec_mem *mem;
+	int i;
+
+	inst->vsi->bs.dma_addr = (u64)bs->dma_addr;
+	inst->vsi->bs.size = bs->size;
+
+	for (i = 0; i < H264_MAX_MV_NUM; i++) {
+		mem = &inst->mv_buf[i];
+		inst->vsi->mv_buf_dma[i].dma_addr = mem->dma_addr;
+		inst->vsi->mv_buf_dma[i].size = mem->size;
+	}
+	inst->vsi->ube.dma_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
+	inst->vsi->ube.size = lat_buf->ctx->msg_queue.wdma_addr.size;
+
+	inst->vsi->row_info.dma_addr = 0;
+	inst->vsi->row_info.size = 0;
+
+	inst->vsi->err_map.dma_addr = lat_buf->wdma_err_addr.dma_addr;
+	inst->vsi->err_map.size = lat_buf->wdma_err_addr.size;
+
+	inst->vsi->slice_bc.dma_addr = lat_buf->slice_bc_addr.dma_addr;
+	inst->vsi->slice_bc.size = lat_buf->slice_bc_addr.size;
+
+	inst->vsi->trans.dma_addr_end = inst->ctx->msg_queue.wdma_rptr_addr;
+	inst->vsi->trans.dma_addr = inst->ctx->msg_queue.wdma_wptr_addr;
+}
+
+static int vdec_h264_slice_setup_core_buffer(struct vdec_h264_slice_inst *inst,
+					     struct vdec_h264_slice_share_info *share_info,
+					     struct vdec_lat_buf *lat_buf)
+{
+	struct mtk_vcodec_mem *mem;
+	struct mtk_vcodec_dec_ctx *ctx = inst->ctx;
+	struct vb2_v4l2_buffer *vb2_v4l2;
+	struct vdec_fb *fb;
+	u64 y_fb_dma, c_fb_dma = 0;
+	int i;
+
+	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
+	if (!fb) {
+		mtk_vdec_err(ctx, "fb buffer is NULL");
+		return -EBUSY;
+	}
+
+	y_fb_dma = (u64)fb->base_y.dma_addr;
+	if (!ctx->is_svp_mode) {
+		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
+			c_fb_dma =
+				y_fb_dma + inst->ctx->picinfo.buf_w * inst->ctx->picinfo.buf_h;
+		else
+			c_fb_dma = (u64)fb->base_c.dma_addr;
+	}
+
+	mtk_vdec_debug(ctx, "[h264-core] y/c addr = 0x%llx 0x%llx", y_fb_dma, c_fb_dma);
+
+	inst->vsi_core->fb.y.dma_addr = y_fb_dma;
+	inst->vsi_core->fb.y.size = ctx->picinfo.fb_sz[0];
+	inst->vsi_core->fb.c.dma_addr = c_fb_dma;
+	inst->vsi_core->fb.c.size = ctx->picinfo.fb_sz[1];
+
+	inst->vsi_core->dec.vdec_fb_va = (unsigned long)fb;
+	inst->vsi_core->dec.nal_info = share_info->nal_info;
+
+	inst->vsi_core->ube.dma_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
+	inst->vsi_core->ube.size = lat_buf->ctx->msg_queue.wdma_addr.size;
+
+	inst->vsi_core->err_map.dma_addr = lat_buf->wdma_err_addr.dma_addr;
+	inst->vsi_core->err_map.size = lat_buf->wdma_err_addr.size;
+
+	inst->vsi_core->slice_bc.dma_addr = lat_buf->slice_bc_addr.dma_addr;
+	inst->vsi_core->slice_bc.size = lat_buf->slice_bc_addr.size;
+
+	inst->vsi_core->row_info.dma_addr = 0;
+	inst->vsi_core->row_info.size = 0;
+
+	inst->vsi_core->trans.dma_addr = share_info->trans_start;
+	inst->vsi_core->trans.dma_addr_end = share_info->trans_end;
+
+	for (i = 0; i < H264_MAX_MV_NUM; i++) {
+		mem = &inst->mv_buf[i];
+		inst->vsi_core->mv_buf_dma[i].dma_addr = mem->dma_addr;
+		inst->vsi_core->mv_buf_dma[i].size = mem->size;
+	}
+
+	vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
+	v4l2_m2m_buf_copy_metadata(&lat_buf->ts_info, vb2_v4l2, true);
+
+	return 0;
+}
+
 static int vdec_h264_slice_init(struct mtk_vcodec_dec_ctx *ctx)
 {
 	struct vdec_h264_slice_inst *inst;
@@ -457,64 +571,22 @@ static void vdec_h264_slice_deinit(void *h_vdec)
 
 static int vdec_h264_slice_core_decode(struct vdec_lat_buf *lat_buf)
 {
-	struct vdec_fb *fb;
-	u64 vdec_fb_va;
-	u64 y_fb_dma, c_fb_dma;
-	int err, timeout, i;
+	int err, timeout;
 	struct mtk_vcodec_dec_ctx *ctx = lat_buf->ctx;
 	struct vdec_h264_slice_inst *inst = ctx->drv_handle;
-	struct vb2_v4l2_buffer *vb2_v4l2;
 	struct vdec_h264_slice_share_info *share_info = lat_buf->private_data;
-	struct mtk_vcodec_mem *mem;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 
 	mtk_vdec_debug(ctx, "[h264-core] vdec_h264 core decode");
 	memcpy(&inst->vsi_core->h264_slice_params, &share_info->h264_slice_params,
 	       sizeof(share_info->h264_slice_params));
 
-	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
-	if (!fb) {
-		err = -EBUSY;
-		mtk_vdec_err(ctx, "fb buffer is NULL");
+	err = vdec_h264_slice_setup_core_buffer(inst, share_info, lat_buf);
+	if (err)
 		goto vdec_dec_end;
-	}
-
-	vdec_fb_va = (unsigned long)fb;
-	y_fb_dma = (u64)fb->base_y.dma_addr;
-	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
-		c_fb_dma =
-			y_fb_dma + inst->ctx->picinfo.buf_w * inst->ctx->picinfo.buf_h;
-	else
-		c_fb_dma = (u64)fb->base_c.dma_addr;
-
-	mtk_vdec_debug(ctx, "[h264-core] y/c addr = 0x%llx 0x%llx", y_fb_dma, c_fb_dma);
-
-	inst->vsi_core->dec.y_fb_dma = y_fb_dma;
-	inst->vsi_core->dec.c_fb_dma = c_fb_dma;
-	inst->vsi_core->dec.vdec_fb_va = vdec_fb_va;
-	inst->vsi_core->dec.nal_info = share_info->nal_info;
-	inst->vsi_core->wdma_start_addr =
-		lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
-	inst->vsi_core->wdma_end_addr =
-		lat_buf->ctx->msg_queue.wdma_addr.dma_addr +
-		lat_buf->ctx->msg_queue.wdma_addr.size;
-	inst->vsi_core->wdma_err_addr = lat_buf->wdma_err_addr.dma_addr;
-	inst->vsi_core->slice_bc_start_addr = lat_buf->slice_bc_addr.dma_addr;
-	inst->vsi_core->slice_bc_end_addr = lat_buf->slice_bc_addr.dma_addr +
-		lat_buf->slice_bc_addr.size;
-	inst->vsi_core->trans_start = share_info->trans_start;
-	inst->vsi_core->trans_end = share_info->trans_end;
-	for (i = 0; i < H264_MAX_MV_NUM; i++) {
-		mem = &inst->mv_buf[i];
-		inst->vsi_core->mv_buf_dma[i] = mem->dma_addr;
-	}
-
-	vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
-	v4l2_m2m_buf_copy_metadata(&lat_buf->ts_info, vb2_v4l2, true);
 
 	vdec_h264_slice_fill_decode_reflist(inst, &inst->vsi_core->h264_slice_params,
 					    share_info);
-
 	err = vpu_dec_core(vpu);
 	if (err) {
 		mtk_vdec_err(ctx, "core decode err=%d", err);
@@ -573,12 +645,11 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct vdec_h264_slice_inst *inst = h_vdec;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 	struct mtk_video_dec_buf *src_buf_info;
-	int nal_start_idx, err, timeout = 0, i;
+	int nal_start_idx, err, timeout = 0;
 	unsigned int data[2];
 	struct vdec_lat_buf *lat_buf;
 	struct vdec_h264_slice_share_info *share_info;
 	unsigned char *buf;
-	struct mtk_vcodec_mem *mem;
 
 	if (vdec_msg_queue_init(&inst->ctx->msg_queue, inst->ctx,
 				vdec_h264_slice_core_decode,
@@ -617,11 +688,9 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	if (err)
 		goto err_free_fb_out;
 
-	vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
-				   &share_info->h264_slice_params.pps);
-
-	inst->vsi->dec.bs_buf_addr = (uint64_t)bs->dma_addr;
-	inst->vsi->dec.bs_buf_size = bs->size;
+	if (!inst->ctx->is_svp_mode)
+		vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
+					   &share_info->h264_slice_params.pps);
 
 	*res_chg = inst->resolution_changed;
 	if (inst->resolution_changed) {
@@ -634,38 +703,27 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		}
 		inst->resolution_changed = false;
 	}
-	for (i = 0; i < H264_MAX_MV_NUM; i++) {
-		mem = &inst->mv_buf[i];
-		inst->vsi->mv_buf_dma[i] = mem->dma_addr;
-	}
-	inst->vsi->wdma_start_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
-	inst->vsi->wdma_end_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr +
-		lat_buf->ctx->msg_queue.wdma_addr.size;
-	inst->vsi->wdma_err_addr = lat_buf->wdma_err_addr.dma_addr;
-	inst->vsi->slice_bc_start_addr = lat_buf->slice_bc_addr.dma_addr;
-	inst->vsi->slice_bc_end_addr = lat_buf->slice_bc_addr.dma_addr +
-		lat_buf->slice_bc_addr.size;
-
-	inst->vsi->trans_end = inst->ctx->msg_queue.wdma_rptr_addr;
-	inst->vsi->trans_start = inst->ctx->msg_queue.wdma_wptr_addr;
-	mtk_vdec_debug(inst->ctx, "lat:trans(0x%llx 0x%llx) err:0x%llx",
-		       inst->vsi->wdma_start_addr,
-		       inst->vsi->wdma_end_addr,
-		       inst->vsi->wdma_err_addr);
-
-	mtk_vdec_debug(inst->ctx, "slice(0x%llx 0x%llx) rprt((0x%llx 0x%llx))",
-		       inst->vsi->slice_bc_start_addr,
-		       inst->vsi->slice_bc_end_addr,
-		       inst->vsi->trans_start,
-		       inst->vsi->trans_end);
+
+	vdec_h264_slice_setup_lat_buffer(inst, bs, lat_buf);
+	mtk_vdec_debug(inst->ctx, "lat:trans(0x%llx 0x%lx) err:0x%llx",
+		       inst->vsi->ube.dma_addr, (unsigned long)inst->vsi->ube.size,
+		       inst->vsi->err_map.dma_addr);
+
+	mtk_vdec_debug(inst->ctx, "slice(0x%llx 0x%lx) rprt((0x%llx 0x%llx))",
+		       inst->vsi->slice_bc.dma_addr, (unsigned long)inst->vsi->slice_bc.size,
+		       inst->vsi->trans.dma_addr, inst->vsi->trans.dma_addr_end);
 	err = vpu_dec_start(vpu, data, 2);
 	if (err) {
 		mtk_vdec_debug(inst->ctx, "lat decode err: %d", err);
 		goto err_free_fb_out;
 	}
 
-	share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
-		inst->vsi->wdma_end_addr_offset;
+	if (inst->ctx->is_svp_mode)
+		share_info->trans_end = inst->vsi->dec.wdma_end_addr_offset;
+	else
+		share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
+			inst->vsi->dec.wdma_end_addr_offset;
+
 	share_info->trans_start = inst->ctx->msg_queue.wdma_wptr_addr;
 	share_info->nal_info = inst->vsi->dec.nal_info;
 
@@ -691,8 +749,11 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		return -EINVAL;
 	}
 
-	share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
-		inst->vsi->wdma_end_addr_offset;
+	if (inst->ctx->is_svp_mode)
+		share_info->trans_end = inst->vsi->dec.wdma_end_addr_offset;
+	else
+		share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
+			inst->vsi->dec.wdma_end_addr_offset;
 	vdec_msg_queue_update_ube_wptr(&lat_buf->ctx->msg_queue, share_info->trans_end);
 
 	if (!IS_VDEC_INNER_RACING(inst->ctx->dev->dec_capability)) {
@@ -737,10 +798,10 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 	mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx c_dma=%llx",
 		       inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma);
 
-	inst->vsi_ctx.dec.bs_buf_addr = (u64)bs->dma_addr;
-	inst->vsi_ctx.dec.bs_buf_size = bs->size;
-	inst->vsi_ctx.dec.y_fb_dma = y_fb_dma;
-	inst->vsi_ctx.dec.c_fb_dma = c_fb_dma;
+	inst->vsi_ctx.bs.dma_addr = (u64)bs->dma_addr;
+	inst->vsi_ctx.bs.size = bs->size;
+	inst->vsi_ctx.fb.y.dma_addr = y_fb_dma;
+	inst->vsi_ctx.fb.c.dma_addr = c_fb_dma;
 	inst->vsi_ctx.dec.vdec_fb_va = (u64)(uintptr_t)fb;
 
 	v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb,
@@ -770,7 +831,7 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 
 		for (i = 0; i < H264_MAX_MV_NUM; i++) {
 			mem = &inst->mv_buf[i];
-			inst->vsi_ctx.mv_buf_dma[i] = mem->dma_addr;
+			inst->vsi_ctx.mv_buf_dma[i].dma_addr = mem->dma_addr;
 		}
 	}
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
index f283c4703dc6..1ee04d920279 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
@@ -308,8 +308,13 @@ int vdec_msg_queue_init(struct vdec_msg_queue *msg_queue,
 		msg_queue->wdma_addr.size = 0;
 		return -ENOMEM;
 	}
-	msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
-	msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
+	if (ctx->is_svp_mode) {
+		msg_queue->wdma_rptr_addr = 0;
+		msg_queue->wdma_wptr_addr = 0;
+	} else {
+		msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
+		msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
+	}
 
 	msg_queue->empty_lat_buf.ctx = ctx;
 	msg_queue->empty_lat_buf.core_decode = NULL;
-- 
2.18.0

[PATCH 10/14] media: medkatek: vcodec: remove parse nal_info in kernel

[Yunfei Dong]

The hardware can parse syntax to get nal_info, needn't to use cpu.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c    | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index fe63a745be87..a0bfb4890e8e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -645,11 +645,10 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct vdec_h264_slice_inst *inst = h_vdec;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 	struct mtk_video_dec_buf *src_buf_info;
-	int nal_start_idx, err, timeout = 0;
+	int err, timeout = 0;
 	unsigned int data[2];
 	struct vdec_lat_buf *lat_buf;
 	struct vdec_h264_slice_share_info *share_info;
-	unsigned char *buf;
 
 	if (vdec_msg_queue_init(&inst->ctx->msg_queue, inst->ctx,
 				vdec_h264_slice_core_decode,
@@ -673,14 +672,6 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	share_info = lat_buf->private_data;
 	src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
 
-	buf = (unsigned char *)bs->va;
-	nal_start_idx = mtk_vdec_h264_find_start_code(buf, bs->size);
-	if (nal_start_idx < 0) {
-		err = -EINVAL;
-		goto err_free_fb_out;
-	}
-
-	inst->vsi->dec.nal_info = buf[nal_start_idx];
 	lat_buf->src_buf_req = src_buf_info->m2m_buf.vb.vb2_buf.req_obj.req;
 	v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb, &lat_buf->ts_info, true);
 
@@ -689,7 +680,7 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		goto err_free_fb_out;
 
 	if (!inst->ctx->is_svp_mode)
-		vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
+		vdec_h264_insert_startcode(inst->ctx->dev, bs->va, &bs->size,
 					   &share_info->h264_slice_params.pps);
 
 	*res_chg = inst->resolution_changed;
-- 
2.18.0

[PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Yunfei Dong]

User driver will fill or parse data in optee-os with secure handle,
need to covert secure fd to secure handle in kernel.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
 drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
 include/uapi/linux/v4l2-controls.h            |  4 ++
 4 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
index 0a89ce452ac3..64e006820f43 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
@@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
+MODULE_IMPORT_NS(DMA_BUF);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
index 2ea517883a86..d2b09ce9f1cf 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
@@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
 	return ret;
 }
 
+static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
+{
+	int secure_handle = 0;
+	struct dma_buf *buf;
+	struct dma_buf_attachment *dba;
+	struct sg_table *sgt;
+	struct device *dev = &ctx->dev->plat_dev->dev;
+
+	buf = dma_buf_get(fd);
+	if (IS_ERR(buf)) {
+		mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
+		return 0;
+	}
+
+	dba = dma_buf_attach(buf, dev);
+	if (IS_ERR(dba)) {
+		mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
+		goto err_attach;
+	}
+
+	sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
+	if (IS_ERR(sgt)) {
+		mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
+		goto err_map;
+	}
+	secure_handle = sg_dma_address(sgt->sgl);
+
+	dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
+	dma_buf_detach(buf, dba);
+	dma_buf_put(buf);
+
+	return secure_handle;
+err_map:
+	dma_buf_detach(buf, dba);
+err_attach:
+	dma_buf_put(buf);
+
+	return 0;
+}
+
 static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
 {
 	struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
@@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
 	struct v4l2_ctrl *hdr_ctrl;
 	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
 	const struct mtk_video_fmt *fmt;
-	int i = 0, ret = 0;
+	int i = 0, ret = 0, sec_fd;
 
 	hdr_ctrl = ctrl;
 	if (!hdr_ctrl || !hdr_ctrl->p_new.p)
@@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
 			return -EINVAL;
 		}
 		break;
+	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
+		sec_fd = ctrl->val;
+
+		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
+		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
+		break;
 	default:
 		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
 		return ret;
@@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
 static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
 {
 	unsigned int i;
+	struct v4l2_ctrl *ctrl;
 
-	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
+	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
 	if (ctx->ctrl_hdl.error) {
 		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
 		return ctx->ctrl_hdl.error;
@@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
 		}
 	}
 
+	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
+				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
+
 	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
 
 	return 0;
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 8696eb1cdd61..d8cf01f76aab 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return "HEVC Size of Length Field";
 	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
 	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
+	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
 
 	/* AV1 controls */
 	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
@@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
 		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
 		break;
+	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
+		*type = V4L2_CTRL_TYPE_INTEGER;
+		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
+		break;
 	case V4L2_CID_USER_CLASS:
 	case V4L2_CID_CAMERA_CLASS:
 	case V4L2_CID_CODEC_CLASS:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index c3604a0a3e30..7b3694985366 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
 #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		(V4L2_CID_CODEC_MFC51_BASE+53)
 #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		(V4L2_CID_CODEC_MFC51_BASE+54)
 
+/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
+#define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
+#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
+
 /*  Camera class control IDs */
 
 #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA | 0x900)
-- 
2.18.0

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Nicolas Dufresne]

Hi,

Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> User driver will fill or parse data in optee-os with secure handle,
> need to covert secure fd to secure handle in kernel.

A major rework of the wording is needed in this patchset, to fix the obvious
typos like covert->convert, but also to stop calling dmabuf allocated from
secure heap, secure fd, its not precise enough to understand what this patch is
going to be about.

> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
>  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
>  include/uapi/linux/v4l2-controls.h            |  4 ++
>  4 files changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> index 0a89ce452ac3..64e006820f43 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
>  
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> +MODULE_IMPORT_NS(DMA_BUF);
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index 2ea517883a86..d2b09ce9f1cf 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
>  	return ret;
>  }
>  
> +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> +{
> +	int secure_handle = 0;
> +	struct dma_buf *buf;
> +	struct dma_buf_attachment *dba;
> +	struct sg_table *sgt;
> +	struct device *dev = &ctx->dev->plat_dev->dev;
> +
> +	buf = dma_buf_get(fd);
> +	if (IS_ERR(buf)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> +		return 0;
> +	}
> +
> +	dba = dma_buf_attach(buf, dev);
> +	if (IS_ERR(dba)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> +		goto err_attach;
> +	}
> +
> +	sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> +	if (IS_ERR(sgt)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> +		goto err_map;
> +	}
> +	secure_handle = sg_dma_address(sgt->sgl);
> +
> +	dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> +	dma_buf_detach(buf, dba);
> +	dma_buf_put(buf);
> +
> +	return secure_handle;
> +err_map:
> +	dma_buf_detach(buf, dba);
> +err_attach:
> +	dma_buf_put(buf);
> +
> +	return 0;
> +}
> +
>  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  {
>  	struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  	struct v4l2_ctrl *hdr_ctrl;
>  	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
>  	const struct mtk_video_fmt *fmt;
> -	int i = 0, ret = 0;
> +	int i = 0, ret = 0, sec_fd;
>  
>  	hdr_ctrl = ctrl;
>  	if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  			return -EINVAL;
>  		}
>  		break;
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> +		sec_fd = ctrl->val;
> +
> +		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> +		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> +		break;
>  	default:
>  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
>  		return ret;
> @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
>  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  {
>  	unsigned int i;
> +	struct v4l2_ctrl *ctrl;
>  
> -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>  	if (ctx->ctrl_hdl.error) {
>  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>  		return ctx->ctrl_hdl.error;
> @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  		}
>  	}
>  
> +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> +				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> +
>  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>  
>  	return 0;
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> index 8696eb1cdd61..d8cf01f76aab 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>  	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return "HEVC Size of Length Field";
>  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
>  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
>  
>  	/* AV1 controls */
>  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
> @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>  	case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
>  		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
>  		break;
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> +		*type = V4L2_CTRL_TYPE_INTEGER;
> +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> +		break;
>  	case V4L2_CID_USER_CLASS:
>  	case V4L2_CID_CAMERA_CLASS:
>  	case V4L2_CID_CODEC_CLASS:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index c3604a0a3e30..7b3694985366 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		(V4L2_CID_CODEC_MFC51_BASE+53)
>  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		(V4L2_CID_CODEC_MFC51_BASE+54)
>  
> +/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> +#define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
> +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
> +
>  /*  Camera class control IDs */
>  
>  #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA | 0x900)

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Yunfei Dong (董云飞)]

Hi Nicolas,

Thanks for your advice.
On Mon, 2023-09-11 at 11:47 -0400, Nicolas Dufresne wrote:
> Hi,
> 
> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > User driver will fill or parse data in optee-os with secure handle,
> > need to covert secure fd to secure handle in kernel.
> 
> A major rework of the wording is needed in this patchset, to fix the
> obvious
> typos like covert->convert, 
I will fix in next patch.
> but also to stop calling dmabuf allocated from
> secure heap, secure fd, 
Could you please help to explain it detail?
Whether you meaning I can't
call dma_buf_get/dma_buf_attach functions directly?

> its not precise enough to understand what this patch is
> going to be about.
> 
This patch is used to covert secure fd to secure handle.
User space will get a secure fd using dma interface to allocate secure
memory, but need to covert fd to handle in order to fill es
buffer(output queue) in optee-os. I will write the commit message
detail.

Best Regards,
Yunfei Dong
> > 
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> >  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
> >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54
> > ++++++++++++++++++-
> >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
> >  include/uapi/linux/v4l2-controls.h            |  4 ++
> >  4 files changed, 62 insertions(+), 2 deletions(-)
> > 
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > .c
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > .c
> > index 0a89ce452ac3..64e006820f43 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > .c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > .c
> > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> >  
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > +MODULE_IMPORT_NS(DMA_BUF);
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > index 2ea517883a86..d2b09ce9f1cf 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct
> > mtk_vcodec_dec_ctx *ctx)
> >  	return ret;
> >  }
> >  
> > +static int mtk_dma_contig_get_secure_handle(struct
> > mtk_vcodec_dec_ctx *ctx, int fd)
> > +{
> > +	int secure_handle = 0;
> > +	struct dma_buf *buf;
> > +	struct dma_buf_attachment *dba;
> > +	struct sg_table *sgt;
> > +	struct device *dev = &ctx->dev->plat_dev->dev;
> > +
> > +	buf = dma_buf_get(fd);
> > +	if (IS_ERR(buf)) {
> > +		mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > +		return 0;
> > +	}
> > +
> > +	dba = dma_buf_attach(buf, dev);
> > +	if (IS_ERR(dba)) {
> > +		mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d",
> > fd);
> > +		goto err_attach;
> > +	}
> > +
> > +	sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > +	if (IS_ERR(sgt)) {
> > +		mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail
> > fd:%d", fd);
> > +		goto err_map;
> > +	}
> > +	secure_handle = sg_dma_address(sgt->sgl);
> > +
> > +	dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > +	dma_buf_detach(buf, dba);
> > +	dma_buf_put(buf);
> > +
> > +	return secure_handle;
> > +err_map:
> > +	dma_buf_detach(buf, dba);
> > +err_attach:
> > +	dma_buf_put(buf);
> > +
> > +	return 0;
> > +}
> > +
> >  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> >  {
> >  	struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > *ctrl)
> >  	struct v4l2_ctrl *hdr_ctrl;
> >  	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev-
> > >vdec_pdata;
> >  	const struct mtk_video_fmt *fmt;
> > -	int i = 0, ret = 0;
> > +	int i = 0, ret = 0, sec_fd;
> >  
> >  	hdr_ctrl = ctrl;
> >  	if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > *ctrl)
> >  			return -EINVAL;
> >  		}
> >  		break;
> > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > +		sec_fd = ctrl->val;
> > +
> > +		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl-
> > >val);
> > +		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d =>
> > 0x%x", sec_fd, ctrl->val);
> > +		break;
> >  	default:
> >  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl
> > id: 0x%x\n", hdr_ctrl->id);
> >  		return ret;
> > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops
> > mtk_vcodec_dec_ctrl_ops = {
> >  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx
> > *ctx)
> >  {
> >  	unsigned int i;
> > +	struct v4l2_ctrl *ctrl;
> >  
> > -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >  	if (ctx->ctrl_hdl.error) {
> >  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init
> > failed\n");
> >  		return ctx->ctrl_hdl.error;
> > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > mtk_vcodec_dec_ctx *ctx)
> >  		}
> >  	}
> >  
> > +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > &mtk_vcodec_dec_ctrl_ops,
> > +				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE,
> > 0, 65535, 1, 0);
> > +
> >  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >  
> >  	return 0;
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > index 8696eb1cdd61..d8cf01f76aab 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >  	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return
> > "HEVC Size of Length Field";
> >  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return
> > "Reference Frames for a P-Frame";
> >  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		ret
> > urn "Prepend SPS and PPS to IDR";
> > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return
> > "MediaTek Decoder get secure handle";
> >  
> >  	/* AV1 controls */
> >  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			ret
> > urn "AV1 Profile";
> > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > **name, enum v4l2_ctrl_type *type,
> >  	case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> >  		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
> >  		break;
> > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > +		*type = V4L2_CTRL_TYPE_INTEGER;
> > +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > +		break;
> >  	case V4L2_CID_USER_CLASS:
> >  	case V4L2_CID_CAMERA_CLASS:
> >  	case V4L2_CID_CODEC_CLASS:
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index c3604a0a3e30..7b3694985366 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		
> > (V4L2_CID_CODEC_MFC51_BASE+53)
> >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		
> > (V4L2_CID_CODEC_MFC51_BASE+54)
> >  
> > +/*  MPEG-class control IDs specific to the MediaTek Decoder driver
> > as defined by V4L2 */
> > +#define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLAS
> > S_CODEC | 0x2000)
> > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_
> > MTK_BASE+8)
> > +
> >  /*  Camera class control IDs */
> >  
> >  #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA |
> > 0x900)
> 
> 

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Nicolas Dufresne]

Le mardi 12 septembre 2023 à 01:55 +0000, Yunfei Dong (董云飞) a écrit :
> Hi Nicolas,
> 
> Thanks for your advice.
> On Mon, 2023-09-11 at 11:47 -0400, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > User driver will fill or parse data in optee-os with secure handle,
> > > need to covert secure fd to secure handle in kernel.
> > 
> > A major rework of the wording is needed in this patchset, to fix the
> > obvious
> > typos like covert->convert, 
> I will fix in next patch.
> > but also to stop calling dmabuf allocated from
> > secure heap, secure fd, 
> Could you please help to explain it detail?
> Whether you meaning I can't
> call dma_buf_get/dma_buf_attach functions directly?

This is in regard to comments in the code. I'd suggest to use secure dmabuf fd
rather then just "secure fd", which is ambiguous.

> 
> > its not precise enough to understand what this patch is
> > going to be about.
> > 
> This patch is used to covert secure fd to secure handle.
> User space will get a secure fd using dma interface to allocate secure
> memory, but need to covert fd to handle in order to fill es
> buffer(output queue) in optee-os. I will write the commit message
> detail.

When you say "secure fd", it gives readers the impression you have introduced a
new concept of memory object in the linux kernel. In fact, these are dmabuf
object. My suggestion is to rework the accuracy of the naming and wording.

> 
> Best Regards,
> Yunfei Dong
> > > 
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > >  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
> > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54
> > > ++++++++++++++++++-
> > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
> > >  include/uapi/linux/v4l2-controls.h            |  4 ++
> > >  4 files changed, 62 insertions(+), 2 deletions(-)
> > > 
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > > .c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > > .c
> > > index 0a89ce452ac3..64e006820f43 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > > .c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv
> > > .c
> > > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> > >  
> > >  MODULE_LICENSE("GPL v2");
> > >  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > > +MODULE_IMPORT_NS(DMA_BUF);
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > index 2ea517883a86..d2b09ce9f1cf 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct
> > > mtk_vcodec_dec_ctx *ctx)
> > >  	return ret;
> > >  }
> > >  
> > > +static int mtk_dma_contig_get_secure_handle(struct
> > > mtk_vcodec_dec_ctx *ctx, int fd)
> > > +{
> > > +	int secure_handle = 0;
> > > +	struct dma_buf *buf;
> > > +	struct dma_buf_attachment *dba;
> > > +	struct sg_table *sgt;
> > > +	struct device *dev = &ctx->dev->plat_dev->dev;
> > > +
> > > +	buf = dma_buf_get(fd);
> > > +	if (IS_ERR(buf)) {
> > > +		mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > > +		return 0;
> > > +	}
> > > +
> > > +	dba = dma_buf_attach(buf, dev);
> > > +	if (IS_ERR(dba)) {
> > > +		mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d",
> > > fd);
> > > +		goto err_attach;
> > > +	}
> > > +
> > > +	sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > > +	if (IS_ERR(sgt)) {
> > > +		mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail
> > > fd:%d", fd);
> > > +		goto err_map;
> > > +	}
> > > +	secure_handle = sg_dma_address(sgt->sgl);
> > > +
> > > +	dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > > +	dma_buf_detach(buf, dba);
> > > +	dma_buf_put(buf);
> > > +
> > > +	return secure_handle;
> > > +err_map:
> > > +	dma_buf_detach(buf, dba);
> > > +err_attach:
> > > +	dma_buf_put(buf);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > >  {
> > >  	struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > > *ctrl)
> > >  	struct v4l2_ctrl *hdr_ctrl;
> > >  	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev-
> > > > vdec_pdata;
> > >  	const struct mtk_video_fmt *fmt;
> > > -	int i = 0, ret = 0;
> > > +	int i = 0, ret = 0, sec_fd;
> > >  
> > >  	hdr_ctrl = ctrl;
> > >  	if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > > *ctrl)
> > >  			return -EINVAL;
> > >  		}
> > >  		break;
> > > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > +		sec_fd = ctrl->val;
> > > +
> > > +		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl-
> > > > val);
> > > +		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d =>
> > > 0x%x", sec_fd, ctrl->val);
> > > +		break;
> > >  	default:
> > >  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl
> > > id: 0x%x\n", hdr_ctrl->id);
> > >  		return ret;
> > > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops
> > > mtk_vcodec_dec_ctrl_ops = {
> > >  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx
> > > *ctx)
> > >  {
> > >  	unsigned int i;
> > > +	struct v4l2_ctrl *ctrl;
> > >  
> > > -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > > +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > >  	if (ctx->ctrl_hdl.error) {
> > >  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init
> > > failed\n");
> > >  		return ctx->ctrl_hdl.error;
> > > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > mtk_vcodec_dec_ctx *ctx)
> > >  		}
> > >  	}
> > >  
> > > +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > &mtk_vcodec_dec_ctrl_ops,
> > > +				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE,
> > > 0, 65535, 1, 0);
> > > +
> > >  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > >  
> > >  	return 0;
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > index 8696eb1cdd61..d8cf01f76aab 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > >  	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return
> > > "HEVC Size of Length Field";
> > >  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return
> > > "Reference Frames for a P-Frame";
> > >  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		ret
> > > urn "Prepend SPS and PPS to IDR";
> > > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return
> > > "MediaTek Decoder get secure handle";
> > >  
> > >  	/* AV1 controls */
> > >  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			ret
> > > urn "AV1 Profile";
> > > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > > **name, enum v4l2_ctrl_type *type,
> > >  	case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> > >  		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
> > >  		break;
> > > +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > +		*type = V4L2_CTRL_TYPE_INTEGER;
> > > +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > +		break;
> > >  	case V4L2_CID_USER_CLASS:
> > >  	case V4L2_CID_CAMERA_CLASS:
> > >  	case V4L2_CID_CODEC_CLASS:
> > > diff --git a/include/uapi/linux/v4l2-controls.h
> > > b/include/uapi/linux/v4l2-controls.h
> > > index c3604a0a3e30..7b3694985366 100644
> > > --- a/include/uapi/linux/v4l2-controls.h
> > > +++ b/include/uapi/linux/v4l2-controls.h
> > > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		
> > > (V4L2_CID_CODEC_MFC51_BASE+53)
> > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		
> > > (V4L2_CID_CODEC_MFC51_BASE+54)
> > >  
> > > +/*  MPEG-class control IDs specific to the MediaTek Decoder driver
> > > as defined by V4L2 */
> > > +#define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLAS
> > > S_CODEC | 0x2000)
> > > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_
> > > MTK_BASE+8)
> > > +
> > >  /*  Camera class control IDs */
> > >  
> > >  #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA |
> > > 0x900)
> > 
> > 

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Nicolas Dufresne]

Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> User driver will fill or parse data in optee-os with secure handle,
> need to covert secure fd to secure handle in kernel.
> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
>  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
>  include/uapi/linux/v4l2-controls.h            |  4 ++
>  4 files changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> index 0a89ce452ac3..64e006820f43 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
>  
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> +MODULE_IMPORT_NS(DMA_BUF);
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index 2ea517883a86..d2b09ce9f1cf 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
>  	return ret;
>  }
>  
> +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> +{
> +	int secure_handle = 0;
> +	struct dma_buf *buf;
> +	struct dma_buf_attachment *dba;
> +	struct sg_table *sgt;
> +	struct device *dev = &ctx->dev->plat_dev->dev;
> +
> +	buf = dma_buf_get(fd);
> +	if (IS_ERR(buf)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> +		return 0;
> +	}
> +
> +	dba = dma_buf_attach(buf, dev);
> +	if (IS_ERR(dba)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> +		goto err_attach;
> +	}
> +
> +	sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> +	if (IS_ERR(sgt)) {
> +		mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> +		goto err_map;
> +	}
> +	secure_handle = sg_dma_address(sgt->sgl);

Does it mean if your secure dmabuf is passed to a driver that didn't know it was
secure it will pick the handle as a memory address and program the HW with it ?
That seems unsafe, the handle should be stored in a dedicated place and mapping
should either fail, or provide a dummy buffer.

> +
> +	dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> +	dma_buf_detach(buf, dba);
> +	dma_buf_put(buf);
> +
> +	return secure_handle;
> +err_map:
> +	dma_buf_detach(buf, dba);
> +err_attach:
> +	dma_buf_put(buf);
> +
> +	return 0;
> +}
> +
>  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  {
>  	struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  	struct v4l2_ctrl *hdr_ctrl;
>  	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
>  	const struct mtk_video_fmt *fmt;
> -	int i = 0, ret = 0;
> +	int i = 0, ret = 0, sec_fd;
>  
>  	hdr_ctrl = ctrl;
>  	if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  			return -EINVAL;
>  		}
>  		break;
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> +		sec_fd = ctrl->val;
> +
> +		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> +		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> +		break;
>  	default:
>  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
>  		return ret;
> @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
>  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  {
>  	unsigned int i;
> +	struct v4l2_ctrl *ctrl;
>  
> -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>  	if (ctx->ctrl_hdl.error) {
>  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>  		return ctx->ctrl_hdl.error;
> @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  		}
>  	}
>  
> +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> +				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> +
>  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>  
>  	return 0;
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> index 8696eb1cdd61..d8cf01f76aab 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>  	case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:	return "HEVC Size of Length Field";
>  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
>  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
>  
>  	/* AV1 controls */
>  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
> @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>  	case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
>  		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
>  		break;
> +	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> +		*type = V4L2_CTRL_TYPE_INTEGER;
> +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> +		break;
>  	case V4L2_CID_USER_CLASS:
>  	case V4L2_CID_CAMERA_CLASS:
>  	case V4L2_CID_CODEC_CLASS:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index c3604a0a3e30..7b3694985366 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		(V4L2_CID_CODEC_MFC51_BASE+53)
>  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		(V4L2_CID_CODEC_MFC51_BASE+54)
>  
> +/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> +#define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
> +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
> +
>  /*  Camera class control IDs */
>  
>  #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA | 0x900)

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Jeffrey Kardatzke]

On Tue, Sep 19, 2023 at 12:43 PM Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
>
> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > User driver will fill or parse data in optee-os with secure handle,
> > need to covert secure fd to secure handle in kernel.
> >
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> >  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
> >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
> >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
> >  include/uapi/linux/v4l2-controls.h            |  4 ++
> >  4 files changed, 62 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > index 0a89ce452ac3..64e006820f43 100644
> > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> >
> >  MODULE_LICENSE("GPL v2");
> >  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > +MODULE_IMPORT_NS(DMA_BUF);
> > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > index 2ea517883a86..d2b09ce9f1cf 100644
> > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
> >       return ret;
> >  }
> >
> > +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> > +{
> > +     int secure_handle = 0;
> > +     struct dma_buf *buf;
> > +     struct dma_buf_attachment *dba;
> > +     struct sg_table *sgt;
> > +     struct device *dev = &ctx->dev->plat_dev->dev;
> > +
> > +     buf = dma_buf_get(fd);
> > +     if (IS_ERR(buf)) {
> > +             mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > +             return 0;
> > +     }
> > +
> > +     dba = dma_buf_attach(buf, dev);
> > +     if (IS_ERR(dba)) {
> > +             mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> > +             goto err_attach;
> > +     }
> > +
> > +     sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > +     if (IS_ERR(sgt)) {
> > +             mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> > +             goto err_map;
> > +     }
> > +     secure_handle = sg_dma_address(sgt->sgl);
>
> Does it mean if your secure dmabuf is passed to a driver that didn't know it was
> secure it will pick the handle as a memory address and program the HW with it ?
> That seems unsafe, the handle should be stored in a dedicated place and mapping
> should either fail, or provide a dummy buffer.

Since the secure dmabufs don't support any mmap/cpu access to them and
return -EPERM in those cases; wouldn't that prevent misuse of them in
other places? (so the mmap operation and CPU access will fail, but
getting the SG list from the dmabuf succeeds)

>
> > +
> > +     dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > +     dma_buf_detach(buf, dba);
> > +     dma_buf_put(buf);
> > +
> > +     return secure_handle;
> > +err_map:
> > +     dma_buf_detach(buf, dba);
> > +err_attach:
> > +     dma_buf_put(buf);
> > +
> > +     return 0;
> > +}
> > +
> >  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> >  {
> >       struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> >       struct v4l2_ctrl *hdr_ctrl;
> >       const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
> >       const struct mtk_video_fmt *fmt;
> > -     int i = 0, ret = 0;
> > +     int i = 0, ret = 0, sec_fd;
> >
> >       hdr_ctrl = ctrl;
> >       if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> >                       return -EINVAL;
> >               }
> >               break;
> > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > +             sec_fd = ctrl->val;
> > +
> > +             ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > +             mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> > +             break;
> >       default:
> >               mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
> >               return ret;
> > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
> >  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> >  {
> >       unsigned int i;
> > +     struct v4l2_ctrl *ctrl;
> >
> > -     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > +     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >       if (ctx->ctrl_hdl.error) {
> >               mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >               return ctx->ctrl_hdl.error;
> > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> >               }
> >       }
> >
> > +     ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> > +                              V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > +
> >       v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >
> >       return 0;
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > index 8696eb1cdd61..d8cf01f76aab 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >       case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:     return "HEVC Size of Length Field";
> >       case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:        return "Reference Frames for a P-Frame";
> >       case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:         return "Prepend SPS and PPS to IDR";
> > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:               return "MediaTek Decoder get secure handle";
> >
> >       /* AV1 controls */
> >       case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:                   return "AV1 Profile";
> > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> >       case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> >               *type = V4L2_CTRL_TYPE_INTEGER_MENU;
> >               break;
> > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > +             *type = V4L2_CTRL_TYPE_INTEGER;
> > +             *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > +             break;
> >       case V4L2_CID_USER_CLASS:
> >       case V4L2_CID_CAMERA_CLASS:
> >       case V4L2_CID_CODEC_CLASS:
> > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > index c3604a0a3e30..7b3694985366 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC            (V4L2_CID_CODEC_MFC51_BASE+53)
> >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P             (V4L2_CID_CODEC_MFC51_BASE+54)
> >
> > +/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> > +#define V4L2_CID_MPEG_MTK_BASE                       (V4L2_CTRL_CLASS_CODEC | 0x2000)
> > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE  (V4L2_CID_MPEG_MTK_BASE+8)
> > +
> >  /*  Camera class control IDs */
> >
> >  #define V4L2_CID_CAMERA_CLASS_BASE   (V4L2_CTRL_CLASS_CAMERA | 0x900)
>

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Nicolas Dufresne]

Le mardi 19 septembre 2023 à 15:38 -0700, Jeffrey Kardatzke a écrit :
> On Tue, Sep 19, 2023 at 12:43 PM Nicolas Dufresne
> <nicolas.dufresne@collabora.com> wrote:
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > User driver will fill or parse data in optee-os with secure handle,
> > > need to covert secure fd to secure handle in kernel.
> > > 
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > >  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
> > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
> > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
> > >  include/uapi/linux/v4l2-controls.h            |  4 ++
> > >  4 files changed, 62 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > index 0a89ce452ac3..64e006820f43 100644
> > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> > > 
> > >  MODULE_LICENSE("GPL v2");
> > >  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > > +MODULE_IMPORT_NS(DMA_BUF);
> > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > index 2ea517883a86..d2b09ce9f1cf 100644
> > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
> > >       return ret;
> > >  }
> > > 
> > > +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> > > +{
> > > +     int secure_handle = 0;
> > > +     struct dma_buf *buf;
> > > +     struct dma_buf_attachment *dba;
> > > +     struct sg_table *sgt;
> > > +     struct device *dev = &ctx->dev->plat_dev->dev;
> > > +
> > > +     buf = dma_buf_get(fd);
> > > +     if (IS_ERR(buf)) {
> > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > > +             return 0;
> > > +     }
> > > +
> > > +     dba = dma_buf_attach(buf, dev);
> > > +     if (IS_ERR(dba)) {
> > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> > > +             goto err_attach;
> > > +     }
> > > +
> > > +     sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > > +     if (IS_ERR(sgt)) {
> > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> > > +             goto err_map;
> > > +     }
> > > +     secure_handle = sg_dma_address(sgt->sgl);
> > 
> > Does it mean if your secure dmabuf is passed to a driver that didn't know it was
> > secure it will pick the handle as a memory address and program the HW with it ?
> > That seems unsafe, the handle should be stored in a dedicated place and mapping
> > should either fail, or provide a dummy buffer.
> 
> Since the secure dmabufs don't support any mmap/cpu access to them and
> return -EPERM in those cases; wouldn't that prevent misuse of them in
> other places? (so the mmap operation and CPU access will fail, but
> getting the SG list from the dmabuf succeeds)

My impression is that if userspace can pass this FD to a driver without telling
the driver it is secure memory, the driver may potentially crash trying to use
the handle as an memory address.

In my opinion, sg_dma_address() should return addresses, like its name state. If
you want to get something else, you should find another way to obtain it.

Nicolas

> 
> > 
> > > +
> > > +     dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > > +     dma_buf_detach(buf, dba);
> > > +     dma_buf_put(buf);
> > > +
> > > +     return secure_handle;
> > > +err_map:
> > > +     dma_buf_detach(buf, dba);
> > > +err_attach:
> > > +     dma_buf_put(buf);
> > > +
> > > +     return 0;
> > > +}
> > > +
> > >  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > >  {
> > >       struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > >       struct v4l2_ctrl *hdr_ctrl;
> > >       const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
> > >       const struct mtk_video_fmt *fmt;
> > > -     int i = 0, ret = 0;
> > > +     int i = 0, ret = 0, sec_fd;
> > > 
> > >       hdr_ctrl = ctrl;
> > >       if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > >                       return -EINVAL;
> > >               }
> > >               break;
> > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > +             sec_fd = ctrl->val;
> > > +
> > > +             ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > > +             mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> > > +             break;
> > >       default:
> > >               mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
> > >               return ret;
> > > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
> > >  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > >  {
> > >       unsigned int i;
> > > +     struct v4l2_ctrl *ctrl;
> > > 
> > > -     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > > +     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > >       if (ctx->ctrl_hdl.error) {
> > >               mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > >               return ctx->ctrl_hdl.error;
> > > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > >               }
> > >       }
> > > 
> > > +     ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> > > +                              V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > +
> > >       v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > > 
> > >       return 0;
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > index 8696eb1cdd61..d8cf01f76aab 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > >       case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:     return "HEVC Size of Length Field";
> > >       case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:        return "Reference Frames for a P-Frame";
> > >       case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:         return "Prepend SPS and PPS to IDR";
> > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:               return "MediaTek Decoder get secure handle";
> > > 
> > >       /* AV1 controls */
> > >       case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:                   return "AV1 Profile";
> > > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > >       case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> > >               *type = V4L2_CTRL_TYPE_INTEGER_MENU;
> > >               break;
> > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > +             *type = V4L2_CTRL_TYPE_INTEGER;
> > > +             *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > +             break;
> > >       case V4L2_CID_USER_CLASS:
> > >       case V4L2_CID_CAMERA_CLASS:
> > >       case V4L2_CID_CODEC_CLASS:
> > > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > > index c3604a0a3e30..7b3694985366 100644
> > > --- a/include/uapi/linux/v4l2-controls.h
> > > +++ b/include/uapi/linux/v4l2-controls.h
> > > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC            (V4L2_CID_CODEC_MFC51_BASE+53)
> > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P             (V4L2_CID_CODEC_MFC51_BASE+54)
> > > 
> > > +/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> > > +#define V4L2_CID_MPEG_MTK_BASE                       (V4L2_CTRL_CLASS_CODEC | 0x2000)
> > > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE  (V4L2_CID_MPEG_MTK_BASE+8)
> > > +
> > >  /*  Camera class control IDs */
> > > 
> > >  #define V4L2_CID_CAMERA_CLASS_BASE   (V4L2_CTRL_CLASS_CAMERA | 0x900)
> > 

Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle

[Jeffrey Kardatzke]

I do agree having a cleaner mechanism for this is better. So ideally
this control is dropped from v4l2 and it becomes another ioctl in
dma-heap instead so there's a uAPI for it. Then for the driver usages
of sg_dma_address to get secure handles, those could be converted into
dma-buf heap kernel APIs so they're not trying to reuse the dma_addr.

On Tue, Sep 19, 2023 at 4:03 PM Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
>
> Le mardi 19 septembre 2023 à 15:38 -0700, Jeffrey Kardatzke a écrit :
> > On Tue, Sep 19, 2023 at 12:43 PM Nicolas Dufresne
> > <nicolas.dufresne@collabora.com> wrote:
> > >
> > > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > > User driver will fill or parse data in optee-os with secure handle,
> > > > need to covert secure fd to secure handle in kernel.
> > > >
> > > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > > ---
> > > >  .../vcodec/decoder/mtk_vcodec_dec_drv.c       |  1 +
> > > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
> > > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++
> > > >  include/uapi/linux/v4l2-controls.h            |  4 ++
> > > >  4 files changed, 62 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > > index 0a89ce452ac3..64e006820f43 100644
> > > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> > > >
> > > >  MODULE_LICENSE("GPL v2");
> > > >  MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > > > +MODULE_IMPORT_NS(DMA_BUF);
> > > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > > index 2ea517883a86..d2b09ce9f1cf 100644
> > > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
> > > >       return ret;
> > > >  }
> > > >
> > > > +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> > > > +{
> > > > +     int secure_handle = 0;
> > > > +     struct dma_buf *buf;
> > > > +     struct dma_buf_attachment *dba;
> > > > +     struct sg_table *sgt;
> > > > +     struct device *dev = &ctx->dev->plat_dev->dev;
> > > > +
> > > > +     buf = dma_buf_get(fd);
> > > > +     if (IS_ERR(buf)) {
> > > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > > > +             return 0;
> > > > +     }
> > > > +
> > > > +     dba = dma_buf_attach(buf, dev);
> > > > +     if (IS_ERR(dba)) {
> > > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> > > > +             goto err_attach;
> > > > +     }
> > > > +
> > > > +     sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > > > +     if (IS_ERR(sgt)) {
> > > > +             mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> > > > +             goto err_map;
> > > > +     }
> > > > +     secure_handle = sg_dma_address(sgt->sgl);
> > >
> > > Does it mean if your secure dmabuf is passed to a driver that didn't know it was
> > > secure it will pick the handle as a memory address and program the HW with it ?
> > > That seems unsafe, the handle should be stored in a dedicated place and mapping
> > > should either fail, or provide a dummy buffer.
> >
> > Since the secure dmabufs don't support any mmap/cpu access to them and
> > return -EPERM in those cases; wouldn't that prevent misuse of them in
> > other places? (so the mmap operation and CPU access will fail, but
> > getting the SG list from the dmabuf succeeds)
>
> My impression is that if userspace can pass this FD to a driver without telling
> the driver it is secure memory, the driver may potentially crash trying to use
> the handle as an memory address.
>
> In my opinion, sg_dma_address() should return addresses, like its name state. If
> you want to get something else, you should find another way to obtain it.
>
> Nicolas
>
> >
> > >
> > > > +
> > > > +     dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > > > +     dma_buf_detach(buf, dba);
> > > > +     dma_buf_put(buf);
> > > > +
> > > > +     return secure_handle;
> > > > +err_map:
> > > > +     dma_buf_detach(buf, dba);
> > > > +err_attach:
> > > > +     dma_buf_put(buf);
> > > > +
> > > > +     return 0;
> > > > +}
> > > > +
> > > >  static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > >  {
> > > >       struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > > > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > >       struct v4l2_ctrl *hdr_ctrl;
> > > >       const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
> > > >       const struct mtk_video_fmt *fmt;
> > > > -     int i = 0, ret = 0;
> > > > +     int i = 0, ret = 0, sec_fd;
> > > >
> > > >       hdr_ctrl = ctrl;
> > > >       if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > > > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > >                       return -EINVAL;
> > > >               }
> > > >               break;
> > > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > > +             sec_fd = ctrl->val;
> > > > +
> > > > +             ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > > > +             mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> > > > +             break;
> > > >       default:
> > > >               mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
> > > >               return ret;
> > > > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
> > > >  static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > > >  {
> > > >       unsigned int i;
> > > > +     struct v4l2_ctrl *ctrl;
> > > >
> > > > -     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > > > +     v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > >       if (ctx->ctrl_hdl.error) {
> > > >               mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > > >               return ctx->ctrl_hdl.error;
> > > > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > > >               }
> > > >       }
> > > >
> > > > +     ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> > > > +                              V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > > +
> > > >       v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > > >
> > > >       return 0;
> > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > index 8696eb1cdd61..d8cf01f76aab 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > > >       case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:     return "HEVC Size of Length Field";
> > > >       case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:        return "Reference Frames for a P-Frame";
> > > >       case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:         return "Prepend SPS and PPS to IDR";
> > > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:               return "MediaTek Decoder get secure handle";
> > > >
> > > >       /* AV1 controls */
> > > >       case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:                   return "AV1 Profile";
> > > > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > > >       case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> > > >               *type = V4L2_CTRL_TYPE_INTEGER_MENU;
> > > >               break;
> > > > +     case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > > +             *type = V4L2_CTRL_TYPE_INTEGER;
> > > > +             *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > > +             break;
> > > >       case V4L2_CID_USER_CLASS:
> > > >       case V4L2_CID_CAMERA_CLASS:
> > > >       case V4L2_CID_CODEC_CLASS:
> > > > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > > > index c3604a0a3e30..7b3694985366 100644
> > > > --- a/include/uapi/linux/v4l2-controls.h
> > > > +++ b/include/uapi/linux/v4l2-controls.h
> > > > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC            (V4L2_CID_CODEC_MFC51_BASE+53)
> > > >  #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P             (V4L2_CID_CODEC_MFC51_BASE+54)
> > > >
> > > > +/*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> > > > +#define V4L2_CID_MPEG_MTK_BASE                       (V4L2_CTRL_CLASS_CODEC | 0x2000)
> > > > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE  (V4L2_CID_MPEG_MTK_BASE+8)
> > > > +
> > > >  /*  Camera class control IDs */
> > > >
> > > >  #define V4L2_CID_CAMERA_CLASS_BASE   (V4L2_CTRL_CLASS_CAMERA | 0x900)
> > >
>

[PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong]

Setting secure mode flag to kernel when trying to play secure video,
then decoder driver will initialize tee related interface to support
svp.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15 ++++++++++++++-
 drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
 include/uapi/linux/v4l2-controls.h                |  1 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
index d2b09ce9f1cf..a981178c25d9 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
@@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
 		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
 		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
 		break;
+	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
+		ctx->is_svp_mode = ctrl->val;
+
+		if (ctx->is_svp_mode) {
+			ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
+			if (ret)
+				mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
+			else
+				mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl->val);
+		}
+		break;
 	default:
 		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
 		return ret;
@@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
 	unsigned int i;
 	struct v4l2_ctrl *ctrl;
 
-	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
+	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
 	if (ctx->ctrl_hdl.error) {
 		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
 		return ctx->ctrl_hdl.error;
@@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
 
 	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
 				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
+	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
+				 V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
 
 	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index d8cf01f76aab..a507045a3f30 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
 	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
 	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
+	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:			return "MediaTek Decoder set secure mode";
 
 	/* AV1 controls */
 	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
@@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 		*type = V4L2_CTRL_TYPE_INTEGER;
 		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
 		break;
+	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
+		*type = V4L2_CTRL_TYPE_INTEGER;
+		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
+		break;
 	case V4L2_CID_USER_CLASS:
 	case V4L2_CID_CAMERA_CLASS:
 	case V4L2_CID_CODEC_CLASS:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 7b3694985366..88e90d943e38 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
 /*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
 #define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
 #define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
+#define V4L2_CID_MPEG_MTK_SET_SECURE_MODE	(V4L2_CID_MPEG_MTK_BASE+9)
 
 /*  Camera class control IDs */
 
-- 
2.18.0

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Nicolas Dufresne]

Hi,

Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> Setting secure mode flag to kernel when trying to play secure video,
> then decoder driver will initialize tee related interface to support
> svp.


This is not what the patch is doing, please rework. This patch is an vendor API
addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should not have to
read your patch to understand this.

> 
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15 ++++++++++++++-
>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>  include/uapi/linux/v4l2-controls.h                |  1 +
>  3 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index d2b09ce9f1cf..a981178c25d9 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>  		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>  		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
>  		break;
> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:

Stepping back a little and focusing on the API, what makes your driver so
special that it should be the only one having a "secure mode" ? We are touching
in gap in the media pipeline in Linux, and this should come with consideration
of the global API.

Why is this API better then let's say Google Android one, were they expose 2
device nodes in their fork of the MFC driver (a secure and a non secure one) ?

regards,
Nicolas

p.s. you forgot to document your control in the RST doc, please do in following
release.

> +		ctx->is_svp_mode = ctrl->val;
> +
> +		if (ctx->is_svp_mode) {
> +			ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> +			if (ret)
> +				mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> +			else
> +				mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl->val);
> +		}
> +		break;
>  	default:
>  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
>  		return ret;
> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  	unsigned int i;
>  	struct v4l2_ctrl *ctrl;
>  
> -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>  	if (ctx->ctrl_hdl.error) {
>  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>  		return ctx->ctrl_hdl.error;
> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>  
>  	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
>  				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> +				 V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>  
>  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>  
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> index d8cf01f76aab..a507045a3f30 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
>  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
>  	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:			return "MediaTek Decoder set secure mode";
>  
>  	/* AV1 controls */
>  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>  		*type = V4L2_CTRL_TYPE_INTEGER;
>  		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>  		break;
> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> +		*type = V4L2_CTRL_TYPE_INTEGER;
> +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> +		break;
>  	case V4L2_CID_USER_CLASS:
>  	case V4L2_CID_CAMERA_CLASS:
>  	case V4L2_CID_CODEC_CLASS:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 7b3694985366..88e90d943e38 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>  /*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
>  #define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
>  #define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
> +#define V4L2_CID_MPEG_MTK_SET_SECURE_MODE	(V4L2_CID_MPEG_MTK_BASE+9)
>  
>  /*  Camera class control IDs */
>  

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong (董云飞)]

Hi Nicolas,

Thanks for your advice.

On Mon, 2023-09-11 at 11:54 -0400, Nicolas Dufresne wrote:
> Hi,
> 
> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > Setting secure mode flag to kernel when trying to play secure
> > video,
> > then decoder driver will initialize tee related interface to
> > support
> > svp.
> 
> 
> This is not what the patch is doing, please rework. This patch is an
> vendor API
> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should not
> have to
> read your patch to understand this.
> 
I don't know your meaning clearly. Whether I need to add one new patch
to add the definition of V4L2_CID_MPEG_MTK_SET_SECURE_MODE? Than the
driver calling it to set secure mode?

Best Regards,
Yunfei Dong

> > 
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> > ++++++++++++++-
> >  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >  include/uapi/linux/v4l2-controls.h                |  1 +
> >  3 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > index d2b09ce9f1cf..a981178c25d9 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > teless.c
> > @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > *ctrl)
> >  		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl-
> > >val);
> >  		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d =>
> > 0x%x", sec_fd, ctrl->val);
> >  		break;
> > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> 
> Stepping back a little and focusing on the API, what makes your
> driver so
> special that it should be the only one having a "secure mode" ? We
> are touching
> in gap in the media pipeline in Linux, and this should come with
> consideration
> of the global API.
> 
> Why is this API better then let's say Google Android one, were they
> expose 2
> device nodes in their fork of the MFC driver (a secure and a non
> secure one) ?
> 
> regards,
> Nicolas
> 
> p.s. you forgot to document your control in the RST doc, please do in
> following
> release.
> 
> > +		ctx->is_svp_mode = ctrl->val;
> > +
> > +		if (ctx->is_svp_mode) {
> > +			ret = mtk_vcodec_dec_optee_open(ctx->dev-
> > >optee_private);
> > +			if (ret)
> > +				mtk_v4l2_vdec_err(ctx, "open secure
> > mode failed.");
> > +			else
> > +				mtk_v4l2_vdec_dbg(3, ctx, "decoder in
> > secure mode: %d", ctrl->val);
> > +		}
> > +		break;
> >  	default:
> >  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl
> > id: 0x%x\n", hdr_ctrl->id);
> >  		return ret;
> > @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > mtk_vcodec_dec_ctx *ctx)
> >  	unsigned int i;
> >  	struct v4l2_ctrl *ctrl;
> >  
> > -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >  	if (ctx->ctrl_hdl.error) {
> >  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init
> > failed\n");
> >  		return ctx->ctrl_hdl.error;
> > @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > mtk_vcodec_dec_ctx *ctx)
> >  
> >  	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > &mtk_vcodec_dec_ctrl_ops,
> >  				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE,
> > 0, 65535, 1, 0);
> > +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > &mtk_vcodec_dec_ctrl_ops,
> > +				 V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0,
> > 65535, 1, 0);
> >  
> >  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >  
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > index d8cf01f76aab..a507045a3f30 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return
> > "Reference Frames for a P-Frame";
> >  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		ret
> > urn "Prepend SPS and PPS to IDR";
> >  	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return
> > "MediaTek Decoder get secure handle";
> > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:			ret
> > urn "MediaTek Decoder set secure mode";
> >  
> >  	/* AV1 controls */
> >  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			ret
> > urn "AV1 Profile";
> > @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > **name, enum v4l2_ctrl_type *type,
> >  		*type = V4L2_CTRL_TYPE_INTEGER;
> >  		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >  		break;
> > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > +		*type = V4L2_CTRL_TYPE_INTEGER;
> > +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > +		break;
> >  	case V4L2_CID_USER_CLASS:
> >  	case V4L2_CID_CAMERA_CLASS:
> >  	case V4L2_CID_CODEC_CLASS:
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 7b3694985366..88e90d943e38 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >  /*  MPEG-class control IDs specific to the MediaTek Decoder driver
> > as defined by V4L2 */
> >  #define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLAS
> > S_CODEC | 0x2000)
> >  #define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_
> > MTK_BASE+8)
> > +#define V4L2_CID_MPEG_MTK_SET_SECURE_MODE	(V4L2_CID_MPEG_MTK_BASE
> > +9)
> >  
> >  /*  Camera class control IDs */
> >  
> 
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Nicolas Dufresne]

Le mardi 12 septembre 2023 à 01:48 +0000, Yunfei Dong (董云飞) a écrit :
> Hi Nicolas,
> 
> Thanks for your advice.
> 
> On Mon, 2023-09-11 at 11:54 -0400, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > Setting secure mode flag to kernel when trying to play secure
> > > video,
> > > then decoder driver will initialize tee related interface to
> > > support
> > > svp.
> > 
> > 
> > This is not what the patch is doing, please rework. This patch is an
> > vendor API
> > addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should not
> > have to
> > read your patch to understand this.
> > 
> I don't know your meaning clearly. Whether I need to add one new patch
> to add the definition of V4L2_CID_MPEG_MTK_SET_SECURE_MODE? Than the
> driver calling it to set secure mode?

I'm commenting next to your commit message. The commit message is saying
something that does not represent what the patch is actually doing, please
rewrite your commit message according to good practices.

> 
> Best Regards,
> Yunfei Dong
> 
> > > 
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> > > ++++++++++++++-
> > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> > >  include/uapi/linux/v4l2-controls.h                |  1 +
> > >  3 files changed, 20 insertions(+), 1 deletion(-)
> > > 
> > > diff --git
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > index d2b09ce9f1cf..a981178c25d9 100644
> > > ---
> > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > +++
> > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_sta
> > > teless.c
> > > @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > > *ctrl)
> > >  		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl-
> > > > val);
> > >  		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d =>
> > > 0x%x", sec_fd, ctrl->val);
> > >  		break;
> > > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > 
> > Stepping back a little and focusing on the API, what makes your
> > driver so
> > special that it should be the only one having a "secure mode" ? We
> > are touching
> > in gap in the media pipeline in Linux, and this should come with
> > consideration
> > of the global API.
> > 
> > Why is this API better then let's say Google Android one, were they
> > expose 2
> > device nodes in their fork of the MFC driver (a secure and a non
> > secure one) ?
> > 
> > regards,
> > Nicolas
> > 
> > p.s. you forgot to document your control in the RST doc, please do in
> > following
> > release.
> > 
> > > +		ctx->is_svp_mode = ctrl->val;
> > > +
> > > +		if (ctx->is_svp_mode) {
> > > +			ret = mtk_vcodec_dec_optee_open(ctx->dev-
> > > > optee_private);
> > > +			if (ret)
> > > +				mtk_v4l2_vdec_err(ctx, "open secure
> > > mode failed.");
> > > +			else
> > > +				mtk_v4l2_vdec_dbg(3, ctx, "decoder in
> > > secure mode: %d", ctrl->val);
> > > +		}
> > > +		break;
> > >  	default:
> > >  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl
> > > id: 0x%x\n", hdr_ctrl->id);
> > >  		return ret;
> > > @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > mtk_vcodec_dec_ctx *ctx)
> > >  	unsigned int i;
> > >  	struct v4l2_ctrl *ctrl;
> > >  
> > > -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> > >  	if (ctx->ctrl_hdl.error) {
> > >  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init
> > > failed\n");
> > >  		return ctx->ctrl_hdl.error;
> > > @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > mtk_vcodec_dec_ctx *ctx)
> > >  
> > >  	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > &mtk_vcodec_dec_ctrl_ops,
> > >  				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE,
> > > 0, 65535, 1, 0);
> > > +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > &mtk_vcodec_dec_ctrl_ops,
> > > +				 V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0,
> > > 65535, 1, 0);
> > >  
> > >  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > >  
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > index d8cf01f76aab..a507045a3f30 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > >  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return
> > > "Reference Frames for a P-Frame";
> > >  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		ret
> > > urn "Prepend SPS and PPS to IDR";
> > >  	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return
> > > "MediaTek Decoder get secure handle";
> > > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:			ret
> > > urn "MediaTek Decoder set secure mode";
> > >  
> > >  	/* AV1 controls */
> > >  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			ret
> > > urn "AV1 Profile";
> > > @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > > **name, enum v4l2_ctrl_type *type,
> > >  		*type = V4L2_CTRL_TYPE_INTEGER;
> > >  		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > >  		break;
> > > +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > +		*type = V4L2_CTRL_TYPE_INTEGER;
> > > +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > +		break;
> > >  	case V4L2_CID_USER_CLASS:
> > >  	case V4L2_CID_CAMERA_CLASS:
> > >  	case V4L2_CID_CODEC_CLASS:
> > > diff --git a/include/uapi/linux/v4l2-controls.h
> > > b/include/uapi/linux/v4l2-controls.h
> > > index 7b3694985366..88e90d943e38 100644
> > > --- a/include/uapi/linux/v4l2-controls.h
> > > +++ b/include/uapi/linux/v4l2-controls.h
> > > @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > >  /*  MPEG-class control IDs specific to the MediaTek Decoder driver
> > > as defined by V4L2 */
> > >  #define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLAS
> > > S_CODEC | 0x2000)
> > >  #define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_
> > > MTK_BASE+8)
> > > +#define V4L2_CID_MPEG_MTK_SET_SECURE_MODE	(V4L2_CID_MPEG_MTK_BASE
> > > +9)
> > >  
> > >  /*  Camera class control IDs */
> > >  
> > 
> > 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

Hi,

On 9/11/23 17:54, Nicolas Dufresne wrote:
> Hi,
> 
> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>> Setting secure mode flag to kernel when trying to play secure video,
>> then decoder driver will initialize tee related interface to support
>> svp.
> 
> 
> This is not what the patch is doing, please rework. This patch is an vendor API
> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should not have to
> read your patch to understand this.
> 
>>
>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>> ---
>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15 ++++++++++++++-
>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
>> index d2b09ce9f1cf..a981178c25d9 100644
>> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
>> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
>>  		ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>  		mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
>>  		break;
>> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> 
> Stepping back a little and focusing on the API, what makes your driver so
> special that it should be the only one having a "secure mode" ? We are touching
> in gap in the media pipeline in Linux, and this should come with consideration
> of the global API.
> 
> Why is this API better then let's say Google Android one, were they expose 2
> device nodes in their fork of the MFC driver (a secure and a non secure one) ?

Perhaps it is a good idea to first post an RFC with an uAPI proposal on how to
handle secure video. I suspect this isn't mediatek specific, other SoCs with
tee support could use this as well.

As Nicolas said, it's long known to be a gap in our media support, so it is
really great that you started work on this, but you need to look at this from
a more generic point-of-view, and not mediatek-specific.

Regards,

	Hans

> 
> regards,
> Nicolas
> 
> p.s. you forgot to document your control in the RST doc, please do in following
> release.
> 
>> +		ctx->is_svp_mode = ctrl->val;
>> +
>> +		if (ctx->is_svp_mode) {
>> +			ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>> +			if (ret)
>> +				mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>> +			else
>> +				mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl->val);
>> +		}
>> +		break;
>>  	default:
>>  		mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
>>  		return ret;
>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>>  	unsigned int i;
>>  	struct v4l2_ctrl *ctrl;
>>  
>> -	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>> +	v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>  	if (ctx->ctrl_hdl.error) {
>>  		mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>  		return ctx->ctrl_hdl.error;
>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
>>  
>>  	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
>>  				 V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>> +	ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
>> +				 V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>  
>>  	v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>  
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>> index d8cf01f76aab..a507045a3f30 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>  	case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:	return "Reference Frames for a P-Frame";
>>  	case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:		return "Prepend SPS and PPS to IDR";
>>  	case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:		return "MediaTek Decoder get secure handle";
>> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:			return "MediaTek Decoder set secure mode";
>>  
>>  	/* AV1 controls */
>>  	case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:			return "AV1 Profile";
>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
>>  		*type = V4L2_CTRL_TYPE_INTEGER;
>>  		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>  		break;
>> +	case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>> +		*type = V4L2_CTRL_TYPE_INTEGER;
>> +		*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>> +		break;
>>  	case V4L2_CID_USER_CLASS:
>>  	case V4L2_CID_CAMERA_CLASS:
>>  	case V4L2_CID_CODEC_CLASS:
>> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
>> index 7b3694985366..88e90d943e38 100644
>> --- a/include/uapi/linux/v4l2-controls.h
>> +++ b/include/uapi/linux/v4l2-controls.h
>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>  /*  MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
>>  #define V4L2_CID_MPEG_MTK_BASE			(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>  #define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE	(V4L2_CID_MPEG_MTK_BASE+8)
>> +#define V4L2_CID_MPEG_MTK_SET_SECURE_MODE	(V4L2_CID_MPEG_MTK_BASE+9)
>>  
>>  /*  Camera class control IDs */
>>  
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong (董云飞)]

Hi Hans & Nicolas,

Thanks for your advice.

On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Hi,
> 
> On 9/11/23 17:54, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > Setting secure mode flag to kernel when trying to play secure
> 
> video,
> > > then decoder driver will initialize tee related interface to
> 
> support
> > > svp.
> > 
> > 
> > This is not what the patch is doing, please rework. This patch is
> 
> an vendor API
> > addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> 
> not have to
> > read your patch to understand this.
> > 
> > > 
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> 
> ++++++++++++++-
> > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> > >  include/uapi/linux/v4l2-controls.h                |  1 +
> > >  3 files changed, 20 insertions(+), 1 deletion(-)
> > > 
> > > diff --git
> 
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> > > index d2b09ce9f1cf..a981178c25d9 100644
> > > ---
> 
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> > > +++
> 
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> > > @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> 
> *ctrl)
> > >  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > >  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> 
> sec_fd, ctrl->val);
> > >  break;
> > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > 
> > Stepping back a little and focusing on the API, what makes your
> 
> driver so
> > special that it should be the only one having a "secure mode" ? We
> 
> are touching
> > in gap in the media pipeline in Linux, and this should come with
> 
> consideration
> > of the global API.
> > 
> > Why is this API better then let's say Google Android one, were they
> 
> expose 2
> > device nodes in their fork of the MFC driver (a secure and a non
> 
> secure one) ?
> 
> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> on how to
> handle secure video. I suspect this isn't mediatek specific, other
> SoCs with
> tee support could use this as well.
> 
> As Nicolas said, it's long known to be a gap in our media support, so
> it is
> really great that you started work on this, but you need to look at
> this from
> a more generic point-of-view, and not mediatek-specific.
> 

Whether your have any advice about how to do a more generic driver to
handle secure video playback?

There are several kind of buffer: output queue buffer/capture queue
buffer/working buffer.

output and capture queue buffer: user space will call tee related
interface to allocate secure handle. Will convert to secure handle with
v4l2 framework, then send secure handle to optee-os.

working buffer: calling dma_heap and dma_buf to get secure memory
handle, then covert secure iova in optee-os.

Using the same kernel driver for svp and non-svp playback, just the
buffer type are different. Normal is iova and secure is secure handle.

User driver will tell the kernel driver with CID control whether the
current playback is svp or non-svp.

Best Regards,
Yunfei Dong
> Regards,
> 
> Hans
> 
> > 
> > regards,
> > Nicolas
> > 
> > p.s. you forgot to document your control in the RST doc, please do
> 
> in following
> > release.
> > 
> > > +ctx->is_svp_mode = ctrl->val;
> > > +
> > > +if (ctx->is_svp_mode) {
> > > +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> > > +if (ret)
> > > +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> > > +else
> > > +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> > 
> > val);
> > > +}
> > > +break;
> > >  default:
> > >  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> > > 0x%x\n",
> 
> hdr_ctrl->id);
> > >  return ret;
> > > @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> 
> mtk_vcodec_dec_ctx *ctx)
> > >  unsigned int i;
> > >  struct v4l2_ctrl *ctrl;
> > >  
> > > -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> > >  if (ctx->ctrl_hdl.error) {
> > >  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > >  return ctx->ctrl_hdl.error;
> > > @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> 
> mtk_vcodec_dec_ctx *ctx)
> > >  
> > >  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> 
> &mtk_vcodec_dec_ctrl_ops,
> > >   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> 
> &mtk_vcodec_dec_ctrl_ops,
> > > + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> > >  
> > >  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > >  
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> 
> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > index d8cf01f76aab..a507045a3f30 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > >  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> > > "Reference
> 
> Frames for a P-Frame";
> > >  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> 
> SPS and PPS to IDR";
> > >  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> > > Decoder
> 
> get secure handle";
> > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> 
> set secure mode";
> > >  
> > >  /* AV1 controls */
> > >  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> > > @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> 
> **name, enum v4l2_ctrl_type *type,
> > >  *type = V4L2_CTRL_TYPE_INTEGER;
> > >  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > >  break;
> > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > +*type = V4L2_CTRL_TYPE_INTEGER;
> > > +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > +break;
> > >  case V4L2_CID_USER_CLASS:
> > >  case V4L2_CID_CAMERA_CLASS:
> > >  case V4L2_CID_CODEC_CLASS:
> > > diff --git a/include/uapi/linux/v4l2-controls.h
> 
> b/include/uapi/linux/v4l2-controls.h
> > > index 7b3694985366..88e90d943e38 100644
> > > --- a/include/uapi/linux/v4l2-controls.h
> > > +++ b/include/uapi/linux/v4l2-controls.h
> > > @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > >  /*  MPEG-class control IDs specific to the MediaTek Decoder
> 
> driver as defined by V4L2 */
> > >  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> > >  #define
> 
> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> > > +#define
> 
> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> > >  
> > >  /*  Camera class control IDs */
> > >  

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> Hi Hans & Nicolas,
> 
> Thanks for your advice.
> 
> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>>  	 
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>  Hi,
>>
>> On 9/11/23 17:54, Nicolas Dufresne wrote:
>>> Hi,
>>>
>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>>>> Setting secure mode flag to kernel when trying to play secure
>>
>> video,
>>>> then decoder driver will initialize tee related interface to
>>
>> support
>>>> svp.
>>>
>>>
>>> This is not what the patch is doing, please rework. This patch is
>>
>> an vendor API
>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
>>
>> not have to
>>> read your patch to understand this.
>>>
>>>>
>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>>>> ---
>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
>>
>> ++++++++++++++-
>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git
>>
>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>> less.c
>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>> less.c
>>>> index d2b09ce9f1cf..a981178c25d9 100644
>>>> ---
>>
>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>> less.c
>>>> +++
>>
>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>> less.c
>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
>>
>> *ctrl)
>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
>>
>> sec_fd, ctrl->val);
>>>>  break;
>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>
>>> Stepping back a little and focusing on the API, what makes your
>>
>> driver so
>>> special that it should be the only one having a "secure mode" ? We
>>
>> are touching
>>> in gap in the media pipeline in Linux, and this should come with
>>
>> consideration
>>> of the global API.
>>>
>>> Why is this API better then let's say Google Android one, were they
>>
>> expose 2
>>> device nodes in their fork of the MFC driver (a secure and a non
>>
>> secure one) ?
>>
>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
>> on how to
>> handle secure video. I suspect this isn't mediatek specific, other
>> SoCs with
>> tee support could use this as well.
>>
>> As Nicolas said, it's long known to be a gap in our media support, so
>> it is
>> really great that you started work on this, but you need to look at
>> this from
>> a more generic point-of-view, and not mediatek-specific.
>>
> 
> Whether your have any advice about how to do a more generic driver to
> handle secure video playback?
> 
> There are several kind of buffer: output queue buffer/capture queue
> buffer/working buffer.
> 
> output and capture queue buffer: user space will call tee related
> interface to allocate secure handle. Will convert to secure handle with
> v4l2 framework, then send secure handle to optee-os.
> 
> working buffer: calling dma_heap and dma_buf to get secure memory
> handle, then covert secure iova in optee-os.
> 
> Using the same kernel driver for svp and non-svp playback, just the
> buffer type are different. Normal is iova and secure is secure handle.
> 
> User driver will tell the kernel driver with CID control whether the
> current playback is svp or non-svp.

My understanding is that when you switch to secure mode, the driver makes
some optee calls to set everything up. And userspace needs a way convert a
dmabuf fd to a 'secure handle', which appears to be the DMA address of the
buffer. Who uses that handle?

In any case, using a control to switch to secure mode and using a control
to convert a dmabuf fd to a secure handle seems a poor choice to me.

I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
once you create buffers for the first time, the driver can switch into secure
mode, and until all buffers are released again you know that the driver will
stay in secure mode.

For converting the dmabuf fd into a secure handle: a new ioctl similar to
VIDIOC_EXPBUF might be more suited for that.

Note that I am the first to admit that I have no experience with secure
video pipelines or optee-os, so I am looking at this purely from an uAPI
perspective.

Regards,

	Hans

> 
> Best Regards,
> Yunfei Dong
>> Regards,
>>
>> Hans
>>
>>>
>>> regards,
>>> Nicolas
>>>
>>> p.s. you forgot to document your control in the RST doc, please do
>>
>> in following
>>> release.
>>>
>>>> +ctx->is_svp_mode = ctrl->val;
>>>> +
>>>> +if (ctx->is_svp_mode) {
>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>>>> +if (ret)
>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>>>> +else
>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
>>>
>>> val);
>>>> +}
>>>> +break;
>>>>  default:
>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
>>>> 0x%x\n",
>>
>> hdr_ctrl->id);
>>>>  return ret;
>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>
>> mtk_vcodec_dec_ctx *ctx)
>>>>  unsigned int i;
>>>>  struct v4l2_ctrl *ctrl;
>>>>  
>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>>>  if (ctx->ctrl_hdl.error) {
>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>>>  return ctx->ctrl_hdl.error;
>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>
>> mtk_vcodec_dec_ctx *ctx)
>>>>  
>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>
>> &mtk_vcodec_dec_ctrl_ops,
>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>
>> &mtk_vcodec_dec_ctrl_ops,
>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>>>  
>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>>>  
>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>
>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>> index d8cf01f76aab..a507045a3f30 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
>>>> "Reference
>>
>> Frames for a P-Frame";
>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
>>
>> SPS and PPS to IDR";
>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
>>>> Decoder
>>
>> get secure handle";
>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
>>
>> set secure mode";
>>>>  
>>>>  /* AV1 controls */
>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
>>
>> **name, enum v4l2_ctrl_type *type,
>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>  break;
>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>> +break;
>>>>  case V4L2_CID_USER_CLASS:
>>>>  case V4L2_CID_CAMERA_CLASS:
>>>>  case V4L2_CID_CODEC_CLASS:
>>>> diff --git a/include/uapi/linux/v4l2-controls.h
>>
>> b/include/uapi/linux/v4l2-controls.h
>>>> index 7b3694985366..88e90d943e38 100644
>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
>>
>> driver as defined by V4L2 */
>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>>>  #define
>>
>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
>>>> +#define
>>
>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
>>>>  
>>>>  /*  Camera class control IDs */
>>>>  

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong (董云飞)]

Hi Hans,

Thanks for your advice.
On Fri, 2023-09-15 at 10:54 +0200, Hans Verkuil wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> > Hi Hans & Nicolas,
> > 
> > Thanks for your advice.
> > 
> > On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> >>   
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >>  Hi,
> >>
> >> On 9/11/23 17:54, Nicolas Dufresne wrote:
> >>> Hi,
> >>>
> >>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >>>> Setting secure mode flag to kernel when trying to play secure
> >>
> >> video,
> >>>> then decoder driver will initialize tee related interface to
> >>
> >> support
> >>>> svp.
> >>>
> >>>
> >>> This is not what the patch is doing, please rework. This patch is
> >>
> >> an vendor API
> >>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> >>
> >> not have to
> >>> read your patch to understand this.
> >>>
> >>>>
> >>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >>>> ---
> >>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> >>
> >> ++++++++++++++-
> >>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>>>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>>>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git
> >>
> >>
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> index d2b09ce9f1cf..a981178c25d9 100644
> >>>> ---
> >>
> >>
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> +++
> >>
> >>
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> >>
> >> *ctrl)
> >>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> >>
> >> sec_fd, ctrl->val);
> >>>>  break;
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>
> >>> Stepping back a little and focusing on the API, what makes your
> >>
> >> driver so
> >>> special that it should be the only one having a "secure mode" ?
> We
> >>
> >> are touching
> >>> in gap in the media pipeline in Linux, and this should come with
> >>
> >> consideration
> >>> of the global API.
> >>>
> >>> Why is this API better then let's say Google Android one, were
> they
> >>
> >> expose 2
> >>> device nodes in their fork of the MFC driver (a secure and a non
> >>
> >> secure one) ?
> >>
> >> Perhaps it is a good idea to first post an RFC with an uAPI
> proposal
> >> on how to
> >> handle secure video. I suspect this isn't mediatek specific, other
> >> SoCs with
> >> tee support could use this as well.
> >>
> >> As Nicolas said, it's long known to be a gap in our media support,
> so
> >> it is
> >> really great that you started work on this, but you need to look
> at
> >> this from
> >> a more generic point-of-view, and not mediatek-specific.
> >>
> > 
> > Whether your have any advice about how to do a more generic driver
> to
> > handle secure video playback?
> > 
> > There are several kind of buffer: output queue buffer/capture queue
> > buffer/working buffer.
> > 
> > output and capture queue buffer: user space will call tee related
> > interface to allocate secure handle. Will convert to secure handle
> with
> > v4l2 framework, then send secure handle to optee-os.
> > 
> > working buffer: calling dma_heap and dma_buf to get secure memory
> > handle, then covert secure iova in optee-os.
> > 
> > Using the same kernel driver for svp and non-svp playback, just the
> > buffer type are different. Normal is iova and secure is secure
> handle.
> > 
> > User driver will tell the kernel driver with CID control whether
> the
> > current playback is svp or non-svp.
> 
> My understanding is that when you switch to secure mode, the driver
> makes
> some optee calls to set everything up. And userspace needs a way
> convert a
> dmabuf fd to a 'secure handle', which appears to be the DMA address
> of the
> buffer. Who uses that handle?
> 
User space need to get/set information for some secure memory with dma
secure handle, such as input buffer/frame buffer/tmp buffer, etc.
Secure fd will convert to secure handle in kernel space then in optee-
os in user space.
> In any case, using a control to switch to secure mode and using a
> control
> to convert a dmabuf fd to a secure handle seems a poor choice to me.
> 
> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_
> type,
> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> ensures that
> once you create buffers for the first time, the driver can switch
> into secure
> mode, and until all buffers are released again you know that the
> driver will
> stay in secure mode.
> 
It's no need to add V4L2_MEMORY_DMABUF_SECURE, v4l2 framewrok can
convert secure fd to secure handle directly for VB2_MEMROY_DMABUF.
User space will queue capture and output buffer, then calling
vb2_dma_contig_plane_dma_addr to get secure handle for secure mode,
getting iova for normal playback.

If the driver want to use memory type MMAP, maybe need to add
VB2_MEMROY_MMAP_SECURE.

> For converting the dmabuf fd into a secure handle: a new ioctl
> similar to
> VIDIOC_EXPBUF might be more suited for that.
> 
> Note that I am the first to admit that I have no experience with
> secure
> video pipelines or optee-os, so I am looking at this purely from an
> uAPI
> perspective.
> 
It's a good choice to convert secure fd to secure handle with a new
ioctl callback, will call the ioctl many times for there are many
buffers. If the driver in secure fd to secure handler callback, the
driver regard the playback is secure mode?

Best Regards,
Yunfei Dong
> Regards,
> 
> Hans
> 
> > 
> > Best Regards,
> > Yunfei Dong
> >> Regards,
> >>
> >> Hans
> >>
> >>>
> >>> regards,
> >>> Nicolas
> >>>
> >>> p.s. you forgot to document your control in the RST doc, please
> do
> >>
> >> in following
> >>> release.
> >>>
> >>>> +ctx->is_svp_mode = ctrl->val;
> >>>> +
> >>>> +if (ctx->is_svp_mode) {
> >>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>> +if (ret)
> >>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>> +else
> >>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >>>
> >>> val);
> >>>> +}
> >>>> +break;
> >>>>  default:
> >>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>> 0x%x\n",
> >>
> >> hdr_ctrl->id);
> >>>>  return ret;
> >>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>
> >> mtk_vcodec_dec_ctx *ctx)
> >>>>  unsigned int i;
> >>>>  struct v4l2_ctrl *ctrl;
> >>>>  
> >>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>  if (ctx->ctrl_hdl.error) {
> >>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>  return ctx->ctrl_hdl.error;
> >>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>
> >> mtk_vcodec_dec_ctx *ctx)
> >>>>  
> >>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>
> >> &mtk_vcodec_dec_ctrl_ops,
> >>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>
> >> &mtk_vcodec_dec_ctrl_ops,
> >>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>  
> >>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>  
> >>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>
> >> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> index d8cf01f76aab..a507045a3f30 100644
> >>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>> "Reference
> >>
> >> Frames for a P-Frame";
> >>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> >>
> >> SPS and PPS to IDR";
> >>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>> Decoder
> >>
> >> get secure handle";
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> >>
> >> set secure mode";
> >>>>  
> >>>>  /* AV1 controls */
> >>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> >>
> >> **name, enum v4l2_ctrl_type *type,
> >>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>  break;
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>> +break;
> >>>>  case V4L2_CID_USER_CLASS:
> >>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>  case V4L2_CID_CODEC_CLASS:
> >>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>
> >> b/include/uapi/linux/v4l2-controls.h
> >>>> index 7b3694985366..88e90d943e38 100644
> >>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type
> {
> >>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>
> >> driver as defined by V4L2 */
> >>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>>>  #define
> >>
> >> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>> +#define
> >>
> >> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>  
> >>>>  /*  Camera class control IDs */
> >>>>  
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> > Hi Hans & Nicolas,
> >
> > Thanks for your advice.
> >
> > On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> >>
> >> External email : Please do not click links or open attachments until
> >> you have verified the sender or the content.
> >>  Hi,
> >>
> >> On 9/11/23 17:54, Nicolas Dufresne wrote:
> >>> Hi,
> >>>
> >>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >>>> Setting secure mode flag to kernel when trying to play secure
> >>
> >> video,
> >>>> then decoder driver will initialize tee related interface to
> >>
> >> support
> >>>> svp.
> >>>
> >>>
> >>> This is not what the patch is doing, please rework. This patch is
> >>
> >> an vendor API
> >>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> >>
> >> not have to
> >>> read your patch to understand this.
> >>>
> >>>>
> >>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >>>> ---
> >>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> >>
> >> ++++++++++++++-
> >>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>>>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>>>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git
> >>
> >> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> index d2b09ce9f1cf..a981178c25d9 100644
> >>>> ---
> >>
> >> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> +++
> >>
> >> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >> less.c
> >>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> >>
> >> *ctrl)
> >>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> >>
> >> sec_fd, ctrl->val);
> >>>>  break;
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>
> >>> Stepping back a little and focusing on the API, what makes your
> >>
> >> driver so
> >>> special that it should be the only one having a "secure mode" ? We
> >>
> >> are touching
> >>> in gap in the media pipeline in Linux, and this should come with
> >>
> >> consideration
> >>> of the global API.
> >>>
> >>> Why is this API better then let's say Google Android one, were they
> >>
> >> expose 2
> >>> device nodes in their fork of the MFC driver (a secure and a non
> >>
> >> secure one) ?
> >>
> >> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> >> on how to
> >> handle secure video. I suspect this isn't mediatek specific, other
> >> SoCs with
> >> tee support could use this as well.
> >>
> >> As Nicolas said, it's long known to be a gap in our media support, so
> >> it is
> >> really great that you started work on this, but you need to look at
> >> this from
> >> a more generic point-of-view, and not mediatek-specific.
> >>
> >
> > Whether your have any advice about how to do a more generic driver to
> > handle secure video playback?
> >
> > There are several kind of buffer: output queue buffer/capture queue
> > buffer/working buffer.
> >
> > output and capture queue buffer: user space will call tee related
> > interface to allocate secure handle. Will convert to secure handle with
> > v4l2 framework, then send secure handle to optee-os.
> >
> > working buffer: calling dma_heap and dma_buf to get secure memory
> > handle, then covert secure iova in optee-os.
> >
> > Using the same kernel driver for svp and non-svp playback, just the
> > buffer type are different. Normal is iova and secure is secure handle.
> >
> > User driver will tell the kernel driver with CID control whether the
> > current playback is svp or non-svp.
>
> My understanding is that when you switch to secure mode, the driver makes
> some optee calls to set everything up. And userspace needs a way convert a
> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> buffer. Who uses that handle?

The only user space usage for getting the 'secure handle' from an fd
is when that memory is written to. This is done when the TEE decrypts
the video contents. User space sends the encrypted video + 'secure
handle' to the TEE, and the TEE decrypts the contents to the memory
associated with the 'secure handle'. Then the 'secure handle' is
passed into the TEE again with the v4l2 driver to use as the source
for video decoding (but w/ v4l2, user space is passing in fds).

>
> In any case, using a control to switch to secure mode and using a control
> to convert a dmabuf fd to a secure handle seems a poor choice to me.
>
> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> once you create buffers for the first time, the driver can switch into secure
> mode, and until all buffers are released again you know that the driver will
> stay in secure mode.

Why do you think the control for setting secure mode is a poor choice?
There's various places in the driver code where functionality changes
based on being secure/non-secure mode, so this is very much a 'global'
setting for the driver. It could be inferred based off a new memory
type for the queues...which then sets that flag in the driver; but
that seems like it would be more fragile and would require checking
for incompatible output/capture memory types. I'm not against another
way of doing this; but didn't see why you think the proposed method is
a poor choice.

>
> For converting the dmabuf fd into a secure handle: a new ioctl similar to
> VIDIOC_EXPBUF might be more suited for that.

I actually think the best way for converting the dmabuf fd into a
secure handle would be another ioctl in the dma-heap driver...since
that's where the memory is actually allocated from. But this really
depends on upstream maintainers and what they are comfortable with.

>
> Note that I am the first to admit that I have no experience with secure
> video pipelines or optee-os, so I am looking at this purely from an uAPI
> perspective.
>
> Regards,
>
>         Hans
>
> >
> > Best Regards,
> > Yunfei Dong
> >> Regards,
> >>
> >> Hans
> >>
> >>>
> >>> regards,
> >>> Nicolas
> >>>
> >>> p.s. you forgot to document your control in the RST doc, please do
> >>
> >> in following
> >>> release.
> >>>
> >>>> +ctx->is_svp_mode = ctrl->val;
> >>>> +
> >>>> +if (ctx->is_svp_mode) {
> >>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>> +if (ret)
> >>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>> +else
> >>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >>>
> >>> val);
> >>>> +}
> >>>> +break;
> >>>>  default:
> >>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>> 0x%x\n",
> >>
> >> hdr_ctrl->id);
> >>>>  return ret;
> >>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>
> >> mtk_vcodec_dec_ctx *ctx)
> >>>>  unsigned int i;
> >>>>  struct v4l2_ctrl *ctrl;
> >>>>
> >>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>  if (ctx->ctrl_hdl.error) {
> >>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>  return ctx->ctrl_hdl.error;
> >>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>
> >> mtk_vcodec_dec_ctx *ctx)
> >>>>
> >>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>
> >> &mtk_vcodec_dec_ctrl_ops,
> >>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>
> >> &mtk_vcodec_dec_ctrl_ops,
> >>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>
> >>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>
> >>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>
> >> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> index d8cf01f76aab..a507045a3f30 100644
> >>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>> "Reference
> >>
> >> Frames for a P-Frame";
> >>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> >>
> >> SPS and PPS to IDR";
> >>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>> Decoder
> >>
> >> get secure handle";
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> >>
> >> set secure mode";
> >>>>
> >>>>  /* AV1 controls */
> >>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> >>
> >> **name, enum v4l2_ctrl_type *type,
> >>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>  break;
> >>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>> +break;
> >>>>  case V4L2_CID_USER_CLASS:
> >>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>  case V4L2_CID_CODEC_CLASS:
> >>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>
> >> b/include/uapi/linux/v4l2-controls.h
> >>>> index 7b3694985366..88e90d943e38 100644
> >>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>
> >> driver as defined by V4L2 */
> >>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>>>  #define
> >>
> >> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>> +#define
> >>
> >> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>
> >>>>  /*  Camera class control IDs */
> >>>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>
>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
>>> Hi Hans & Nicolas,
>>>
>>> Thanks for your advice.
>>>
>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>>>>
>>>> External email : Please do not click links or open attachments until
>>>> you have verified the sender or the content.
>>>>  Hi,
>>>>
>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
>>>>> Hi,
>>>>>
>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>>>>>> Setting secure mode flag to kernel when trying to play secure
>>>>
>>>> video,
>>>>>> then decoder driver will initialize tee related interface to
>>>>
>>>> support
>>>>>> svp.
>>>>>
>>>>>
>>>>> This is not what the patch is doing, please rework. This patch is
>>>>
>>>> an vendor API
>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
>>>>
>>>> not have to
>>>>> read your patch to understand this.
>>>>>
>>>>>>
>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>>>>>> ---
>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
>>>>
>>>> ++++++++++++++-
>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git
>>>>
>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>> less.c
>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>> less.c
>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
>>>>>> ---
>>>>
>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>> less.c
>>>>>> +++
>>>>
>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>> less.c
>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
>>>>
>>>> *ctrl)
>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
>>>>
>>>> sec_fd, ctrl->val);
>>>>>>  break;
>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>
>>>>> Stepping back a little and focusing on the API, what makes your
>>>>
>>>> driver so
>>>>> special that it should be the only one having a "secure mode" ? We
>>>>
>>>> are touching
>>>>> in gap in the media pipeline in Linux, and this should come with
>>>>
>>>> consideration
>>>>> of the global API.
>>>>>
>>>>> Why is this API better then let's say Google Android one, were they
>>>>
>>>> expose 2
>>>>> device nodes in their fork of the MFC driver (a secure and a non
>>>>
>>>> secure one) ?
>>>>
>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
>>>> on how to
>>>> handle secure video. I suspect this isn't mediatek specific, other
>>>> SoCs with
>>>> tee support could use this as well.
>>>>
>>>> As Nicolas said, it's long known to be a gap in our media support, so
>>>> it is
>>>> really great that you started work on this, but you need to look at
>>>> this from
>>>> a more generic point-of-view, and not mediatek-specific.
>>>>
>>>
>>> Whether your have any advice about how to do a more generic driver to
>>> handle secure video playback?
>>>
>>> There are several kind of buffer: output queue buffer/capture queue
>>> buffer/working buffer.
>>>
>>> output and capture queue buffer: user space will call tee related
>>> interface to allocate secure handle. Will convert to secure handle with
>>> v4l2 framework, then send secure handle to optee-os.
>>>
>>> working buffer: calling dma_heap and dma_buf to get secure memory
>>> handle, then covert secure iova in optee-os.
>>>
>>> Using the same kernel driver for svp and non-svp playback, just the
>>> buffer type are different. Normal is iova and secure is secure handle.
>>>
>>> User driver will tell the kernel driver with CID control whether the
>>> current playback is svp or non-svp.
>>
>> My understanding is that when you switch to secure mode, the driver makes
>> some optee calls to set everything up. And userspace needs a way convert a
>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
>> buffer. Who uses that handle?
> 
> The only user space usage for getting the 'secure handle' from an fd
> is when that memory is written to. This is done when the TEE decrypts
> the video contents. User space sends the encrypted video + 'secure
> handle' to the TEE, and the TEE decrypts the contents to the memory
> associated with the 'secure handle'. Then the 'secure handle' is
> passed into the TEE again with the v4l2 driver to use as the source
> for video decoding (but w/ v4l2, user space is passing in fds).

I think I need some more background. This series is to support a 'Secure Video
Processor' (at least, that's what svp stands for I believe, something that
is not mentioned anywhere in this series, BTW) which is used to decode an
encrypted h264 stream.

First question: how is that stream encrypted? Is that according to some standard?
Nothing is mentioned about that.

I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
in the output buffer and queue it to the codec), nothing special is needed for that.
Except, how does the hardware know it is encrypted? I guess that's where the
control comes in, you have to turn on SVP mode first.

For the capture buffers you need to provide buffers from secure/trusted memory.
That's a dmabuf fd, but where does that come from?

I saw this message:

https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u

so I expect that's where it comes from. But I agree that getting this from dma-heaps
seems more natural.

I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')

For actually displaying these secure buffers you would use drm, and I assume that
the hardware would mix in the contents of the secure buffer into the video output
pipeline? I.e., the actual contents remain inaccessible. And that the video output
(HDMI or DisplayPort) is using HDCP?

> 
>>
>> In any case, using a control to switch to secure mode and using a control
>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
>>
>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
>> once you create buffers for the first time, the driver can switch into secure
>> mode, and until all buffers are released again you know that the driver will
>> stay in secure mode.
> 
> Why do you think the control for setting secure mode is a poor choice?
> There's various places in the driver code where functionality changes
> based on being secure/non-secure mode, so this is very much a 'global'
> setting for the driver. It could be inferred based off a new memory
> type for the queues...which then sets that flag in the driver; but
> that seems like it would be more fragile and would require checking
> for incompatible output/capture memory types. I'm not against another
> way of doing this; but didn't see why you think the proposed method is
> a poor choice.

I assume you are either decoding to secure memory all the time, or not
at all. That's something you would want to select the moment you allocate
the first buffer. Using the V4L2_MEMORY_ value would be the natural place
for that. A control can typically be toggled at any time, and it makes
no sense to do that for secure streaming.

Related to that: if you pass a dmabuf fd you will need to check somewhere
if the fd points to secure memory or not. You don't want to mix the two
but you want to check that at VIDIOC_QBUF time.

Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
drivers do not need to do that.

> 
>>
>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
>> VIDIOC_EXPBUF might be more suited for that.
> 
> I actually think the best way for converting the dmabuf fd into a
> secure handle would be another ioctl in the dma-heap driver...since
> that's where the memory is actually allocated from. But this really
> depends on upstream maintainers and what they are comfortable with.

That feels like a more natural place of doing this.

Regards,

	Hans

> 
>>
>> Note that I am the first to admit that I have no experience with secure
>> video pipelines or optee-os, so I am looking at this purely from an uAPI
>> perspective.
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>> Best Regards,
>>> Yunfei Dong
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>>
>>>>> regards,
>>>>> Nicolas
>>>>>
>>>>> p.s. you forgot to document your control in the RST doc, please do
>>>>
>>>> in following
>>>>> release.
>>>>>
>>>>>> +ctx->is_svp_mode = ctrl->val;
>>>>>> +
>>>>>> +if (ctx->is_svp_mode) {
>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>>>>>> +if (ret)
>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>>>>>> +else
>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
>>>>>
>>>>> val);
>>>>>> +}
>>>>>> +break;
>>>>>>  default:
>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
>>>>>> 0x%x\n",
>>>>
>>>> hdr_ctrl->id);
>>>>>>  return ret;
>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>
>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>  unsigned int i;
>>>>>>  struct v4l2_ctrl *ctrl;
>>>>>>
>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>>>>>  if (ctx->ctrl_hdl.error) {
>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>>>>>  return ctx->ctrl_hdl.error;
>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>
>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>
>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>
>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>
>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>>>>>
>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>>>>>
>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>
>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>> index d8cf01f76aab..a507045a3f30 100644
>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
>>>>>> "Reference
>>>>
>>>> Frames for a P-Frame";
>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
>>>>
>>>> SPS and PPS to IDR";
>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
>>>>>> Decoder
>>>>
>>>> get secure handle";
>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
>>>>
>>>> set secure mode";
>>>>>>
>>>>>>  /* AV1 controls */
>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
>>>>
>>>> **name, enum v4l2_ctrl_type *type,
>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>  break;
>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>> +break;
>>>>>>  case V4L2_CID_USER_CLASS:
>>>>>>  case V4L2_CID_CAMERA_CLASS:
>>>>>>  case V4L2_CID_CODEC_CLASS:
>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
>>>>
>>>> b/include/uapi/linux/v4l2-controls.h
>>>>>> index 7b3694985366..88e90d943e38 100644
>>>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
>>>>
>>>> driver as defined by V4L2 */
>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>>>>>  #define
>>>>
>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
>>>>>> +#define
>>>>
>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
>>>>>>
>>>>>>  /*  Camera class control IDs */
>>>>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Nicolas Dufresne]

Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> > On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> > > 
> > > On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> > > > Hi Hans & Nicolas,
> > > > 
> > > > Thanks for your advice.
> > > > 
> > > > On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> > > > > 
> > > > > External email : Please do not click links or open attachments until
> > > > > you have verified the sender or the content.
> > > > >  Hi,
> > > > > 
> > > > > On 9/11/23 17:54, Nicolas Dufresne wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > > > > > Setting secure mode flag to kernel when trying to play secure
> > > > > 
> > > > > video,
> > > > > > > then decoder driver will initialize tee related interface to
> > > > > 
> > > > > support
> > > > > > > svp.
> > > > > > 
> > > > > > 
> > > > > > This is not what the patch is doing, please rework. This patch is
> > > > > 
> > > > > an vendor API
> > > > > > addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> > > > > 
> > > > > not have to
> > > > > > read your patch to understand this.
> > > > > > 
> > > > > > > 
> > > > > > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > > > > > ---
> > > > > > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> > > > > 
> > > > > ++++++++++++++-
> > > > > > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> > > > > > >  include/uapi/linux/v4l2-controls.h                |  1 +
> > > > > > >  3 files changed, 20 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git
> > > > > 
> > > > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > less.c
> > > > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > less.c
> > > > > > > index d2b09ce9f1cf..a981178c25d9 100644
> > > > > > > ---
> > > > > 
> > > > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > less.c
> > > > > > > +++
> > > > > 
> > > > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > less.c
> > > > > > > @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > > > > 
> > > > > *ctrl)
> > > > > > >  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > > > > > >  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> > > > > 
> > > > > sec_fd, ctrl->val);
> > > > > > >  break;
> > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > > > > 
> > > > > > Stepping back a little and focusing on the API, what makes your
> > > > > 
> > > > > driver so
> > > > > > special that it should be the only one having a "secure mode" ? We
> > > > > 
> > > > > are touching
> > > > > > in gap in the media pipeline in Linux, and this should come with
> > > > > 
> > > > > consideration
> > > > > > of the global API.
> > > > > > 
> > > > > > Why is this API better then let's say Google Android one, were they
> > > > > 
> > > > > expose 2
> > > > > > device nodes in their fork of the MFC driver (a secure and a non
> > > > > 
> > > > > secure one) ?
> > > > > 
> > > > > Perhaps it is a good idea to first post an RFC with an uAPI proposal
> > > > > on how to
> > > > > handle secure video. I suspect this isn't mediatek specific, other
> > > > > SoCs with
> > > > > tee support could use this as well.
> > > > > 
> > > > > As Nicolas said, it's long known to be a gap in our media support, so
> > > > > it is
> > > > > really great that you started work on this, but you need to look at
> > > > > this from
> > > > > a more generic point-of-view, and not mediatek-specific.
> > > > > 
> > > > 
> > > > Whether your have any advice about how to do a more generic driver to
> > > > handle secure video playback?
> > > > 
> > > > There are several kind of buffer: output queue buffer/capture queue
> > > > buffer/working buffer.
> > > > 
> > > > output and capture queue buffer: user space will call tee related
> > > > interface to allocate secure handle. Will convert to secure handle with
> > > > v4l2 framework, then send secure handle to optee-os.
> > > > 
> > > > working buffer: calling dma_heap and dma_buf to get secure memory
> > > > handle, then covert secure iova in optee-os.
> > > > 
> > > > Using the same kernel driver for svp and non-svp playback, just the
> > > > buffer type are different. Normal is iova and secure is secure handle.
> > > > 
> > > > User driver will tell the kernel driver with CID control whether the
> > > > current playback is svp or non-svp.
> > > 
> > > My understanding is that when you switch to secure mode, the driver makes
> > > some optee calls to set everything up. And userspace needs a way convert a
> > > dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> > > buffer. Who uses that handle?
> > 
> > The only user space usage for getting the 'secure handle' from an fd
> > is when that memory is written to. This is done when the TEE decrypts
> > the video contents. User space sends the encrypted video + 'secure
> > handle' to the TEE, and the TEE decrypts the contents to the memory
> > associated with the 'secure handle'. Then the 'secure handle' is
> > passed into the TEE again with the v4l2 driver to use as the source
> > for video decoding (but w/ v4l2, user space is passing in fds).
> 
> I think I need some more background. This series is to support a 'Secure Video
> Processor' (at least, that's what svp stands for I believe, something that
> is not mentioned anywhere in this series, BTW) which is used to decode an
> encrypted h264 stream.
> 
> First question: how is that stream encrypted? Is that according to some standard?
> Nothing is mentioned about that.
> 
> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
> in the output buffer and queue it to the codec), nothing special is needed for that.
> Except, how does the hardware know it is encrypted? I guess that's where the
> control comes in, you have to turn on SVP mode first.

Decryption takes place before the decoder. I suspect there is no dedicated
driver for that, the TEE driver API is similar to smart card API and fits well
this task. So the decrytor consume normal memory that is encrypted and is only
allowed to decrypt into secure memory. All this is happening before the decoder,
so is out of scope for this patchset.

Just a correction :-D.

> 
> For the capture buffers you need to provide buffers from secure/trusted memory.
> That's a dmabuf fd, but where does that come from?
> 
> I saw this message:
> 
> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
> 
> so I expect that's where it comes from. But I agree that getting this from dma-heaps
> seems more natural.
> 
> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
> 
> For actually displaying these secure buffers you would use drm, and I assume that
> the hardware would mix in the contents of the secure buffer into the video output
> pipeline? I.e., the actual contents remain inaccessible. And that the video output
> (HDMI or DisplayPort) is using HDCP?
> 
> > 
> > > 
> > > In any case, using a control to switch to secure mode and using a control
> > > to convert a dmabuf fd to a secure handle seems a poor choice to me.
> > > 
> > > I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> > > e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> > > once you create buffers for the first time, the driver can switch into secure
> > > mode, and until all buffers are released again you know that the driver will
> > > stay in secure mode.
> > 
> > Why do you think the control for setting secure mode is a poor choice?
> > There's various places in the driver code where functionality changes
> > based on being secure/non-secure mode, so this is very much a 'global'
> > setting for the driver. It could be inferred based off a new memory
> > type for the queues...which then sets that flag in the driver; but
> > that seems like it would be more fragile and would require checking
> > for incompatible output/capture memory types. I'm not against another
> > way of doing this; but didn't see why you think the proposed method is
> > a poor choice.
> 
> I assume you are either decoding to secure memory all the time, or not
> at all. That's something you would want to select the moment you allocate
> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
> for that. A control can typically be toggled at any time, and it makes
> no sense to do that for secure streaming.
> 
> Related to that: if you pass a dmabuf fd you will need to check somewhere
> if the fd points to secure memory or not. You don't want to mix the two
> but you want to check that at VIDIOC_QBUF time.
> 
> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
> drivers do not need to do that.

Just to clarify a bit, and make sure I understand this too. You are proposing to
introduce something like:

   V4L2_MEMORY_SECURE_DMABUF

Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
driver that the memory is secure according to the definition of "secure" for the
platform its running on.

This drivers also allocate secure SHM (a standard tee concept) and have internal
allocation for reconstruction buffer and some hw specific reference metadata. So
the idea would be that it would keep allocation using the dmabuf heap internal
APIs ? And decide which type of memory based on the memory type found in the
queue?

Stepping back a little, why can't we have a way for drivers to detect that
dmabuf are secure ? I'm wondering if its actually useful to impose to all
userspace component to know that a dmabuf is secure ?

Also, regarding MTK, these are stateless decoders. I think it would be nice to
show use example code that can properly parse the un-encrypted header, pass the
data to the decryptor and decode. There is a bit of mechanic in there that lacks
clarification, a reference implementation would clearly help. Finally, does this
platform offers some clearkey implementation (or other alternative) so we can do
validation and regression testing? It would be very unfortunate to add feature
upstream that can only be tested by proprietary CDM software.

Nicolas

> 
> > 
> > > 
> > > For converting the dmabuf fd into a secure handle: a new ioctl similar to
> > > VIDIOC_EXPBUF might be more suited for that.
> > 
> > I actually think the best way for converting the dmabuf fd into a
> > secure handle would be another ioctl in the dma-heap driver...since
> > that's where the memory is actually allocated from. But this really
> > depends on upstream maintainers and what they are comfortable with.
> 
> That feels like a more natural place of doing this.
> 
> Regards,
> 
> 	Hans
> 
> > 
> > > 
> > > Note that I am the first to admit that I have no experience with secure
> > > video pipelines or optee-os, so I am looking at this purely from an uAPI
> > > perspective.
> > > 
> > > Regards,
> > > 
> > >         Hans
> > > 
> > > > 
> > > > Best Regards,
> > > > Yunfei Dong
> > > > > Regards,
> > > > > 
> > > > > Hans
> > > > > 
> > > > > > 
> > > > > > regards,
> > > > > > Nicolas
> > > > > > 
> > > > > > p.s. you forgot to document your control in the RST doc, please do
> > > > > 
> > > > > in following
> > > > > > release.
> > > > > > 
> > > > > > > +ctx->is_svp_mode = ctrl->val;
> > > > > > > +
> > > > > > > +if (ctx->is_svp_mode) {
> > > > > > > +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> > > > > > > +if (ret)
> > > > > > > +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> > > > > > > +else
> > > > > > > +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> > > > > > 
> > > > > > val);
> > > > > > > +}
> > > > > > > +break;
> > > > > > >  default:
> > > > > > >  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> > > > > > > 0x%x\n",
> > > > > 
> > > > > hdr_ctrl->id);
> > > > > > >  return ret;
> > > > > > > @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > > > 
> > > > > mtk_vcodec_dec_ctx *ctx)
> > > > > > >  unsigned int i;
> > > > > > >  struct v4l2_ctrl *ctrl;
> > > > > > > 
> > > > > > > -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > > > > > +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> > > > > > >  if (ctx->ctrl_hdl.error) {
> > > > > > >  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > > > > > >  return ctx->ctrl_hdl.error;
> > > > > > > @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > > > 
> > > > > mtk_vcodec_dec_ctx *ctx)
> > > > > > > 
> > > > > > >  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > > > 
> > > > > &mtk_vcodec_dec_ctrl_ops,
> > > > > > >   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > > > > > +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > > > 
> > > > > &mtk_vcodec_dec_ctrl_ops,
> > > > > > > + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> > > > > > > 
> > > > > > >  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > > > > > > 
> > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > 
> > > > > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > index d8cf01f76aab..a507045a3f30 100644
> > > > > > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > > > > > >  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> > > > > > > "Reference
> > > > > 
> > > > > Frames for a P-Frame";
> > > > > > >  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> > > > > 
> > > > > SPS and PPS to IDR";
> > > > > > >  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> > > > > > > Decoder
> > > > > 
> > > > > get secure handle";
> > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> > > > > 
> > > > > set secure mode";
> > > > > > > 
> > > > > > >  /* AV1 controls */
> > > > > > >  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> > > > > > > @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > > > > 
> > > > > **name, enum v4l2_ctrl_type *type,
> > > > > > >  *type = V4L2_CTRL_TYPE_INTEGER;
> > > > > > >  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > > > > >  break;
> > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > > > > > +*type = V4L2_CTRL_TYPE_INTEGER;
> > > > > > > +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > > > > > +break;
> > > > > > >  case V4L2_CID_USER_CLASS:
> > > > > > >  case V4L2_CID_CAMERA_CLASS:
> > > > > > >  case V4L2_CID_CODEC_CLASS:
> > > > > > > diff --git a/include/uapi/linux/v4l2-controls.h
> > > > > 
> > > > > b/include/uapi/linux/v4l2-controls.h
> > > > > > > index 7b3694985366..88e90d943e38 100644
> > > > > > > --- a/include/uapi/linux/v4l2-controls.h
> > > > > > > +++ b/include/uapi/linux/v4l2-controls.h
> > > > > > > @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > > > > > >  /*  MPEG-class control IDs specific to the MediaTek Decoder
> > > > > 
> > > > > driver as defined by V4L2 */
> > > > > > >  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> > > > > > >  #define
> > > > > 
> > > > > V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> > > > > > > +#define
> > > > > 
> > > > > V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> > > > > > > 
> > > > > > >  /*  Camera class control IDs */
> > > > > > > 
> > > 
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Tue, Sep 19, 2023 at 11:51 AM Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
>
> Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
> > On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> > > On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> > > >
> > > > On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> > > > > Hi Hans & Nicolas,
> > > > >
> > > > > Thanks for your advice.
> > > > >
> > > > > On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> > > > > >
> > > > > > External email : Please do not click links or open attachments until
> > > > > > you have verified the sender or the content.
> > > > > >  Hi,
> > > > > >
> > > > > > On 9/11/23 17:54, Nicolas Dufresne wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > > > > > > Setting secure mode flag to kernel when trying to play secure
> > > > > >
> > > > > > video,
> > > > > > > > then decoder driver will initialize tee related interface to
> > > > > >
> > > > > > support
> > > > > > > > svp.
> > > > > > >
> > > > > > >
> > > > > > > This is not what the patch is doing, please rework. This patch is
> > > > > >
> > > > > > an vendor API
> > > > > > > addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> > > > > >
> > > > > > not have to
> > > > > > > read your patch to understand this.
> > > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > > > > > > ---
> > > > > > > >  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> > > > > >
> > > > > > ++++++++++++++-
> > > > > > > >  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> > > > > > > >  include/uapi/linux/v4l2-controls.h                |  1 +
> > > > > > > >  3 files changed, 20 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git
> > > > > >
> > > > > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > > less.c
> > > > > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > > less.c
> > > > > > > > index d2b09ce9f1cf..a981178c25d9 100644
> > > > > > > > ---
> > > > > >
> > > > > > a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > > less.c
> > > > > > > > +++
> > > > > >
> > > > > > b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> > > > > > less.c
> > > > > > > > @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> > > > > >
> > > > > > *ctrl)
> > > > > > > >  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > > > > > > >  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> > > > > >
> > > > > > sec_fd, ctrl->val);
> > > > > > > >  break;
> > > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > > > > >
> > > > > > > Stepping back a little and focusing on the API, what makes your
> > > > > >
> > > > > > driver so
> > > > > > > special that it should be the only one having a "secure mode" ? We
> > > > > >
> > > > > > are touching
> > > > > > > in gap in the media pipeline in Linux, and this should come with
> > > > > >
> > > > > > consideration
> > > > > > > of the global API.
> > > > > > >
> > > > > > > Why is this API better then let's say Google Android one, were they
> > > > > >
> > > > > > expose 2
> > > > > > > device nodes in their fork of the MFC driver (a secure and a non
> > > > > >
> > > > > > secure one) ?
> > > > > >
> > > > > > Perhaps it is a good idea to first post an RFC with an uAPI proposal
> > > > > > on how to
> > > > > > handle secure video. I suspect this isn't mediatek specific, other
> > > > > > SoCs with
> > > > > > tee support could use this as well.
> > > > > >
> > > > > > As Nicolas said, it's long known to be a gap in our media support, so
> > > > > > it is
> > > > > > really great that you started work on this, but you need to look at
> > > > > > this from
> > > > > > a more generic point-of-view, and not mediatek-specific.
> > > > > >
> > > > >
> > > > > Whether your have any advice about how to do a more generic driver to
> > > > > handle secure video playback?
> > > > >
> > > > > There are several kind of buffer: output queue buffer/capture queue
> > > > > buffer/working buffer.
> > > > >
> > > > > output and capture queue buffer: user space will call tee related
> > > > > interface to allocate secure handle. Will convert to secure handle with
> > > > > v4l2 framework, then send secure handle to optee-os.
> > > > >
> > > > > working buffer: calling dma_heap and dma_buf to get secure memory
> > > > > handle, then covert secure iova in optee-os.
> > > > >
> > > > > Using the same kernel driver for svp and non-svp playback, just the
> > > > > buffer type are different. Normal is iova and secure is secure handle.
> > > > >
> > > > > User driver will tell the kernel driver with CID control whether the
> > > > > current playback is svp or non-svp.
> > > >
> > > > My understanding is that when you switch to secure mode, the driver makes
> > > > some optee calls to set everything up. And userspace needs a way convert a
> > > > dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> > > > buffer. Who uses that handle?
> > >
> > > The only user space usage for getting the 'secure handle' from an fd
> > > is when that memory is written to. This is done when the TEE decrypts
> > > the video contents. User space sends the encrypted video + 'secure
> > > handle' to the TEE, and the TEE decrypts the contents to the memory
> > > associated with the 'secure handle'. Then the 'secure handle' is
> > > passed into the TEE again with the v4l2 driver to use as the source
> > > for video decoding (but w/ v4l2, user space is passing in fds).
> >
> > I think I need some more background. This series is to support a 'Secure Video
> > Processor' (at least, that's what svp stands for I believe, something that
> > is not mentioned anywhere in this series, BTW) which is used to decode an
> > encrypted h264 stream.
> >
> > First question: how is that stream encrypted? Is that according to some standard?
> > Nothing is mentioned about that.
> >
> > I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
> > in the output buffer and queue it to the codec), nothing special is needed for that.
> > Except, how does the hardware know it is encrypted? I guess that's where the
> > control comes in, you have to turn on SVP mode first.
>
> Decryption takes place before the decoder. I suspect there is no dedicated
> driver for that, the TEE driver API is similar to smart card API and fits well
> this task. So the decrytor consume normal memory that is encrypted and is only
> allowed to decrypt into secure memory. All this is happening before the decoder,
> so is out of scope for this patchset.
>
> Just a correction :-D.
>
> >
> > For the capture buffers you need to provide buffers from secure/trusted memory.
> > That's a dmabuf fd, but where does that come from?
> >
> > I saw this message:
> >
> > https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
> >
> > so I expect that's where it comes from. But I agree that getting this from dma-heaps
> > seems more natural.
> >
> > I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
> >
> > For actually displaying these secure buffers you would use drm, and I assume that
> > the hardware would mix in the contents of the secure buffer into the video output
> > pipeline? I.e., the actual contents remain inaccessible. And that the video output
> > (HDMI or DisplayPort) is using HDCP?
> >
> > >
> > > >
> > > > In any case, using a control to switch to secure mode and using a control
> > > > to convert a dmabuf fd to a secure handle seems a poor choice to me.
> > > >
> > > > I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> > > > e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> > > > once you create buffers for the first time, the driver can switch into secure
> > > > mode, and until all buffers are released again you know that the driver will
> > > > stay in secure mode.
> > >
> > > Why do you think the control for setting secure mode is a poor choice?
> > > There's various places in the driver code where functionality changes
> > > based on being secure/non-secure mode, so this is very much a 'global'
> > > setting for the driver. It could be inferred based off a new memory
> > > type for the queues...which then sets that flag in the driver; but
> > > that seems like it would be more fragile and would require checking
> > > for incompatible output/capture memory types. I'm not against another
> > > way of doing this; but didn't see why you think the proposed method is
> > > a poor choice.
> >
> > I assume you are either decoding to secure memory all the time, or not
> > at all. That's something you would want to select the moment you allocate
> > the first buffer. Using the V4L2_MEMORY_ value would be the natural place
> > for that. A control can typically be toggled at any time, and it makes
> > no sense to do that for secure streaming.
> >
> > Related to that: if you pass a dmabuf fd you will need to check somewhere
> > if the fd points to secure memory or not. You don't want to mix the two
> > but you want to check that at VIDIOC_QBUF time.
> >
> > Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
> > drivers do not need to do that.
>
> Just to clarify a bit, and make sure I understand this too. You are proposing to
> introduce something like:
>
>    V4L2_MEMORY_SECURE_DMABUF
>
> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
> driver that the memory is secure according to the definition of "secure" for the
> platform its running on.
>
> This drivers also allocate secure SHM (a standard tee concept) and have internal
> allocation for reconstruction buffer and some hw specific reference metadata. So
> the idea would be that it would keep allocation using the dmabuf heap internal
> APIs ? And decide which type of memory based on the memory type found in the
> queue?
>
> Stepping back a little, why can't we have a way for drivers to detect that
> dmabuf are secure ? I'm wondering if its actually useful to impose to all
> userspace component to know that a dmabuf is secure ?
>
> Also, regarding MTK, these are stateless decoders. I think it would be nice to
> show use example code that can properly parse the un-encrypted header, pass the
> data to the decryptor and decode. There is a bit of mechanic in there that lacks
> clarification, a reference implementation would clearly help. Finally, does this
> platform offers some clearkey implementation (or other alternative) so we can do
> validation and regression testing? It would be very unfortunate to add feature
> upstream that can only be tested by proprietary CDM software.
>
> Nicolas


Here's some links to the current userspace implementation built on top
of the MTK patches (and yeah, this'll end up changing based on what
happens upstream).

1. This is where we are decrypting the video to a secure buffer, it's
invoking IPC into a closed source component to do that:
https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/decoder_buffer_transcryptor.cc;l=87
2. This is where we aren enabling secure mode:
https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=412
3. This is where we are resolving secure buffers to secure handles:
https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=535
(the allocation of the secure buffers is done in closed source CDM
code, but it's just opening the dma-buf heap and issuing the ioctl to
allocate it)
4. This is where we submit the secure buffers to the output queue:
https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_queue.cc;l=816
(this is nothing special, since it's just passing in the fd)
5. For the capture queue, there's zero changes in Chrome V4L2 code for
that...it's all transparent to user space that it's a secure surface
that's being rendered to. We do allocate them w/ different flags via
minigbm which happens here:
https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/platform_video_frame_pool.cc;l=37

>
> >
> > >
> > > >
> > > > For converting the dmabuf fd into a secure handle: a new ioctl similar to
> > > > VIDIOC_EXPBUF might be more suited for that.
> > >
> > > I actually think the best way for converting the dmabuf fd into a
> > > secure handle would be another ioctl in the dma-heap driver...since
> > > that's where the memory is actually allocated from. But this really
> > > depends on upstream maintainers and what they are comfortable with.
> >
> > That feels like a more natural place of doing this.
> >
> > Regards,
> >
> >       Hans
> >
> > >
> > > >
> > > > Note that I am the first to admit that I have no experience with secure
> > > > video pipelines or optee-os, so I am looking at this purely from an uAPI
> > > > perspective.
> > > >
> > > > Regards,
> > > >
> > > >         Hans
> > > >
> > > > >
> > > > > Best Regards,
> > > > > Yunfei Dong
> > > > > > Regards,
> > > > > >
> > > > > > Hans
> > > > > >
> > > > > > >
> > > > > > > regards,
> > > > > > > Nicolas
> > > > > > >
> > > > > > > p.s. you forgot to document your control in the RST doc, please do
> > > > > >
> > > > > > in following
> > > > > > > release.
> > > > > > >
> > > > > > > > +ctx->is_svp_mode = ctrl->val;
> > > > > > > > +
> > > > > > > > +if (ctx->is_svp_mode) {
> > > > > > > > +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> > > > > > > > +if (ret)
> > > > > > > > +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> > > > > > > > +else
> > > > > > > > +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> > > > > > >
> > > > > > > val);
> > > > > > > > +}
> > > > > > > > +break;
> > > > > > > >  default:
> > > > > > > >  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> > > > > > > > 0x%x\n",
> > > > > >
> > > > > > hdr_ctrl->id);
> > > > > > > >  return ret;
> > > > > > > > @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > > > >
> > > > > > mtk_vcodec_dec_ctx *ctx)
> > > > > > > >  unsigned int i;
> > > > > > > >  struct v4l2_ctrl *ctrl;
> > > > > > > >
> > > > > > > > -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > > > > > > +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> > > > > > > >  if (ctx->ctrl_hdl.error) {
> > > > > > > >  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > > > > > > >  return ctx->ctrl_hdl.error;
> > > > > > > > @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> > > > > >
> > > > > > mtk_vcodec_dec_ctx *ctx)
> > > > > > > >
> > > > > > > >  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > > > >
> > > > > > &mtk_vcodec_dec_ctrl_ops,
> > > > > > > >   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > > > > > > +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> > > > > >
> > > > > > &mtk_vcodec_dec_ctrl_ops,
> > > > > > > > + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> > > > > > > >
> > > > > > > >  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > > > > > > >
> > > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > >
> > > > > > b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > > index d8cf01f76aab..a507045a3f30 100644
> > > > > > > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > > > > > > @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > > > > > > >  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> > > > > > > > "Reference
> > > > > >
> > > > > > Frames for a P-Frame";
> > > > > > > >  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> > > > > >
> > > > > > SPS and PPS to IDR";
> > > > > > > >  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> > > > > > > > Decoder
> > > > > >
> > > > > > get secure handle";
> > > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> > > > > >
> > > > > > set secure mode";
> > > > > > > >
> > > > > > > >  /* AV1 controls */
> > > > > > > >  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> > > > > > > > @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> > > > > >
> > > > > > **name, enum v4l2_ctrl_type *type,
> > > > > > > >  *type = V4L2_CTRL_TYPE_INTEGER;
> > > > > > > >  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > > > > > >  break;
> > > > > > > > +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > > > > > > > +*type = V4L2_CTRL_TYPE_INTEGER;
> > > > > > > > +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > > > > > > +break;
> > > > > > > >  case V4L2_CID_USER_CLASS:
> > > > > > > >  case V4L2_CID_CAMERA_CLASS:
> > > > > > > >  case V4L2_CID_CODEC_CLASS:
> > > > > > > > diff --git a/include/uapi/linux/v4l2-controls.h
> > > > > >
> > > > > > b/include/uapi/linux/v4l2-controls.h
> > > > > > > > index 7b3694985366..88e90d943e38 100644
> > > > > > > > --- a/include/uapi/linux/v4l2-controls.h
> > > > > > > > +++ b/include/uapi/linux/v4l2-controls.h
> > > > > > > > @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > > > > > > >  /*  MPEG-class control IDs specific to the MediaTek Decoder
> > > > > >
> > > > > > driver as defined by V4L2 */
> > > > > > > >  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> > > > > > > >  #define
> > > > > >
> > > > > > V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> > > > > > > > +#define
> > > > > >
> > > > > > V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> > > > > > > >
> > > > > > > >  /*  Camera class control IDs */
> > > > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 19/09/2023 21:49, Jeffrey Kardatzke wrote:
> On Tue, Sep 19, 2023 at 11:51 AM Nicolas Dufresne
> <nicolas.dufresne@collabora.com> wrote:
>>
>> Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
>>> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
>>>> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>>>
>>>>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
>>>>>> Hi Hans & Nicolas,
>>>>>>
>>>>>> Thanks for your advice.
>>>>>>
>>>>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>>>>>>>
>>>>>>> External email : Please do not click links or open attachments until
>>>>>>> you have verified the sender or the content.
>>>>>>>  Hi,
>>>>>>>
>>>>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>>>>>>>>> Setting secure mode flag to kernel when trying to play secure
>>>>>>>
>>>>>>> video,
>>>>>>>>> then decoder driver will initialize tee related interface to
>>>>>>>
>>>>>>> support
>>>>>>>>> svp.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not what the patch is doing, please rework. This patch is
>>>>>>>
>>>>>>> an vendor API
>>>>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
>>>>>>>
>>>>>>> not have to
>>>>>>>> read your patch to understand this.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>>>>>>>>> ---
>>>>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
>>>>>>>
>>>>>>> ++++++++++++++-
>>>>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>>>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>>>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>
>>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>> less.c
>>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>> less.c
>>>>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
>>>>>>>>> ---
>>>>>>>
>>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>> less.c
>>>>>>>>> +++
>>>>>>>
>>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>> less.c
>>>>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
>>>>>>>
>>>>>>> *ctrl)
>>>>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
>>>>>>>
>>>>>>> sec_fd, ctrl->val);
>>>>>>>>>  break;
>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>>
>>>>>>>> Stepping back a little and focusing on the API, what makes your
>>>>>>>
>>>>>>> driver so
>>>>>>>> special that it should be the only one having a "secure mode" ? We
>>>>>>>
>>>>>>> are touching
>>>>>>>> in gap in the media pipeline in Linux, and this should come with
>>>>>>>
>>>>>>> consideration
>>>>>>>> of the global API.
>>>>>>>>
>>>>>>>> Why is this API better then let's say Google Android one, were they
>>>>>>>
>>>>>>> expose 2
>>>>>>>> device nodes in their fork of the MFC driver (a secure and a non
>>>>>>>
>>>>>>> secure one) ?
>>>>>>>
>>>>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
>>>>>>> on how to
>>>>>>> handle secure video. I suspect this isn't mediatek specific, other
>>>>>>> SoCs with
>>>>>>> tee support could use this as well.
>>>>>>>
>>>>>>> As Nicolas said, it's long known to be a gap in our media support, so
>>>>>>> it is
>>>>>>> really great that you started work on this, but you need to look at
>>>>>>> this from
>>>>>>> a more generic point-of-view, and not mediatek-specific.
>>>>>>>
>>>>>>
>>>>>> Whether your have any advice about how to do a more generic driver to
>>>>>> handle secure video playback?
>>>>>>
>>>>>> There are several kind of buffer: output queue buffer/capture queue
>>>>>> buffer/working buffer.
>>>>>>
>>>>>> output and capture queue buffer: user space will call tee related
>>>>>> interface to allocate secure handle. Will convert to secure handle with
>>>>>> v4l2 framework, then send secure handle to optee-os.
>>>>>>
>>>>>> working buffer: calling dma_heap and dma_buf to get secure memory
>>>>>> handle, then covert secure iova in optee-os.
>>>>>>
>>>>>> Using the same kernel driver for svp and non-svp playback, just the
>>>>>> buffer type are different. Normal is iova and secure is secure handle.
>>>>>>
>>>>>> User driver will tell the kernel driver with CID control whether the
>>>>>> current playback is svp or non-svp.
>>>>>
>>>>> My understanding is that when you switch to secure mode, the driver makes
>>>>> some optee calls to set everything up. And userspace needs a way convert a
>>>>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
>>>>> buffer. Who uses that handle?
>>>>
>>>> The only user space usage for getting the 'secure handle' from an fd
>>>> is when that memory is written to. This is done when the TEE decrypts
>>>> the video contents. User space sends the encrypted video + 'secure
>>>> handle' to the TEE, and the TEE decrypts the contents to the memory
>>>> associated with the 'secure handle'. Then the 'secure handle' is
>>>> passed into the TEE again with the v4l2 driver to use as the source
>>>> for video decoding (but w/ v4l2, user space is passing in fds).
>>>
>>> I think I need some more background. This series is to support a 'Secure Video
>>> Processor' (at least, that's what svp stands for I believe, something that
>>> is not mentioned anywhere in this series, BTW) which is used to decode an
>>> encrypted h264 stream.
>>>
>>> First question: how is that stream encrypted? Is that according to some standard?
>>> Nothing is mentioned about that.
>>>
>>> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
>>> in the output buffer and queue it to the codec), nothing special is needed for that.
>>> Except, how does the hardware know it is encrypted? I guess that's where the
>>> control comes in, you have to turn on SVP mode first.
>>
>> Decryption takes place before the decoder. I suspect there is no dedicated
>> driver for that, the TEE driver API is similar to smart card API and fits well
>> this task. So the decrytor consume normal memory that is encrypted and is only
>> allowed to decrypt into secure memory. All this is happening before the decoder,
>> so is out of scope for this patchset.
>>
>> Just a correction :-D.
>>
>>>
>>> For the capture buffers you need to provide buffers from secure/trusted memory.
>>> That's a dmabuf fd, but where does that come from?
>>>
>>> I saw this message:
>>>
>>> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
>>>
>>> so I expect that's where it comes from. But I agree that getting this from dma-heaps
>>> seems more natural.
>>>
>>> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
>>>
>>> For actually displaying these secure buffers you would use drm, and I assume that
>>> the hardware would mix in the contents of the secure buffer into the video output
>>> pipeline? I.e., the actual contents remain inaccessible. And that the video output
>>> (HDMI or DisplayPort) is using HDCP?
>>>
>>>>
>>>>>
>>>>> In any case, using a control to switch to secure mode and using a control
>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
>>>>>
>>>>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
>>>>> once you create buffers for the first time, the driver can switch into secure
>>>>> mode, and until all buffers are released again you know that the driver will
>>>>> stay in secure mode.
>>>>
>>>> Why do you think the control for setting secure mode is a poor choice?
>>>> There's various places in the driver code where functionality changes
>>>> based on being secure/non-secure mode, so this is very much a 'global'
>>>> setting for the driver. It could be inferred based off a new memory
>>>> type for the queues...which then sets that flag in the driver; but
>>>> that seems like it would be more fragile and would require checking
>>>> for incompatible output/capture memory types. I'm not against another
>>>> way of doing this; but didn't see why you think the proposed method is
>>>> a poor choice.
>>>
>>> I assume you are either decoding to secure memory all the time, or not
>>> at all. That's something you would want to select the moment you allocate
>>> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
>>> for that. A control can typically be toggled at any time, and it makes
>>> no sense to do that for secure streaming.
>>>
>>> Related to that: if you pass a dmabuf fd you will need to check somewhere
>>> if the fd points to secure memory or not. You don't want to mix the two
>>> but you want to check that at VIDIOC_QBUF time.
>>>
>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
>>> drivers do not need to do that.
>>
>> Just to clarify a bit, and make sure I understand this too. You are proposing to
>> introduce something like:
>>
>>    V4L2_MEMORY_SECURE_DMABUF
>>
>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
>> driver that the memory is secure according to the definition of "secure" for the
>> platform its running on.
>>
>> This drivers also allocate secure SHM (a standard tee concept) and have internal
>> allocation for reconstruction buffer and some hw specific reference metadata. So
>> the idea would be that it would keep allocation using the dmabuf heap internal
>> APIs ? And decide which type of memory based on the memory type found in the
>> queue?
>>
>> Stepping back a little, why can't we have a way for drivers to detect that
>> dmabuf are secure ? I'm wondering if its actually useful to impose to all
>> userspace component to know that a dmabuf is secure ?
>>
>> Also, regarding MTK, these are stateless decoders. I think it would be nice to
>> show use example code that can properly parse the un-encrypted header, pass the
>> data to the decryptor and decode. There is a bit of mechanic in there that lacks
>> clarification, a reference implementation would clearly help. Finally, does this
>> platform offers some clearkey implementation (or other alternative) so we can do
>> validation and regression testing? It would be very unfortunate to add feature
>> upstream that can only be tested by proprietary CDM software.
>>
>> Nicolas
> 
> 
> Here's some links to the current userspace implementation built on top
> of the MTK patches (and yeah, this'll end up changing based on what
> happens upstream).
> 
> 1. This is where we are decrypting the video to a secure buffer, it's
> invoking IPC into a closed source component to do that:
> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/decoder_buffer_transcryptor.cc;l=87

So the encrypted compressed stream (contained in a regular non-secure buffer)
is decrypted here into secure buffers. Correct?

The hardware codec will just operate on those secure buffers, both for the
output and capture queues, right? And no decryption/encryption takes place,
it is all operating on unencrypted secure buffers, right?

Or is the plan to include the decryption step in the driver?

But who encrypted the compressed stream? Is it encrypted according to
some standard? Or it is mediatek specific?

Regards,

	Hans

> 2. This is where we aren enabling secure mode:
> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=412
> 3. This is where we are resolving secure buffers to secure handles:
> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=535
> (the allocation of the secure buffers is done in closed source CDM
> code, but it's just opening the dma-buf heap and issuing the ioctl to
> allocate it)
> 4. This is where we submit the secure buffers to the output queue:
> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_queue.cc;l=816
> (this is nothing special, since it's just passing in the fd)
> 5. For the capture queue, there's zero changes in Chrome V4L2 code for
> that...it's all transparent to user space that it's a secure surface
> that's being rendered to. We do allocate them w/ different flags via
> minigbm which happens here:
> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/platform_video_frame_pool.cc;l=37
> 
>>
>>>
>>>>
>>>>>
>>>>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
>>>>> VIDIOC_EXPBUF might be more suited for that.
>>>>
>>>> I actually think the best way for converting the dmabuf fd into a
>>>> secure handle would be another ioctl in the dma-heap driver...since
>>>> that's where the memory is actually allocated from. But this really
>>>> depends on upstream maintainers and what they are comfortable with.
>>>
>>> That feels like a more natural place of doing this.
>>>
>>> Regards,
>>>
>>>       Hans
>>>
>>>>
>>>>>
>>>>> Note that I am the first to admit that I have no experience with secure
>>>>> video pipelines or optee-os, so I am looking at this purely from an uAPI
>>>>> perspective.
>>>>>
>>>>> Regards,
>>>>>
>>>>>         Hans
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Yunfei Dong
>>>>>>> Regards,
>>>>>>>
>>>>>>> Hans
>>>>>>>
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>> p.s. you forgot to document your control in the RST doc, please do
>>>>>>>
>>>>>>> in following
>>>>>>>> release.
>>>>>>>>
>>>>>>>>> +ctx->is_svp_mode = ctrl->val;
>>>>>>>>> +
>>>>>>>>> +if (ctx->is_svp_mode) {
>>>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>>>>>>>>> +if (ret)
>>>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>>>>>>>>> +else
>>>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
>>>>>>>>
>>>>>>>> val);
>>>>>>>>> +}
>>>>>>>>> +break;
>>>>>>>>>  default:
>>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
>>>>>>>>> 0x%x\n",
>>>>>>>
>>>>>>> hdr_ctrl->id);
>>>>>>>>>  return ret;
>>>>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>>
>>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>>  unsigned int i;
>>>>>>>>>  struct v4l2_ctrl *ctrl;
>>>>>>>>>
>>>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>>>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>>>>>>>>  if (ctx->ctrl_hdl.error) {
>>>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>>>>>>>>  return ctx->ctrl_hdl.error;
>>>>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>>
>>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>>
>>>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>>
>>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>>>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>>
>>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>>>>>>>>
>>>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>
>>>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>> index d8cf01f76aab..a507045a3f30 100644
>>>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
>>>>>>>>> "Reference
>>>>>>>
>>>>>>> Frames for a P-Frame";
>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
>>>>>>>
>>>>>>> SPS and PPS to IDR";
>>>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
>>>>>>>>> Decoder
>>>>>>>
>>>>>>> get secure handle";
>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
>>>>>>>
>>>>>>> set secure mode";
>>>>>>>>>
>>>>>>>>>  /* AV1 controls */
>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
>>>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
>>>>>>>
>>>>>>> **name, enum v4l2_ctrl_type *type,
>>>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>>>  break;
>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>>> +break;
>>>>>>>>>  case V4L2_CID_USER_CLASS:
>>>>>>>>>  case V4L2_CID_CAMERA_CLASS:
>>>>>>>>>  case V4L2_CID_CODEC_CLASS:
>>>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
>>>>>>>
>>>>>>> b/include/uapi/linux/v4l2-controls.h
>>>>>>>>> index 7b3694985366..88e90d943e38 100644
>>>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
>>>>>>>
>>>>>>> driver as defined by V4L2 */
>>>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>>>>>>>>  #define
>>>>>>>
>>>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
>>>>>>>>> +#define
>>>>>>>
>>>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
>>>>>>>>>
>>>>>>>>>  /*  Camera class control IDs */
>>>>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Wed, Sep 20, 2023 at 12:10 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 19/09/2023 21:49, Jeffrey Kardatzke wrote:
> > On Tue, Sep 19, 2023 at 11:51 AM Nicolas Dufresne
> > <nicolas.dufresne@collabora.com> wrote:
> >>
> >> Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
> >>> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> >>>> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>>>>
> >>>>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> >>>>>> Hi Hans & Nicolas,
> >>>>>>
> >>>>>> Thanks for your advice.
> >>>>>>
> >>>>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> >>>>>>>
> >>>>>>> External email : Please do not click links or open attachments until
> >>>>>>> you have verified the sender or the content.
> >>>>>>>  Hi,
> >>>>>>>
> >>>>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >>>>>>>>> Setting secure mode flag to kernel when trying to play secure
> >>>>>>>
> >>>>>>> video,
> >>>>>>>>> then decoder driver will initialize tee related interface to
> >>>>>>>
> >>>>>>> support
> >>>>>>>>> svp.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This is not what the patch is doing, please rework. This patch is
> >>>>>>>
> >>>>>>> an vendor API
> >>>>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> >>>>>>>
> >>>>>>> not have to
> >>>>>>>> read your patch to understand this.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >>>>>>>>> ---
> >>>>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> >>>>>>>
> >>>>>>> ++++++++++++++-
> >>>>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>>>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>>>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git
> >>>>>>>
> >>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>>> less.c
> >>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>>> less.c
> >>>>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
> >>>>>>>>> ---
> >>>>>>>
> >>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>>> less.c
> >>>>>>>>> +++
> >>>>>>>
> >>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>>> less.c
> >>>>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> >>>>>>>
> >>>>>>> *ctrl)
> >>>>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> >>>>>>>
> >>>>>>> sec_fd, ctrl->val);
> >>>>>>>>>  break;
> >>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>>>>
> >>>>>>>> Stepping back a little and focusing on the API, what makes your
> >>>>>>>
> >>>>>>> driver so
> >>>>>>>> special that it should be the only one having a "secure mode" ? We
> >>>>>>>
> >>>>>>> are touching
> >>>>>>>> in gap in the media pipeline in Linux, and this should come with
> >>>>>>>
> >>>>>>> consideration
> >>>>>>>> of the global API.
> >>>>>>>>
> >>>>>>>> Why is this API better then let's say Google Android one, were they
> >>>>>>>
> >>>>>>> expose 2
> >>>>>>>> device nodes in their fork of the MFC driver (a secure and a non
> >>>>>>>
> >>>>>>> secure one) ?
> >>>>>>>
> >>>>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> >>>>>>> on how to
> >>>>>>> handle secure video. I suspect this isn't mediatek specific, other
> >>>>>>> SoCs with
> >>>>>>> tee support could use this as well.
> >>>>>>>
> >>>>>>> As Nicolas said, it's long known to be a gap in our media support, so
> >>>>>>> it is
> >>>>>>> really great that you started work on this, but you need to look at
> >>>>>>> this from
> >>>>>>> a more generic point-of-view, and not mediatek-specific.
> >>>>>>>
> >>>>>>
> >>>>>> Whether your have any advice about how to do a more generic driver to
> >>>>>> handle secure video playback?
> >>>>>>
> >>>>>> There are several kind of buffer: output queue buffer/capture queue
> >>>>>> buffer/working buffer.
> >>>>>>
> >>>>>> output and capture queue buffer: user space will call tee related
> >>>>>> interface to allocate secure handle. Will convert to secure handle with
> >>>>>> v4l2 framework, then send secure handle to optee-os.
> >>>>>>
> >>>>>> working buffer: calling dma_heap and dma_buf to get secure memory
> >>>>>> handle, then covert secure iova in optee-os.
> >>>>>>
> >>>>>> Using the same kernel driver for svp and non-svp playback, just the
> >>>>>> buffer type are different. Normal is iova and secure is secure handle.
> >>>>>>
> >>>>>> User driver will tell the kernel driver with CID control whether the
> >>>>>> current playback is svp or non-svp.
> >>>>>
> >>>>> My understanding is that when you switch to secure mode, the driver makes
> >>>>> some optee calls to set everything up. And userspace needs a way convert a
> >>>>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> >>>>> buffer. Who uses that handle?
> >>>>
> >>>> The only user space usage for getting the 'secure handle' from an fd
> >>>> is when that memory is written to. This is done when the TEE decrypts
> >>>> the video contents. User space sends the encrypted video + 'secure
> >>>> handle' to the TEE, and the TEE decrypts the contents to the memory
> >>>> associated with the 'secure handle'. Then the 'secure handle' is
> >>>> passed into the TEE again with the v4l2 driver to use as the source
> >>>> for video decoding (but w/ v4l2, user space is passing in fds).
> >>>
> >>> I think I need some more background. This series is to support a 'Secure Video
> >>> Processor' (at least, that's what svp stands for I believe, something that
> >>> is not mentioned anywhere in this series, BTW) which is used to decode an
> >>> encrypted h264 stream.
> >>>
> >>> First question: how is that stream encrypted? Is that according to some standard?
> >>> Nothing is mentioned about that.
> >>>
> >>> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
> >>> in the output buffer and queue it to the codec), nothing special is needed for that.
> >>> Except, how does the hardware know it is encrypted? I guess that's where the
> >>> control comes in, you have to turn on SVP mode first.
> >>
> >> Decryption takes place before the decoder. I suspect there is no dedicated
> >> driver for that, the TEE driver API is similar to smart card API and fits well
> >> this task. So the decrytor consume normal memory that is encrypted and is only
> >> allowed to decrypt into secure memory. All this is happening before the decoder,
> >> so is out of scope for this patchset.
> >>
> >> Just a correction :-D.
> >>
> >>>
> >>> For the capture buffers you need to provide buffers from secure/trusted memory.
> >>> That's a dmabuf fd, but where does that come from?
> >>>
> >>> I saw this message:
> >>>
> >>> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
> >>>
> >>> so I expect that's where it comes from. But I agree that getting this from dma-heaps
> >>> seems more natural.
> >>>
> >>> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
> >>>
> >>> For actually displaying these secure buffers you would use drm, and I assume that
> >>> the hardware would mix in the contents of the secure buffer into the video output
> >>> pipeline? I.e., the actual contents remain inaccessible. And that the video output
> >>> (HDMI or DisplayPort) is using HDCP?
> >>>
> >>>>
> >>>>>
> >>>>> In any case, using a control to switch to secure mode and using a control
> >>>>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
> >>>>>
> >>>>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> >>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> >>>>> once you create buffers for the first time, the driver can switch into secure
> >>>>> mode, and until all buffers are released again you know that the driver will
> >>>>> stay in secure mode.
> >>>>
> >>>> Why do you think the control for setting secure mode is a poor choice?
> >>>> There's various places in the driver code where functionality changes
> >>>> based on being secure/non-secure mode, so this is very much a 'global'
> >>>> setting for the driver. It could be inferred based off a new memory
> >>>> type for the queues...which then sets that flag in the driver; but
> >>>> that seems like it would be more fragile and would require checking
> >>>> for incompatible output/capture memory types. I'm not against another
> >>>> way of doing this; but didn't see why you think the proposed method is
> >>>> a poor choice.
> >>>
> >>> I assume you are either decoding to secure memory all the time, or not
> >>> at all. That's something you would want to select the moment you allocate
> >>> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
> >>> for that. A control can typically be toggled at any time, and it makes
> >>> no sense to do that for secure streaming.
> >>>
> >>> Related to that: if you pass a dmabuf fd you will need to check somewhere
> >>> if the fd points to secure memory or not. You don't want to mix the two
> >>> but you want to check that at VIDIOC_QBUF time.
> >>>
> >>> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
> >>> drivers do not need to do that.
> >>
> >> Just to clarify a bit, and make sure I understand this too. You are proposing to
> >> introduce something like:
> >>
> >>    V4L2_MEMORY_SECURE_DMABUF
> >>
> >> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
> >> driver that the memory is secure according to the definition of "secure" for the
> >> platform its running on.
> >>
> >> This drivers also allocate secure SHM (a standard tee concept) and have internal
> >> allocation for reconstruction buffer and some hw specific reference metadata. So
> >> the idea would be that it would keep allocation using the dmabuf heap internal
> >> APIs ? And decide which type of memory based on the memory type found in the
> >> queue?
> >>
> >> Stepping back a little, why can't we have a way for drivers to detect that
> >> dmabuf are secure ? I'm wondering if its actually useful to impose to all
> >> userspace component to know that a dmabuf is secure ?
> >>
> >> Also, regarding MTK, these are stateless decoders. I think it would be nice to
> >> show use example code that can properly parse the un-encrypted header, pass the
> >> data to the decryptor and decode. There is a bit of mechanic in there that lacks
> >> clarification, a reference implementation would clearly help. Finally, does this
> >> platform offers some clearkey implementation (or other alternative) so we can do
> >> validation and regression testing? It would be very unfortunate to add feature
> >> upstream that can only be tested by proprietary CDM software.
> >>
> >> Nicolas
> >
> >
> > Here's some links to the current userspace implementation built on top
> > of the MTK patches (and yeah, this'll end up changing based on what
> > happens upstream).
> >
> > 1. This is where we are decrypting the video to a secure buffer, it's
> > invoking IPC into a closed source component to do that:
> > https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/decoder_buffer_transcryptor.cc;l=87
>
> So the encrypted compressed stream (contained in a regular non-secure buffer)
> is decrypted here into secure buffers. Correct?
Correct
>
> The hardware codec will just operate on those secure buffers, both for the
> output and capture queues, right? And no decryption/encryption takes place,
> it is all operating on unencrypted secure buffers, right?
Correct
>
> Or is the plan to include the decryption step in the driver?
No, the driver will never be doing the decryption.
>
> But who encrypted the compressed stream? Is it encrypted according to
> some standard? Or it is mediatek specific?
It's encrypted using CENC (Common Encryption). The method for
acquiring the keys to perform the decryption is Widevine specific
(Widevine is the Digital Rights Management system we are using...but
nothing in the kernel patches dictates which Digital Rights Management
system is used, but the encryption technique is a standard).
>
> Regards,
>
>         Hans
>
> > 2. This is where we aren enabling secure mode:
> > https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=412
> > 3. This is where we are resolving secure buffers to secure handles:
> > https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=535
> > (the allocation of the secure buffers is done in closed source CDM
> > code, but it's just opening the dma-buf heap and issuing the ioctl to
> > allocate it)
> > 4. This is where we submit the secure buffers to the output queue:
> > https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_queue.cc;l=816
> > (this is nothing special, since it's just passing in the fd)
> > 5. For the capture queue, there's zero changes in Chrome V4L2 code for
> > that...it's all transparent to user space that it's a secure surface
> > that's being rendered to. We do allocate them w/ different flags via
> > minigbm which happens here:
> > https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/platform_video_frame_pool.cc;l=37
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
> >>>>> VIDIOC_EXPBUF might be more suited for that.
> >>>>
> >>>> I actually think the best way for converting the dmabuf fd into a
> >>>> secure handle would be another ioctl in the dma-heap driver...since
> >>>> that's where the memory is actually allocated from. But this really
> >>>> depends on upstream maintainers and what they are comfortable with.
> >>>
> >>> That feels like a more natural place of doing this.
> >>>
> >>> Regards,
> >>>
> >>>       Hans
> >>>
> >>>>
> >>>>>
> >>>>> Note that I am the first to admit that I have no experience with secure
> >>>>> video pipelines or optee-os, so I am looking at this purely from an uAPI
> >>>>> perspective.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>         Hans
> >>>>>
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Yunfei Dong
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Hans
> >>>>>>>
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>> Nicolas
> >>>>>>>>
> >>>>>>>> p.s. you forgot to document your control in the RST doc, please do
> >>>>>>>
> >>>>>>> in following
> >>>>>>>> release.
> >>>>>>>>
> >>>>>>>>> +ctx->is_svp_mode = ctrl->val;
> >>>>>>>>> +
> >>>>>>>>> +if (ctx->is_svp_mode) {
> >>>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>>>>>>> +if (ret)
> >>>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>>>>>>> +else
> >>>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >>>>>>>>
> >>>>>>>> val);
> >>>>>>>>> +}
> >>>>>>>>> +break;
> >>>>>>>>>  default:
> >>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>>>>>>> 0x%x\n",
> >>>>>>>
> >>>>>>> hdr_ctrl->id);
> >>>>>>>>>  return ret;
> >>>>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>>
> >>>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>>  unsigned int i;
> >>>>>>>>>  struct v4l2_ctrl *ctrl;
> >>>>>>>>>
> >>>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>>>>>>  if (ctx->ctrl_hdl.error) {
> >>>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>>>>>>  return ctx->ctrl_hdl.error;
> >>>>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>>
> >>>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>>
> >>>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>>
> >>>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>>
> >>>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>>>>>>
> >>>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>
> >>>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>>> index d8cf01f76aab..a507045a3f30 100644
> >>>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>>>>>>> "Reference
> >>>>>>>
> >>>>>>> Frames for a P-Frame";
> >>>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> >>>>>>>
> >>>>>>> SPS and PPS to IDR";
> >>>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>>>>>>> Decoder
> >>>>>>>
> >>>>>>> get secure handle";
> >>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> >>>>>>>
> >>>>>>> set secure mode";
> >>>>>>>>>
> >>>>>>>>>  /* AV1 controls */
> >>>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> >>>>>>>
> >>>>>>> **name, enum v4l2_ctrl_type *type,
> >>>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>>>  break;
> >>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>>> +break;
> >>>>>>>>>  case V4L2_CID_USER_CLASS:
> >>>>>>>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>>>>>>  case V4L2_CID_CODEC_CLASS:
> >>>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>>>>>>
> >>>>>>> b/include/uapi/linux/v4l2-controls.h
> >>>>>>>>> index 7b3694985366..88e90d943e38 100644
> >>>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >>>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>>>>>>
> >>>>>>> driver as defined by V4L2 */
> >>>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>>>>>>>>  #define
> >>>>>>>
> >>>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>>>>>>> +#define
> >>>>>>>
> >>>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>>>>>>
> >>>>>>>>>  /*  Camera class control IDs */
> >>>>>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> linux-arm-kernel mailing list
> >>>>> linux-arm-kernel@lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>>
> >>
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 20/09/2023 20:13, Jeffrey Kardatzke wrote:
> On Wed, Sep 20, 2023 at 12:10 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>
>> On 19/09/2023 21:49, Jeffrey Kardatzke wrote:
>>> On Tue, Sep 19, 2023 at 11:51 AM Nicolas Dufresne
>>> <nicolas.dufresne@collabora.com> wrote:
>>>>
>>>> Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
>>>>> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
>>>>>> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>>>>>
>>>>>>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
>>>>>>>> Hi Hans & Nicolas,
>>>>>>>>
>>>>>>>> Thanks for your advice.
>>>>>>>>
>>>>>>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>>>>>>>>>
>>>>>>>>> External email : Please do not click links or open attachments until
>>>>>>>>> you have verified the sender or the content.
>>>>>>>>>  Hi,
>>>>>>>>>
>>>>>>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>>>>>>>>>>> Setting secure mode flag to kernel when trying to play secure
>>>>>>>>>
>>>>>>>>> video,
>>>>>>>>>>> then decoder driver will initialize tee related interface to
>>>>>>>>>
>>>>>>>>> support
>>>>>>>>>>> svp.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is not what the patch is doing, please rework. This patch is
>>>>>>>>>
>>>>>>>>> an vendor API
>>>>>>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
>>>>>>>>>
>>>>>>>>> not have to
>>>>>>>>>> read your patch to understand this.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
>>>>>>>>>
>>>>>>>>> ++++++++++++++-
>>>>>>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>>>>>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>>>>>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git
>>>>>>>>>
>>>>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>>>> less.c
>>>>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>>>> less.c
>>>>>>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
>>>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>>>> less.c
>>>>>>>>>>> +++
>>>>>>>>>
>>>>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>>>>> less.c
>>>>>>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
>>>>>>>>>
>>>>>>>>> *ctrl)
>>>>>>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>>>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
>>>>>>>>>
>>>>>>>>> sec_fd, ctrl->val);
>>>>>>>>>>>  break;
>>>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>>>>
>>>>>>>>>> Stepping back a little and focusing on the API, what makes your
>>>>>>>>>
>>>>>>>>> driver so
>>>>>>>>>> special that it should be the only one having a "secure mode" ? We
>>>>>>>>>
>>>>>>>>> are touching
>>>>>>>>>> in gap in the media pipeline in Linux, and this should come with
>>>>>>>>>
>>>>>>>>> consideration
>>>>>>>>>> of the global API.
>>>>>>>>>>
>>>>>>>>>> Why is this API better then let's say Google Android one, were they
>>>>>>>>>
>>>>>>>>> expose 2
>>>>>>>>>> device nodes in their fork of the MFC driver (a secure and a non
>>>>>>>>>
>>>>>>>>> secure one) ?
>>>>>>>>>
>>>>>>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
>>>>>>>>> on how to
>>>>>>>>> handle secure video. I suspect this isn't mediatek specific, other
>>>>>>>>> SoCs with
>>>>>>>>> tee support could use this as well.
>>>>>>>>>
>>>>>>>>> As Nicolas said, it's long known to be a gap in our media support, so
>>>>>>>>> it is
>>>>>>>>> really great that you started work on this, but you need to look at
>>>>>>>>> this from
>>>>>>>>> a more generic point-of-view, and not mediatek-specific.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Whether your have any advice about how to do a more generic driver to
>>>>>>>> handle secure video playback?
>>>>>>>>
>>>>>>>> There are several kind of buffer: output queue buffer/capture queue
>>>>>>>> buffer/working buffer.
>>>>>>>>
>>>>>>>> output and capture queue buffer: user space will call tee related
>>>>>>>> interface to allocate secure handle. Will convert to secure handle with
>>>>>>>> v4l2 framework, then send secure handle to optee-os.
>>>>>>>>
>>>>>>>> working buffer: calling dma_heap and dma_buf to get secure memory
>>>>>>>> handle, then covert secure iova in optee-os.
>>>>>>>>
>>>>>>>> Using the same kernel driver for svp and non-svp playback, just the
>>>>>>>> buffer type are different. Normal is iova and secure is secure handle.
>>>>>>>>
>>>>>>>> User driver will tell the kernel driver with CID control whether the
>>>>>>>> current playback is svp or non-svp.
>>>>>>>
>>>>>>> My understanding is that when you switch to secure mode, the driver makes
>>>>>>> some optee calls to set everything up. And userspace needs a way convert a
>>>>>>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
>>>>>>> buffer. Who uses that handle?
>>>>>>
>>>>>> The only user space usage for getting the 'secure handle' from an fd
>>>>>> is when that memory is written to. This is done when the TEE decrypts
>>>>>> the video contents. User space sends the encrypted video + 'secure
>>>>>> handle' to the TEE, and the TEE decrypts the contents to the memory
>>>>>> associated with the 'secure handle'. Then the 'secure handle' is
>>>>>> passed into the TEE again with the v4l2 driver to use as the source
>>>>>> for video decoding (but w/ v4l2, user space is passing in fds).
>>>>>
>>>>> I think I need some more background. This series is to support a 'Secure Video
>>>>> Processor' (at least, that's what svp stands for I believe, something that
>>>>> is not mentioned anywhere in this series, BTW) which is used to decode an
>>>>> encrypted h264 stream.
>>>>>
>>>>> First question: how is that stream encrypted? Is that according to some standard?
>>>>> Nothing is mentioned about that.
>>>>>
>>>>> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
>>>>> in the output buffer and queue it to the codec), nothing special is needed for that.
>>>>> Except, how does the hardware know it is encrypted? I guess that's where the
>>>>> control comes in, you have to turn on SVP mode first.
>>>>
>>>> Decryption takes place before the decoder. I suspect there is no dedicated
>>>> driver for that, the TEE driver API is similar to smart card API and fits well
>>>> this task. So the decrytor consume normal memory that is encrypted and is only
>>>> allowed to decrypt into secure memory. All this is happening before the decoder,
>>>> so is out of scope for this patchset.
>>>>
>>>> Just a correction :-D.
>>>>
>>>>>
>>>>> For the capture buffers you need to provide buffers from secure/trusted memory.
>>>>> That's a dmabuf fd, but where does that come from?
>>>>>
>>>>> I saw this message:
>>>>>
>>>>> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
>>>>>
>>>>> so I expect that's where it comes from. But I agree that getting this from dma-heaps
>>>>> seems more natural.
>>>>>
>>>>> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
>>>>>
>>>>> For actually displaying these secure buffers you would use drm, and I assume that
>>>>> the hardware would mix in the contents of the secure buffer into the video output
>>>>> pipeline? I.e., the actual contents remain inaccessible. And that the video output
>>>>> (HDMI or DisplayPort) is using HDCP?
>>>>>
>>>>>>
>>>>>>>
>>>>>>> In any case, using a control to switch to secure mode and using a control
>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
>>>>>>>
>>>>>>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
>>>>>>> once you create buffers for the first time, the driver can switch into secure
>>>>>>> mode, and until all buffers are released again you know that the driver will
>>>>>>> stay in secure mode.
>>>>>>
>>>>>> Why do you think the control for setting secure mode is a poor choice?
>>>>>> There's various places in the driver code where functionality changes
>>>>>> based on being secure/non-secure mode, so this is very much a 'global'
>>>>>> setting for the driver. It could be inferred based off a new memory
>>>>>> type for the queues...which then sets that flag in the driver; but
>>>>>> that seems like it would be more fragile and would require checking
>>>>>> for incompatible output/capture memory types. I'm not against another
>>>>>> way of doing this; but didn't see why you think the proposed method is
>>>>>> a poor choice.
>>>>>
>>>>> I assume you are either decoding to secure memory all the time, or not
>>>>> at all. That's something you would want to select the moment you allocate
>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
>>>>> for that. A control can typically be toggled at any time, and it makes
>>>>> no sense to do that for secure streaming.
>>>>>
>>>>> Related to that: if you pass a dmabuf fd you will need to check somewhere
>>>>> if the fd points to secure memory or not. You don't want to mix the two
>>>>> but you want to check that at VIDIOC_QBUF time.
>>>>>
>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
>>>>> drivers do not need to do that.
>>>>
>>>> Just to clarify a bit, and make sure I understand this too. You are proposing to
>>>> introduce something like:
>>>>
>>>>    V4L2_MEMORY_SECURE_DMABUF
>>>>
>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
>>>> driver that the memory is secure according to the definition of "secure" for the
>>>> platform its running on.
>>>>
>>>> This drivers also allocate secure SHM (a standard tee concept) and have internal
>>>> allocation for reconstruction buffer and some hw specific reference metadata. So
>>>> the idea would be that it would keep allocation using the dmabuf heap internal
>>>> APIs ? And decide which type of memory based on the memory type found in the
>>>> queue?
>>>>
>>>> Stepping back a little, why can't we have a way for drivers to detect that
>>>> dmabuf are secure ? I'm wondering if its actually useful to impose to all
>>>> userspace component to know that a dmabuf is secure ?
>>>>
>>>> Also, regarding MTK, these are stateless decoders. I think it would be nice to
>>>> show use example code that can properly parse the un-encrypted header, pass the
>>>> data to the decryptor and decode. There is a bit of mechanic in there that lacks
>>>> clarification, a reference implementation would clearly help. Finally, does this
>>>> platform offers some clearkey implementation (or other alternative) so we can do
>>>> validation and regression testing? It would be very unfortunate to add feature
>>>> upstream that can only be tested by proprietary CDM software.
>>>>
>>>> Nicolas
>>>
>>>
>>> Here's some links to the current userspace implementation built on top
>>> of the MTK patches (and yeah, this'll end up changing based on what
>>> happens upstream).
>>>
>>> 1. This is where we are decrypting the video to a secure buffer, it's
>>> invoking IPC into a closed source component to do that:
>>> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/decoder_buffer_transcryptor.cc;l=87
>>
>> So the encrypted compressed stream (contained in a regular non-secure buffer)
>> is decrypted here into secure buffers. Correct?
> Correct
>>
>> The hardware codec will just operate on those secure buffers, both for the
>> output and capture queues, right? And no decryption/encryption takes place,
>> it is all operating on unencrypted secure buffers, right?
> Correct
>>
>> Or is the plan to include the decryption step in the driver?
> No, the driver will never be doing the decryption.
>>
>> But who encrypted the compressed stream? Is it encrypted according to
>> some standard? Or it is mediatek specific?
> It's encrypted using CENC (Common Encryption). The method for
> acquiring the keys to perform the decryption is Widevine specific
> (Widevine is the Digital Rights Management system we are using...but
> nothing in the kernel patches dictates which Digital Rights Management
> system is used, but the encryption technique is a standard).

Ah, that's the missing piece for me. Now I understand the context of these
patches.

Thank you, this was very helpful.

Regards,

	Hans

>>
>> Regards,
>>
>>         Hans
>>
>>> 2. This is where we aren enabling secure mode:
>>> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=412
>>> 3. This is where we are resolving secure buffers to secure handles:
>>> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_video_decoder.cc;l=535
>>> (the allocation of the secure buffers is done in closed source CDM
>>> code, but it's just opening the dma-buf heap and issuing the ioctl to
>>> allocate it)
>>> 4. This is where we submit the secure buffers to the output queue:
>>> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/v4l2_queue.cc;l=816
>>> (this is nothing special, since it's just passing in the fd)
>>> 5. For the capture queue, there's zero changes in Chrome V4L2 code for
>>> that...it's all transparent to user space that it's a secure surface
>>> that's being rendered to. We do allocate them w/ different flags via
>>> minigbm which happens here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/platform_video_frame_pool.cc;l=37
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
>>>>>>> VIDIOC_EXPBUF might be more suited for that.
>>>>>>
>>>>>> I actually think the best way for converting the dmabuf fd into a
>>>>>> secure handle would be another ioctl in the dma-heap driver...since
>>>>>> that's where the memory is actually allocated from. But this really
>>>>>> depends on upstream maintainers and what they are comfortable with.
>>>>>
>>>>> That feels like a more natural place of doing this.
>>>>>
>>>>> Regards,
>>>>>
>>>>>       Hans
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Note that I am the first to admit that I have no experience with secure
>>>>>>> video pipelines or optee-os, so I am looking at this purely from an uAPI
>>>>>>> perspective.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>         Hans
>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Yunfei Dong
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>> p.s. you forgot to document your control in the RST doc, please do
>>>>>>>>>
>>>>>>>>> in following
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>>> +ctx->is_svp_mode = ctrl->val;
>>>>>>>>>>> +
>>>>>>>>>>> +if (ctx->is_svp_mode) {
>>>>>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>>>>>>>>>>> +if (ret)
>>>>>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>>>>>>>>>>> +else
>>>>>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
>>>>>>>>>>
>>>>>>>>>> val);
>>>>>>>>>>> +}
>>>>>>>>>>> +break;
>>>>>>>>>>>  default:
>>>>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
>>>>>>>>>>> 0x%x\n",
>>>>>>>>>
>>>>>>>>> hdr_ctrl->id);
>>>>>>>>>>>  return ret;
>>>>>>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>>>>
>>>>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>>>>  unsigned int i;
>>>>>>>>>>>  struct v4l2_ctrl *ctrl;
>>>>>>>>>>>
>>>>>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>>>>>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>>>>>>>>>>  if (ctx->ctrl_hdl.error) {
>>>>>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>>>>>>>>>>  return ctx->ctrl_hdl.error;
>>>>>>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>>>>
>>>>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>>>>
>>>>>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>>>>
>>>>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>>>>>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>>>>
>>>>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>>>>>>>>>>
>>>>>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>>
>>>>>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>>>> index d8cf01f76aab..a507045a3f30 100644
>>>>>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
>>>>>>>>>>> "Reference
>>>>>>>>>
>>>>>>>>> Frames for a P-Frame";
>>>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
>>>>>>>>>
>>>>>>>>> SPS and PPS to IDR";
>>>>>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
>>>>>>>>>>> Decoder
>>>>>>>>>
>>>>>>>>> get secure handle";
>>>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
>>>>>>>>>
>>>>>>>>> set secure mode";
>>>>>>>>>>>
>>>>>>>>>>>  /* AV1 controls */
>>>>>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
>>>>>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
>>>>>>>>>
>>>>>>>>> **name, enum v4l2_ctrl_type *type,
>>>>>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>>>>>  break;
>>>>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>>>>> +break;
>>>>>>>>>>>  case V4L2_CID_USER_CLASS:
>>>>>>>>>>>  case V4L2_CID_CAMERA_CLASS:
>>>>>>>>>>>  case V4L2_CID_CODEC_CLASS:
>>>>>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
>>>>>>>>>
>>>>>>>>> b/include/uapi/linux/v4l2-controls.h
>>>>>>>>>>> index 7b3694985366..88e90d943e38 100644
>>>>>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>>>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>>>>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>>>>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
>>>>>>>>>
>>>>>>>>> driver as defined by V4L2 */
>>>>>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>>>>>>>>>>  #define
>>>>>>>>>
>>>>>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
>>>>>>>>>>> +#define
>>>>>>>>>
>>>>>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
>>>>>>>>>>>
>>>>>>>>>>>  /*  Camera class control IDs */
>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> linux-arm-kernel mailing list
>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>
>>>>
>>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 19/09/2023 20:51, Nicolas Dufresne wrote:
> Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
>> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
>>> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>>
>>>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
>>>>> Hi Hans & Nicolas,
>>>>>
>>>>> Thanks for your advice.
>>>>>
>>>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>>>>>>
>>>>>> External email : Please do not click links or open attachments until
>>>>>> you have verified the sender or the content.
>>>>>>  Hi,
>>>>>>
>>>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
>>>>>>>> Setting secure mode flag to kernel when trying to play secure
>>>>>>
>>>>>> video,
>>>>>>>> then decoder driver will initialize tee related interface to
>>>>>>
>>>>>> support
>>>>>>>> svp.
>>>>>>>
>>>>>>>
>>>>>>> This is not what the patch is doing, please rework. This patch is
>>>>>>
>>>>>> an vendor API
>>>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
>>>>>>
>>>>>> not have to
>>>>>>> read your patch to understand this.
>>>>>>>
>>>>>>>>
>>>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
>>>>>>>> ---
>>>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
>>>>>>
>>>>>> ++++++++++++++-
>>>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
>>>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
>>>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git
>>>>>>
>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>> less.c
>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>> less.c
>>>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
>>>>>>>> ---
>>>>>>
>>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>> less.c
>>>>>>>> +++
>>>>>>
>>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
>>>>>> less.c
>>>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
>>>>>>
>>>>>> *ctrl)
>>>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
>>>>>>
>>>>>> sec_fd, ctrl->val);
>>>>>>>>  break;
>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>
>>>>>>> Stepping back a little and focusing on the API, what makes your
>>>>>>
>>>>>> driver so
>>>>>>> special that it should be the only one having a "secure mode" ? We
>>>>>>
>>>>>> are touching
>>>>>>> in gap in the media pipeline in Linux, and this should come with
>>>>>>
>>>>>> consideration
>>>>>>> of the global API.
>>>>>>>
>>>>>>> Why is this API better then let's say Google Android one, were they
>>>>>>
>>>>>> expose 2
>>>>>>> device nodes in their fork of the MFC driver (a secure and a non
>>>>>>
>>>>>> secure one) ?
>>>>>>
>>>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
>>>>>> on how to
>>>>>> handle secure video. I suspect this isn't mediatek specific, other
>>>>>> SoCs with
>>>>>> tee support could use this as well.
>>>>>>
>>>>>> As Nicolas said, it's long known to be a gap in our media support, so
>>>>>> it is
>>>>>> really great that you started work on this, but you need to look at
>>>>>> this from
>>>>>> a more generic point-of-view, and not mediatek-specific.
>>>>>>
>>>>>
>>>>> Whether your have any advice about how to do a more generic driver to
>>>>> handle secure video playback?
>>>>>
>>>>> There are several kind of buffer: output queue buffer/capture queue
>>>>> buffer/working buffer.
>>>>>
>>>>> output and capture queue buffer: user space will call tee related
>>>>> interface to allocate secure handle. Will convert to secure handle with
>>>>> v4l2 framework, then send secure handle to optee-os.
>>>>>
>>>>> working buffer: calling dma_heap and dma_buf to get secure memory
>>>>> handle, then covert secure iova in optee-os.
>>>>>
>>>>> Using the same kernel driver for svp and non-svp playback, just the
>>>>> buffer type are different. Normal is iova and secure is secure handle.
>>>>>
>>>>> User driver will tell the kernel driver with CID control whether the
>>>>> current playback is svp or non-svp.
>>>>
>>>> My understanding is that when you switch to secure mode, the driver makes
>>>> some optee calls to set everything up. And userspace needs a way convert a
>>>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
>>>> buffer. Who uses that handle?
>>>
>>> The only user space usage for getting the 'secure handle' from an fd
>>> is when that memory is written to. This is done when the TEE decrypts
>>> the video contents. User space sends the encrypted video + 'secure
>>> handle' to the TEE, and the TEE decrypts the contents to the memory
>>> associated with the 'secure handle'. Then the 'secure handle' is
>>> passed into the TEE again with the v4l2 driver to use as the source
>>> for video decoding (but w/ v4l2, user space is passing in fds).
>>
>> I think I need some more background. This series is to support a 'Secure Video
>> Processor' (at least, that's what svp stands for I believe, something that
>> is not mentioned anywhere in this series, BTW) which is used to decode an
>> encrypted h264 stream.
>>
>> First question: how is that stream encrypted? Is that according to some standard?
>> Nothing is mentioned about that.
>>
>> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
>> in the output buffer and queue it to the codec), nothing special is needed for that.
>> Except, how does the hardware know it is encrypted? I guess that's where the
>> control comes in, you have to turn on SVP mode first.
> 
> Decryption takes place before the decoder. I suspect there is no dedicated
> driver for that, the TEE driver API is similar to smart card API and fits well
> this task. So the decrytor consume normal memory that is encrypted and is only
> allowed to decrypt into secure memory. All this is happening before the decoder,
> so is out of scope for this patchset.
> 
> Just a correction :-D.
> 
>>
>> For the capture buffers you need to provide buffers from secure/trusted memory.
>> That's a dmabuf fd, but where does that come from?
>>
>> I saw this message:
>>
>> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
>>
>> so I expect that's where it comes from. But I agree that getting this from dma-heaps
>> seems more natural.
>>
>> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
>>
>> For actually displaying these secure buffers you would use drm, and I assume that
>> the hardware would mix in the contents of the secure buffer into the video output
>> pipeline? I.e., the actual contents remain inaccessible. And that the video output
>> (HDMI or DisplayPort) is using HDCP?
>>
>>>
>>>>
>>>> In any case, using a control to switch to secure mode and using a control
>>>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
>>>>
>>>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
>>>> once you create buffers for the first time, the driver can switch into secure
>>>> mode, and until all buffers are released again you know that the driver will
>>>> stay in secure mode.
>>>
>>> Why do you think the control for setting secure mode is a poor choice?
>>> There's various places in the driver code where functionality changes
>>> based on being secure/non-secure mode, so this is very much a 'global'
>>> setting for the driver. It could be inferred based off a new memory
>>> type for the queues...which then sets that flag in the driver; but
>>> that seems like it would be more fragile and would require checking
>>> for incompatible output/capture memory types. I'm not against another
>>> way of doing this; but didn't see why you think the proposed method is
>>> a poor choice.
>>
>> I assume you are either decoding to secure memory all the time, or not
>> at all. That's something you would want to select the moment you allocate
>> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
>> for that. A control can typically be toggled at any time, and it makes
>> no sense to do that for secure streaming.
>>
>> Related to that: if you pass a dmabuf fd you will need to check somewhere
>> if the fd points to secure memory or not. You don't want to mix the two
>> but you want to check that at VIDIOC_QBUF time.
>>
>> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
>> drivers do not need to do that.
> 
> Just to clarify a bit, and make sure I understand this too. You are proposing to
> introduce something like:
> 
>    V4L2_MEMORY_SECURE_DMABUF
> 
> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
> driver that the memory is secure according to the definition of "secure" for the
> platform its running on.
> 
> This drivers also allocate secure SHM (a standard tee concept) and have internal
> allocation for reconstruction buffer and some hw specific reference metadata. So
> the idea would be that it would keep allocation using the dmabuf heap internal
> APIs ? And decide which type of memory based on the memory type found in the
> queue?

Yes. Once you request the first buffer you basically tell the driver whether it
will operate in secure or non-secure mode, and that stays that way until all
buffers are freed. I think that makes sense.

If there is a need in the future to have V4L2 allocate the secure buffers, then
a similar V4L2_MEMORY_MMAP_SECURE type can be added. I think using v4l2_memory
to select secure or non-secure mode is logical and fits well with the V4L2 API.

> Stepping back a little, why can't we have a way for drivers to detect that
> dmabuf are secure ? I'm wondering if its actually useful to impose to all
> userspace component to know that a dmabuf is secure ?

I was wondering the same thing: there should be a simple way for drivers and
userspace to check if a dmabuf fd is secure or not. That will certainly help
the vb2 framework verify that you don't mix secure and non-secure dmabuf fds.

> 
> Also, regarding MTK, these are stateless decoders. I think it would be nice to
> show use example code that can properly parse the un-encrypted header, pass the
> data to the decryptor and decode. There is a bit of mechanic in there that lacks
> clarification, a reference implementation would clearly help. Finally, does this
> platform offers some clearkey implementation (or other alternative) so we can do
> validation and regression testing? It would be very unfortunate to add feature
> upstream that can only be tested by proprietary CDM software.

Good points.

	Hans

> 
> Nicolas
> 
>>
>>>
>>>>
>>>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
>>>> VIDIOC_EXPBUF might be more suited for that.
>>>
>>> I actually think the best way for converting the dmabuf fd into a
>>> secure handle would be another ioctl in the dma-heap driver...since
>>> that's where the memory is actually allocated from. But this really
>>> depends on upstream maintainers and what they are comfortable with.
>>
>> That feels like a more natural place of doing this.
>>
>> Regards,
>>
>> 	Hans
>>
>>>
>>>>
>>>> Note that I am the first to admit that I have no experience with secure
>>>> video pipelines or optee-os, so I am looking at this purely from an uAPI
>>>> perspective.
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Yunfei Dong
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>> Nicolas
>>>>>>>
>>>>>>> p.s. you forgot to document your control in the RST doc, please do
>>>>>>
>>>>>> in following
>>>>>>> release.
>>>>>>>
>>>>>>>> +ctx->is_svp_mode = ctrl->val;
>>>>>>>> +
>>>>>>>> +if (ctx->is_svp_mode) {
>>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
>>>>>>>> +if (ret)
>>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
>>>>>>>> +else
>>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
>>>>>>>
>>>>>>> val);
>>>>>>>> +}
>>>>>>>> +break;
>>>>>>>>  default:
>>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
>>>>>>>> 0x%x\n",
>>>>>>
>>>>>> hdr_ctrl->id);
>>>>>>>>  return ret;
>>>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>
>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>  unsigned int i;
>>>>>>>>  struct v4l2_ctrl *ctrl;
>>>>>>>>
>>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
>>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
>>>>>>>>  if (ctx->ctrl_hdl.error) {
>>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
>>>>>>>>  return ctx->ctrl_hdl.error;
>>>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
>>>>>>
>>>>>> mtk_vcodec_dec_ctx *ctx)
>>>>>>>>
>>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>
>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
>>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
>>>>>>
>>>>>> &mtk_vcodec_dec_ctrl_ops,
>>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
>>>>>>>>
>>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
>>>>>>>>
>>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>
>>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>> index d8cf01f76aab..a507045a3f30 100644
>>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
>>>>>>>> "Reference
>>>>>>
>>>>>> Frames for a P-Frame";
>>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
>>>>>>
>>>>>> SPS and PPS to IDR";
>>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
>>>>>>>> Decoder
>>>>>>
>>>>>> get secure handle";
>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
>>>>>>
>>>>>> set secure mode";
>>>>>>>>
>>>>>>>>  /* AV1 controls */
>>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
>>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
>>>>>>
>>>>>> **name, enum v4l2_ctrl_type *type,
>>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>>  break;
>>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
>>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
>>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
>>>>>>>> +break;
>>>>>>>>  case V4L2_CID_USER_CLASS:
>>>>>>>>  case V4L2_CID_CAMERA_CLASS:
>>>>>>>>  case V4L2_CID_CODEC_CLASS:
>>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
>>>>>>
>>>>>> b/include/uapi/linux/v4l2-controls.h
>>>>>>>> index 7b3694985366..88e90d943e38 100644
>>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
>>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
>>>>>>
>>>>>> driver as defined by V4L2 */
>>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
>>>>>>>>  #define
>>>>>>
>>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
>>>>>>>> +#define
>>>>>>
>>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
>>>>>>>>
>>>>>>>>  /*  Camera class control IDs */
>>>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Wed, Sep 20, 2023 at 12:21 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 19/09/2023 20:51, Nicolas Dufresne wrote:
> > Le mardi 19 septembre 2023 à 10:53 +0200, Hans Verkuil a écrit :
> >> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> >>> On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>>>
> >>>> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> >>>>> Hi Hans & Nicolas,
> >>>>>
> >>>>> Thanks for your advice.
> >>>>>
> >>>>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> >>>>>>
> >>>>>> External email : Please do not click links or open attachments until
> >>>>>> you have verified the sender or the content.
> >>>>>>  Hi,
> >>>>>>
> >>>>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >>>>>>>> Setting secure mode flag to kernel when trying to play secure
> >>>>>>
> >>>>>> video,
> >>>>>>>> then decoder driver will initialize tee related interface to
> >>>>>>
> >>>>>> support
> >>>>>>>> svp.
> >>>>>>>
> >>>>>>>
> >>>>>>> This is not what the patch is doing, please rework. This patch is
> >>>>>>
> >>>>>> an vendor API
> >>>>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> >>>>>>
> >>>>>> not have to
> >>>>>>> read your patch to understand this.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >>>>>>>> ---
> >>>>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> >>>>>>
> >>>>>> ++++++++++++++-
> >>>>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>>>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>>>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git
> >>>>>>
> >>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>> less.c
> >>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>> less.c
> >>>>>>>> index d2b09ce9f1cf..a981178c25d9 100644
> >>>>>>>> ---
> >>>>>>
> >>>>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>> less.c
> >>>>>>>> +++
> >>>>>>
> >>>>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>>>> less.c
> >>>>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> >>>>>>
> >>>>>> *ctrl)
> >>>>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> >>>>>>
> >>>>>> sec_fd, ctrl->val);
> >>>>>>>>  break;
> >>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>>>
> >>>>>>> Stepping back a little and focusing on the API, what makes your
> >>>>>>
> >>>>>> driver so
> >>>>>>> special that it should be the only one having a "secure mode" ? We
> >>>>>>
> >>>>>> are touching
> >>>>>>> in gap in the media pipeline in Linux, and this should come with
> >>>>>>
> >>>>>> consideration
> >>>>>>> of the global API.
> >>>>>>>
> >>>>>>> Why is this API better then let's say Google Android one, were they
> >>>>>>
> >>>>>> expose 2
> >>>>>>> device nodes in their fork of the MFC driver (a secure and a non
> >>>>>>
> >>>>>> secure one) ?
> >>>>>>
> >>>>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> >>>>>> on how to
> >>>>>> handle secure video. I suspect this isn't mediatek specific, other
> >>>>>> SoCs with
> >>>>>> tee support could use this as well.
> >>>>>>
> >>>>>> As Nicolas said, it's long known to be a gap in our media support, so
> >>>>>> it is
> >>>>>> really great that you started work on this, but you need to look at
> >>>>>> this from
> >>>>>> a more generic point-of-view, and not mediatek-specific.
> >>>>>>
> >>>>>
> >>>>> Whether your have any advice about how to do a more generic driver to
> >>>>> handle secure video playback?
> >>>>>
> >>>>> There are several kind of buffer: output queue buffer/capture queue
> >>>>> buffer/working buffer.
> >>>>>
> >>>>> output and capture queue buffer: user space will call tee related
> >>>>> interface to allocate secure handle. Will convert to secure handle with
> >>>>> v4l2 framework, then send secure handle to optee-os.
> >>>>>
> >>>>> working buffer: calling dma_heap and dma_buf to get secure memory
> >>>>> handle, then covert secure iova in optee-os.
> >>>>>
> >>>>> Using the same kernel driver for svp and non-svp playback, just the
> >>>>> buffer type are different. Normal is iova and secure is secure handle.
> >>>>>
> >>>>> User driver will tell the kernel driver with CID control whether the
> >>>>> current playback is svp or non-svp.
> >>>>
> >>>> My understanding is that when you switch to secure mode, the driver makes
> >>>> some optee calls to set everything up. And userspace needs a way convert a
> >>>> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> >>>> buffer. Who uses that handle?
> >>>
> >>> The only user space usage for getting the 'secure handle' from an fd
> >>> is when that memory is written to. This is done when the TEE decrypts
> >>> the video contents. User space sends the encrypted video + 'secure
> >>> handle' to the TEE, and the TEE decrypts the contents to the memory
> >>> associated with the 'secure handle'. Then the 'secure handle' is
> >>> passed into the TEE again with the v4l2 driver to use as the source
> >>> for video decoding (but w/ v4l2, user space is passing in fds).
> >>
> >> I think I need some more background. This series is to support a 'Secure Video
> >> Processor' (at least, that's what svp stands for I believe, something that
> >> is not mentioned anywhere in this series, BTW) which is used to decode an
> >> encrypted h264 stream.
> >>
> >> First question: how is that stream encrypted? Is that according to some standard?
> >> Nothing is mentioned about that.
> >>
> >> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
> >> in the output buffer and queue it to the codec), nothing special is needed for that.
> >> Except, how does the hardware know it is encrypted? I guess that's where the
> >> control comes in, you have to turn on SVP mode first.
> >
> > Decryption takes place before the decoder. I suspect there is no dedicated
> > driver for that, the TEE driver API is similar to smart card API and fits well
> > this task. So the decrytor consume normal memory that is encrypted and is only
> > allowed to decrypt into secure memory. All this is happening before the decoder,
> > so is out of scope for this patchset.
> >
> > Just a correction :-D.
> >
> >>
> >> For the capture buffers you need to provide buffers from secure/trusted memory.
> >> That's a dmabuf fd, but where does that come from?
> >>
> >> I saw this message:
> >>
> >> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
> >>
> >> so I expect that's where it comes from. But I agree that getting this from dma-heaps
> >> seems more natural.
> >>
> >> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
> >>
> >> For actually displaying these secure buffers you would use drm, and I assume that
> >> the hardware would mix in the contents of the secure buffer into the video output
> >> pipeline? I.e., the actual contents remain inaccessible. And that the video output
> >> (HDMI or DisplayPort) is using HDCP?
> >>
> >>>
> >>>>
> >>>> In any case, using a control to switch to secure mode and using a control
> >>>> to convert a dmabuf fd to a secure handle seems a poor choice to me.
> >>>>
> >>>> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> >>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> >>>> once you create buffers for the first time, the driver can switch into secure
> >>>> mode, and until all buffers are released again you know that the driver will
> >>>> stay in secure mode.
> >>>
> >>> Why do you think the control for setting secure mode is a poor choice?
> >>> There's various places in the driver code where functionality changes
> >>> based on being secure/non-secure mode, so this is very much a 'global'
> >>> setting for the driver. It could be inferred based off a new memory
> >>> type for the queues...which then sets that flag in the driver; but
> >>> that seems like it would be more fragile and would require checking
> >>> for incompatible output/capture memory types. I'm not against another
> >>> way of doing this; but didn't see why you think the proposed method is
> >>> a poor choice.
> >>
> >> I assume you are either decoding to secure memory all the time, or not
> >> at all. That's something you would want to select the moment you allocate
> >> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
> >> for that. A control can typically be toggled at any time, and it makes
> >> no sense to do that for secure streaming.
> >>
> >> Related to that: if you pass a dmabuf fd you will need to check somewhere
> >> if the fd points to secure memory or not. You don't want to mix the two
> >> but you want to check that at VIDIOC_QBUF time.
> >>
> >> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
> >> drivers do not need to do that.
> >
> > Just to clarify a bit, and make sure I understand this too. You are proposing to
> > introduce something like:
> >
> >    V4L2_MEMORY_SECURE_DMABUF
> >
> > Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while telling the
> > driver that the memory is secure according to the definition of "secure" for the
> > platform its running on.
> >
> > This drivers also allocate secure SHM (a standard tee concept) and have internal
> > allocation for reconstruction buffer and some hw specific reference metadata. So
> > the idea would be that it would keep allocation using the dmabuf heap internal
> > APIs ? And decide which type of memory based on the memory type found in the
> > queue?
>
> Yes. Once you request the first buffer you basically tell the driver whether it
> will operate in secure or non-secure mode, and that stays that way until all
> buffers are freed. I think that makes sense.
>
> If there is a need in the future to have V4L2 allocate the secure buffers, then
> a similar V4L2_MEMORY_MMAP_SECURE type can be added. I think using v4l2_memory
> to select secure or non-secure mode is logical and fits well with the V4L2 API.
>
OK, sounds good. I'll work with Mediatek to get the patches updated for that.

> > Stepping back a little, why can't we have a way for drivers to detect that
> > dmabuf are secure ? I'm wondering if its actually useful to impose to all
> > userspace component to know that a dmabuf is secure ?
>
> I was wondering the same thing: there should be a simple way for drivers and
> userspace to check if a dmabuf fd is secure or not. That will certainly help
> the vb2 framework verify that you don't mix secure and non-secure dmabuf fds.
>
Already talked to Mediatek about this and they are working on updating
the dma-buf patches for this.

> >
> > Also, regarding MTK, these are stateless decoders. I think it would be nice to
> > show use example code that can properly parse the un-encrypted header, pass the
> > data to the decryptor and decode. There is a bit of mechanic in there that lacks
> > clarification, a reference implementation would clearly help. Finally, does this
> > platform offers some clearkey implementation (or other alternative) so we can do
> > validation and regression testing? It would be very unfortunate to add feature
> > upstream that can only be tested by proprietary CDM software.
>

It would be possible to use this with clearkey w/ some additional work
on our end. If this is then part of the public ChromiumOS build, would
that be satisfactory? (the TEE would have some binary blob components
like firmware does though)

> Good points.
>
>         Hans
>
> >
> > Nicolas
> >
> >>
> >>>
> >>>>
> >>>> For converting the dmabuf fd into a secure handle: a new ioctl similar to
> >>>> VIDIOC_EXPBUF might be more suited for that.
> >>>
> >>> I actually think the best way for converting the dmabuf fd into a
> >>> secure handle would be another ioctl in the dma-heap driver...since
> >>> that's where the memory is actually allocated from. But this really
> >>> depends on upstream maintainers and what they are comfortable with.
> >>
> >> That feels like a more natural place of doing this.
> >>
> >> Regards,
> >>
> >>      Hans
> >>
> >>>
> >>>>
> >>>> Note that I am the first to admit that I have no experience with secure
> >>>> video pipelines or optee-os, so I am looking at this purely from an uAPI
> >>>> perspective.
> >>>>
> >>>> Regards,
> >>>>
> >>>>         Hans
> >>>>
> >>>>>
> >>>>> Best Regards,
> >>>>> Yunfei Dong
> >>>>>> Regards,
> >>>>>>
> >>>>>> Hans
> >>>>>>
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> Nicolas
> >>>>>>>
> >>>>>>> p.s. you forgot to document your control in the RST doc, please do
> >>>>>>
> >>>>>> in following
> >>>>>>> release.
> >>>>>>>
> >>>>>>>> +ctx->is_svp_mode = ctrl->val;
> >>>>>>>> +
> >>>>>>>> +if (ctx->is_svp_mode) {
> >>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>>>>>> +if (ret)
> >>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>>>>>> +else
> >>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >>>>>>>
> >>>>>>> val);
> >>>>>>>> +}
> >>>>>>>> +break;
> >>>>>>>>  default:
> >>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>>>>>> 0x%x\n",
> >>>>>>
> >>>>>> hdr_ctrl->id);
> >>>>>>>>  return ret;
> >>>>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>
> >>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>  unsigned int i;
> >>>>>>>>  struct v4l2_ctrl *ctrl;
> >>>>>>>>
> >>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>>>>>  if (ctx->ctrl_hdl.error) {
> >>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>>>>>  return ctx->ctrl_hdl.error;
> >>>>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>
> >>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>
> >>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>
> >>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>
> >>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>>>>>
> >>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>
> >>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> index d8cf01f76aab..a507045a3f30 100644
> >>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>>>>>> "Reference
> >>>>>>
> >>>>>> Frames for a P-Frame";
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> >>>>>>
> >>>>>> SPS and PPS to IDR";
> >>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>>>>>> Decoder
> >>>>>>
> >>>>>> get secure handle";
> >>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> >>>>>>
> >>>>>> set secure mode";
> >>>>>>>>
> >>>>>>>>  /* AV1 controls */
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> >>>>>>
> >>>>>> **name, enum v4l2_ctrl_type *type,
> >>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>>  break;
> >>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>> +break;
> >>>>>>>>  case V4L2_CID_USER_CLASS:
> >>>>>>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>>>>>  case V4L2_CID_CODEC_CLASS:
> >>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>>>>>
> >>>>>> b/include/uapi/linux/v4l2-controls.h
> >>>>>>>> index 7b3694985366..88e90d943e38 100644
> >>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>>>>>
> >>>>>> driver as defined by V4L2 */
> >>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>>>>>>>  #define
> >>>>>>
> >>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>>>>>> +#define
> >>>>>>
> >>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>>>>>
> >>>>>>>>  /*  Camera class control IDs */
> >>>>>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> linux-arm-kernel mailing list
> >>>> linux-arm-kernel@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> >
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Nicolas Dufresne]

Le mercredi 20 septembre 2023 à 11:20 -0700, Jeffrey Kardatzke a écrit :
> > > 
> > > Also, regarding MTK, these are stateless decoders. I think it would be nice to
> > > show use example code that can properly parse the un-encrypted header, pass the
> > > data to the decryptor and decode. There is a bit of mechanic in there that lacks
> > > clarification, a reference implementation would clearly help. Finally, does this
> > > platform offers some clearkey implementation (or other alternative) so we can do
> > > validation and regression testing? It would be very unfortunate to add feature
> > > upstream that can only be tested by proprietary CDM software.
> > 
> 
> It would be possible to use this with clearkey w/ some additional work
> on our end. If this is then part of the public ChromiumOS build, would
> that be satisfactory? (the TEE would have some binary blob components
> like firmware does though)

From my point of view, this would fully cover my concern. To clarify this
concern, the  decryption into secure memory currently only ever take place in
proprietary code that implements the protection (Widewine CDM). With clear key,
we can have an open source CDM (made for testing purpose) so that we don't have
to have hidden code to test the entire pipeline. So appart from the TEE
firmware, which is just a firmware like all the others, we could have open
source tests in kernelCI and other CI, and we could extend these test to
eventually support other vendors.

Note that currently, with other proposal, one could allocate and fill a normal
buffer, and "secure" that buffer to test the CODECs and display, but on this
specific architecture, with the limitation on the number of secure regions, this
feature isn't available.

Alternatives to this end-to-end solution, we could consider a TA (Trusted
Application) that simply copy data from a untrusted chunk of memory into a
trusted chunk of memory. That seems like a cross-platform solution. It would be
even better if this get standardized in TEEs for course (or at least required
with all secure memory implementation). Then copying from untrusted to trusted
could easily become an ioctl generic to all TEE drivers. That to me would be
equally acceptable, and perhaps easier to use.

Nicolas 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Thu, Sep 21, 2023 at 8:46 AM Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
>
> Le mercredi 20 septembre 2023 à 11:20 -0700, Jeffrey Kardatzke a écrit :
> > > >
> > > > Also, regarding MTK, these are stateless decoders. I think it would be nice to
> > > > show use example code that can properly parse the un-encrypted header, pass the
> > > > data to the decryptor and decode. There is a bit of mechanic in there that lacks
> > > > clarification, a reference implementation would clearly help. Finally, does this
> > > > platform offers some clearkey implementation (or other alternative) so we can do
> > > > validation and regression testing? It would be very unfortunate to add feature
> > > > upstream that can only be tested by proprietary CDM software.
> > >
> >
> > It would be possible to use this with clearkey w/ some additional work
> > on our end. If this is then part of the public ChromiumOS build, would
> > that be satisfactory? (the TEE would have some binary blob components
> > like firmware does though)
>
> From my point of view, this would fully cover my concern. To clarify this
> concern, the  decryption into secure memory currently only ever take place in
> proprietary code that implements the protection (Widewine CDM). With clear key,
> we can have an open source CDM (made for testing purpose) so that we don't have
> to have hidden code to test the entire pipeline. So appart from the TEE
> firmware, which is just a firmware like all the others, we could have open
> source tests in kernelCI and other CI, and we could extend these test to
> eventually support other vendors.
>
> Note that currently, with other proposal, one could allocate and fill a normal
> buffer, and "secure" that buffer to test the CODECs and display, but on this
> specific architecture, with the limitation on the number of secure regions, this
> feature isn't available.
>
> Alternatives to this end-to-end solution, we could consider a TA (Trusted
> Application) that simply copy data from a untrusted chunk of memory into a
> trusted chunk of memory. That seems like a cross-platform solution. It would be
> even better if this get standardized in TEEs for course (or at least required
> with all secure memory implementation). Then copying from untrusted to trusted
> could easily become an ioctl generic to all TEE drivers. That to me would be
> equally acceptable, and perhaps easier to use.
>
> Nicolas

It's very likely for the clearkey implementation that I would just
have it copying the data from a non-secure to secure buffer in a TA.
We would never do that in production of course, but for testing images
that would suffice.

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong (董云飞)]

Hi Hans,

Thanks for your help to give some good advice.
On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
>  	 
> >>>> In any case, using a control to switch to secure mode and using
> a control
> >>>> to convert a dmabuf fd to a secure handle seems a poor choice to
> me.
> >>>>
> >>>> I was wondering if it wouldn't be better to create a new
> V4L2_MEMORY_ type,
> >>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> ensures that
> >>>> once you create buffers for the first time, the driver can
> switch into secure
> >>>> mode, and until all buffers are released again you know that the
> driver will
> >>>> stay in secure mode.
> >>>
> >>> Why do you think the control for setting secure mode is a poor
> choice?
> >>> There's various places in the driver code where functionality
> changes
> >>> based on being secure/non-secure mode, so this is very much a
> 'global'
> >>> setting for the driver. It could be inferred based off a new
> memory
> >>> type for the queues...which then sets that flag in the driver;
> but
> >>> that seems like it would be more fragile and would require
> checking
> >>> for incompatible output/capture memory types. I'm not against
> another
> >>> way of doing this; but didn't see why you think the proposed
> method is
> >>> a poor choice.
> >>
> >> I assume you are either decoding to secure memory all the time, or
> not
> >> at all. That's something you would want to select the moment you
> allocate
> >> the first buffer. Using the V4L2_MEMORY_ value would be the
> natural place
> >> for that. A control can typically be toggled at any time, and it
> makes
> >> no sense to do that for secure streaming.
> >>
> >> Related to that: if you pass a dmabuf fd you will need to check
> somewhere
> >> if the fd points to secure memory or not. You don't want to mix
> the two
> >> but you want to check that at VIDIOC_QBUF time.
> >>
> >> Note that the V4L2_MEMORY_ value is already checked in the v4l2
> core,
> >> drivers do not need to do that.
> > 
> > Just to clarify a bit, and make sure I understand this too. You are
> proposing to
> > introduce something like:
> > 
> >    V4L2_MEMORY_SECURE_DMABUF
> > 
> > Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
> telling the
> > driver that the memory is secure according to the definition of
> "secure" for the
> > platform its running on.
> > 
> > This drivers also allocate secure SHM (a standard tee concept) and
> have internal
> > allocation for reconstruction buffer and some hw specific reference
> metadata. So
> > the idea would be that it would keep allocation using the dmabuf
> heap internal
> > APIs ? And decide which type of memory based on the memory type
> found in the
> > queue?
> 
> Yes. Once you request the first buffer you basically tell the driver
> whether it
> will operate in secure or non-secure mode, and that stays that way
> until all
> buffers are freed. I think that makes sense.
> 

According to iommu's information, the dma operation for secure and non-
secure are the same, whether just need to add one memory type in v4l2
framework the same as V4L2_MEMORY_DMABUF? The dma operation in
videobuf2-dma-contig.c can use the same functions.

Best Regards,
Yunfei Dong

> If there is a need in the future to have V4L2 allocate the secure
> buffers, then
> a similar V4L2_MEMORY_MMAP_SECURE type can be added. I think using
> v4l2_memory
> to select secure or non-secure mode is logical and fits well with the
> V4L2 API.
> > Stepping back a little, why can't we have a way for drivers to
> detect that
> > dmabuf are secure ? I'm wondering if its actually useful to impose
> to all
> > userspace component to know that a dmabuf is secure ?
> 
> I was wondering the same thing: there should be a simple way for
> drivers and
> userspace to check if a dmabuf fd is secure or not. That will
> certainly help
> the vb2 framework verify that you don't mix secure and non-secure
> dmabuf fds.
> 
> > 
> > Also, regarding MTK, these are stateless decoders. I think it would
> be nice to
> > show use example code that can properly parse the un-encrypted
> header, pass the
> > data to the decryptor and decode. There is a bit of mechanic in
> there that lacks
> > clarification, a reference implementation would clearly help.
> Finally, does this
> > platform offers some clearkey implementation (or other alternative)
> so we can do
> > validation and regression testing? It would be very unfortunate to
> add feature
> > upstream that can only be tested by proprietary CDM software.
> 
> Good points.
> 
> Hans
> 
> > 
> > Nicolas
> > 
> >>
> >>>
> >>>>
> >>>> For converting the dmabuf fd into a secure handle: a new ioctl
> similar to
> >>>> VIDIOC_EXPBUF might be more suited for that.
> >>>
> >>> I actually think the best way for converting the dmabuf fd into a
> >>> secure handle would be another ioctl in the dma-heap
> driver...since
> >>> that's where the memory is actually allocated from. But this
> really
> >>> depends on upstream maintainers and what they are comfortable
> with.
> >>
> >> That feels like a more natural place of doing this.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>>
> >>>>
> >>>> Note that I am the first to admit that I have no experience with
> secure
> >>>> video pipelines or optee-os, so I am looking at this purely from
> an uAPI
> >>>> perspective.
> >>>>
> >>>> Regards,
> >>>>
> >>>>         Hans
> >>>>
> >>>>>
> >>>>> Best Regards,
> >>>>> Yunfei Dong
> >>>>>> Regards,
> >>>>>>
> >>>>>> Hans
> >>>>>>
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> Nicolas
> >>>>>>>
> >>>>>>> p.s. you forgot to document your control in the RST doc,
> please do
> >>>>>>
> >>>>>> in following
> >>>>>>> release.
> >>>>>>>
> >>>>>>>> +ctx->is_svp_mode = ctrl->val;
> >>>>>>>> +
> >>>>>>>> +if (ctx->is_svp_mode) {
> >>>>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>>>>>> +if (ret)
> >>>>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>>>>>> +else
> >>>>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d",
> ctrl-
> >>>>>>>
> >>>>>>> val);
> >>>>>>>> +}
> >>>>>>>> +break;
> >>>>>>>>  default:
> >>>>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>>>>>> 0x%x\n",
> >>>>>>
> >>>>>> hdr_ctrl->id);
> >>>>>>>>  return ret;
> >>>>>>>> @@ -573,7 +584,7 @@ static int
> mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>
> >>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>  unsigned int i;
> >>>>>>>>  struct v4l2_ctrl *ctrl;
> >>>>>>>>
> >>>>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>>>>>  if (ctx->ctrl_hdl.error) {
> >>>>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>>>>>  return ctx->ctrl_hdl.error;
> >>>>>>>> @@ -592,6 +603,8 @@ static int
> mtk_vcodec_dec_ctrls_setup(struct
> >>>>>>
> >>>>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>>>
> >>>>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>
> >>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>>>
> >>>>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>>>>>
> >>>>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>
> >>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> index d8cf01f76aab..a507045a3f30 100644
> >>>>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>>>>>> "Reference
> >>>>>>
> >>>>>> Frames for a P-Frame";
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return
> "Prepend
> >>>>>>
> >>>>>> SPS and PPS to IDR";
> >>>>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>>>>>> Decoder
> >>>>>>
> >>>>>> get secure handle";
> >>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek
> Decoder
> >>>>>>
> >>>>>> set secure mode";
> >>>>>>>>
> >>>>>>>>  /* AV1 controls */
> >>>>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const
> char
> >>>>>>
> >>>>>> **name, enum v4l2_ctrl_type *type,
> >>>>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>>  break;
> >>>>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>>> +break;
> >>>>>>>>  case V4L2_CID_USER_CLASS:
> >>>>>>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>>>>>  case V4L2_CID_CODEC_CLASS:
> >>>>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>>>>>
> >>>>>> b/include/uapi/linux/v4l2-controls.h
> >>>>>>>> index 7b3694985366..88e90d943e38 100644
> >>>>>>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>>>>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>>>>>> @@ -957,6 +957,7 @@ enum
> v4l2_mpeg_mfc51_video_force_frame_type {
> >>>>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>>>>>
> >>>>>> driver as defined by V4L2 */
> >>>>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC |
> 0x2000)
> >>>>>>>>  #define
> >>>>>>
> >>>>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>>>>>> +#define
> >>>>>>
> >>>>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>>>>>
> >>>>>>>>  /*  Camera class control IDs */
> >>>>>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> linux-arm-kernel mailing list
> >>>> linux-arm-kernel@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> > 
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
> Hi Hans,
> 
> Thanks for your help to give some good advice.
> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
>>  	 
>>>>>> In any case, using a control to switch to secure mode and using
>> a control
>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
>> me.
>>>>>>
>>>>>> I was wondering if it wouldn't be better to create a new
>> V4L2_MEMORY_ type,
>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
>> ensures that
>>>>>> once you create buffers for the first time, the driver can
>> switch into secure
>>>>>> mode, and until all buffers are released again you know that the
>> driver will
>>>>>> stay in secure mode.
>>>>>
>>>>> Why do you think the control for setting secure mode is a poor
>> choice?
>>>>> There's various places in the driver code where functionality
>> changes
>>>>> based on being secure/non-secure mode, so this is very much a
>> 'global'
>>>>> setting for the driver. It could be inferred based off a new
>> memory
>>>>> type for the queues...which then sets that flag in the driver;
>> but
>>>>> that seems like it would be more fragile and would require
>> checking
>>>>> for incompatible output/capture memory types. I'm not against
>> another
>>>>> way of doing this; but didn't see why you think the proposed
>> method is
>>>>> a poor choice.
>>>>
>>>> I assume you are either decoding to secure memory all the time, or
>> not
>>>> at all. That's something you would want to select the moment you
>> allocate
>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
>> natural place
>>>> for that. A control can typically be toggled at any time, and it
>> makes
>>>> no sense to do that for secure streaming.
>>>>
>>>> Related to that: if you pass a dmabuf fd you will need to check
>> somewhere
>>>> if the fd points to secure memory or not. You don't want to mix
>> the two
>>>> but you want to check that at VIDIOC_QBUF time.
>>>>
>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
>> core,
>>>> drivers do not need to do that.
>>>
>>> Just to clarify a bit, and make sure I understand this too. You are
>> proposing to
>>> introduce something like:
>>>
>>>    V4L2_MEMORY_SECURE_DMABUF
>>>
>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
>> telling the
>>> driver that the memory is secure according to the definition of
>> "secure" for the
>>> platform its running on.
>>>
>>> This drivers also allocate secure SHM (a standard tee concept) and
>> have internal
>>> allocation for reconstruction buffer and some hw specific reference
>> metadata. So
>>> the idea would be that it would keep allocation using the dmabuf
>> heap internal
>>> APIs ? And decide which type of memory based on the memory type
>> found in the
>>> queue?
>>
>> Yes. Once you request the first buffer you basically tell the driver
>> whether it
>> will operate in secure or non-secure mode, and that stays that way
>> until all
>> buffers are freed. I think that makes sense.
>>
> 
> According to iommu's information, the dma operation for secure and non-
> secure are the same, whether just need to add one memory type in v4l2
> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
> videobuf2-dma-contig.c can use the same functions.

So if I pass a non-secure dma fd to the capture queue of the codec, who
will check that it can't write the data to that fd? Since doing so would
expose the video. Presumably at some point the tee code will prevent that?
(I sincerely hope so!)

Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
for that (that avoids using a control to toggle between normal and secure mode),
and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
fd that is passed in is for secure memory. This means that mistakes by
userspace are caught at QBUF time.

Of course, this will not protect you (people can disable this check by
recompiling the kernel), that still has to be done by the firmware, but
it catches userspace errors early on.

Also, while for this hardware the DMA operation is the same, that might
not be the case for other hardware.

Regards,

	Hans

> 
> Best Regards,
> Yunfei Dong
> 

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
> > Hi Hans,
> >
> > Thanks for your help to give some good advice.
> > On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
> >>
> >>>>>> In any case, using a control to switch to secure mode and using
> >> a control
> >>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
> >> me.
> >>>>>>
> >>>>>> I was wondering if it wouldn't be better to create a new
> >> V4L2_MEMORY_ type,
> >>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> >> ensures that
> >>>>>> once you create buffers for the first time, the driver can
> >> switch into secure
> >>>>>> mode, and until all buffers are released again you know that the
> >> driver will
> >>>>>> stay in secure mode.
> >>>>>
> >>>>> Why do you think the control for setting secure mode is a poor
> >> choice?
> >>>>> There's various places in the driver code where functionality
> >> changes
> >>>>> based on being secure/non-secure mode, so this is very much a
> >> 'global'
> >>>>> setting for the driver. It could be inferred based off a new
> >> memory
> >>>>> type for the queues...which then sets that flag in the driver;
> >> but
> >>>>> that seems like it would be more fragile and would require
> >> checking
> >>>>> for incompatible output/capture memory types. I'm not against
> >> another
> >>>>> way of doing this; but didn't see why you think the proposed
> >> method is
> >>>>> a poor choice.
> >>>>
> >>>> I assume you are either decoding to secure memory all the time, or
> >> not
> >>>> at all. That's something you would want to select the moment you
> >> allocate
> >>>> the first buffer. Using the V4L2_MEMORY_ value would be the
> >> natural place
> >>>> for that. A control can typically be toggled at any time, and it
> >> makes
> >>>> no sense to do that for secure streaming.
> >>>>
> >>>> Related to that: if you pass a dmabuf fd you will need to check
> >> somewhere
> >>>> if the fd points to secure memory or not. You don't want to mix
> >> the two
> >>>> but you want to check that at VIDIOC_QBUF time.
> >>>>
> >>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
> >> core,
> >>>> drivers do not need to do that.
> >>>
> >>> Just to clarify a bit, and make sure I understand this too. You are
> >> proposing to
> >>> introduce something like:
> >>>
> >>>    V4L2_MEMORY_SECURE_DMABUF
> >>>
> >>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
> >> telling the
> >>> driver that the memory is secure according to the definition of
> >> "secure" for the
> >>> platform its running on.
> >>>
> >>> This drivers also allocate secure SHM (a standard tee concept) and
> >> have internal
> >>> allocation for reconstruction buffer and some hw specific reference
> >> metadata. So
> >>> the idea would be that it would keep allocation using the dmabuf
> >> heap internal
> >>> APIs ? And decide which type of memory based on the memory type
> >> found in the
> >>> queue?
> >>
> >> Yes. Once you request the first buffer you basically tell the driver
> >> whether it
> >> will operate in secure or non-secure mode, and that stays that way
> >> until all
> >> buffers are freed. I think that makes sense.
> >>
> >
> > According to iommu's information, the dma operation for secure and non-
> > secure are the same, whether just need to add one memory type in v4l2
> > framework the same as V4L2_MEMORY_DMABUF? The dma operation in
> > videobuf2-dma-contig.c can use the same functions.
>
> So if I pass a non-secure dma fd to the capture queue of the codec, who
> will check that it can't write the data to that fd? Since doing so would
> expose the video. Presumably at some point the tee code will prevent that?
> (I sincerely hope so!)

It is entirely the job of the TEE to prevent this. Nothing in the
kernel should allow exploitation of what happens in the TEE no matter
what goes on in the kernel

>
> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
> for that (that avoids using a control to toggle between normal and secure mode),
> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
> fd that is passed in is for secure memory. This means that mistakes by
> userspace are caught at QBUF time.
>
> Of course, this will not protect you (people can disable this check by
> recompiling the kernel), that still has to be done by the firmware, but
> it catches userspace errors early on.
>
> Also, while for this hardware the DMA operation is the same, that might
> not be the case for other hardware.

That's a really good point. So one of the other models that is used
for secure video decoding is to send the encrypted buffer into the
video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
all the corresponding crypto parameters (i.e. algorithm, IV,
encryption pattern, etc.). Then the video driver internally does the
decryption and decode in one operation.  That's not what we want to
use here for Mediatek; but I've done other integrations that work that
way (that was for VAAPI [1], not V4L2...but there are other ARM
implementations that do operate that way).  So if we end up requiring
V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
output+capture, that'll close off other potential solutions in the
future.

Expanding on your point about DMA operations being different on
various hardware, that also makes me think a general check for this in
v4l2 code may also be limiting. There are various ways secure video
pipelines are done, so leaving these checks up to the individual
drivers that implement secure video decode may be more pragmatic. If
there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
general for how drivers can handle secure video decode.

[1] - https://github.com/intel/libva/blob/master/va/va.h#L2177

>
> Regards,
>
>         Hans
>
> >
> > Best Regards,
> > Yunfei Dong
> >
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 22/09/2023 21:17, Jeffrey Kardatzke wrote:
> On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>
>> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
>>> Hi Hans,
>>>
>>> Thanks for your help to give some good advice.
>>> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
>>>>
>>>>>>>> In any case, using a control to switch to secure mode and using
>>>> a control
>>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
>>>> me.
>>>>>>>>
>>>>>>>> I was wondering if it wouldn't be better to create a new
>>>> V4L2_MEMORY_ type,
>>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
>>>> ensures that
>>>>>>>> once you create buffers for the first time, the driver can
>>>> switch into secure
>>>>>>>> mode, and until all buffers are released again you know that the
>>>> driver will
>>>>>>>> stay in secure mode.
>>>>>>>
>>>>>>> Why do you think the control for setting secure mode is a poor
>>>> choice?
>>>>>>> There's various places in the driver code where functionality
>>>> changes
>>>>>>> based on being secure/non-secure mode, so this is very much a
>>>> 'global'
>>>>>>> setting for the driver. It could be inferred based off a new
>>>> memory
>>>>>>> type for the queues...which then sets that flag in the driver;
>>>> but
>>>>>>> that seems like it would be more fragile and would require
>>>> checking
>>>>>>> for incompatible output/capture memory types. I'm not against
>>>> another
>>>>>>> way of doing this; but didn't see why you think the proposed
>>>> method is
>>>>>>> a poor choice.
>>>>>>
>>>>>> I assume you are either decoding to secure memory all the time, or
>>>> not
>>>>>> at all. That's something you would want to select the moment you
>>>> allocate
>>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
>>>> natural place
>>>>>> for that. A control can typically be toggled at any time, and it
>>>> makes
>>>>>> no sense to do that for secure streaming.
>>>>>>
>>>>>> Related to that: if you pass a dmabuf fd you will need to check
>>>> somewhere
>>>>>> if the fd points to secure memory or not. You don't want to mix
>>>> the two
>>>>>> but you want to check that at VIDIOC_QBUF time.
>>>>>>
>>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
>>>> core,
>>>>>> drivers do not need to do that.
>>>>>
>>>>> Just to clarify a bit, and make sure I understand this too. You are
>>>> proposing to
>>>>> introduce something like:
>>>>>
>>>>>    V4L2_MEMORY_SECURE_DMABUF
>>>>>
>>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
>>>> telling the
>>>>> driver that the memory is secure according to the definition of
>>>> "secure" for the
>>>>> platform its running on.
>>>>>
>>>>> This drivers also allocate secure SHM (a standard tee concept) and
>>>> have internal
>>>>> allocation for reconstruction buffer and some hw specific reference
>>>> metadata. So
>>>>> the idea would be that it would keep allocation using the dmabuf
>>>> heap internal
>>>>> APIs ? And decide which type of memory based on the memory type
>>>> found in the
>>>>> queue?
>>>>
>>>> Yes. Once you request the first buffer you basically tell the driver
>>>> whether it
>>>> will operate in secure or non-secure mode, and that stays that way
>>>> until all
>>>> buffers are freed. I think that makes sense.
>>>>
>>>
>>> According to iommu's information, the dma operation for secure and non-
>>> secure are the same, whether just need to add one memory type in v4l2
>>> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
>>> videobuf2-dma-contig.c can use the same functions.
>>
>> So if I pass a non-secure dma fd to the capture queue of the codec, who
>> will check that it can't write the data to that fd? Since doing so would
>> expose the video. Presumably at some point the tee code will prevent that?
>> (I sincerely hope so!)
> 
> It is entirely the job of the TEE to prevent this. Nothing in the
> kernel should allow exploitation of what happens in the TEE no matter
> what goes on in the kernel
> 
>>
>> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
>> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
>> for that (that avoids using a control to toggle between normal and secure mode),
>> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
>> fd that is passed in is for secure memory. This means that mistakes by
>> userspace are caught at QBUF time.
>>
>> Of course, this will not protect you (people can disable this check by
>> recompiling the kernel), that still has to be done by the firmware, but
>> it catches userspace errors early on.
>>
>> Also, while for this hardware the DMA operation is the same, that might
>> not be the case for other hardware.
> 
> That's a really good point. So one of the other models that is used
> for secure video decoding is to send the encrypted buffer into the
> video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
> all the corresponding crypto parameters (i.e. algorithm, IV,
> encryption pattern, etc.). Then the video driver internally does the
> decryption and decode in one operation.  That's not what we want to
> use here for Mediatek; but I've done other integrations that work that
> way (that was for VAAPI [1], not V4L2...but there are other ARM
> implementations that do operate that way).  So if we end up requiring
> V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
> output+capture, that'll close off other potential solutions in the
> future.
> 
> Expanding on your point about DMA operations being different on
> various hardware, that also makes me think a general check for this in
> v4l2 code may also be limiting. There are various ways secure video
> pipelines are done, so leaving these checks up to the individual
> drivers that implement secure video decode may be more pragmatic. If
> there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
> general for how drivers can handle secure video decode.

No, using a control for this is really wrong.

The reason why I want it as a separate memory type is that that is
what you use when you call VIDIOC_REQBUFS, and that ioctl is also
when things are locked down in a driver. As long as no buffers have
been allocated, you can still change formats, parameters, etc. But
once buffers are allocated, most of that can't be changed, since
changing e.g. the format would also change the buffer sizes.

It also locks down who owns the buffers by storing the file descriptor.
This prevents other processes from hijacking the I/O streaming, only
the owner can stream buffers.

So it is a natural point in the sequence for selecting secure
buffers.

If you request V4L2_MEMORY_DMABUF_SECURE for the output, then the
capture side must also use DMABUF_SECURE. Whether or not you can
use regular DMABUF for the output side and select DMABUF_SECURE
on the capture side is a driver decision. It can be useful to
support this for testing the secure capture using regular video
streams (something Nicolas discussed as well), but it depends on
the hardware whether you can use that technique.

Regards,

	Hans

> 
> [1] - https://github.com/intel/libva/blob/master/va/va.h#L2177
> 
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>> Best Regards,
>>> Yunfei Dong
>>>
>>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Mon, Sep 25, 2023 at 2:00 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 22/09/2023 21:17, Jeffrey Kardatzke wrote:
> > On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>
> >> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
> >>> Hi Hans,
> >>>
> >>> Thanks for your help to give some good advice.
> >>> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
> >>>>
> >>>>>>>> In any case, using a control to switch to secure mode and using
> >>>> a control
> >>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
> >>>> me.
> >>>>>>>>
> >>>>>>>> I was wondering if it wouldn't be better to create a new
> >>>> V4L2_MEMORY_ type,
> >>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> >>>> ensures that
> >>>>>>>> once you create buffers for the first time, the driver can
> >>>> switch into secure
> >>>>>>>> mode, and until all buffers are released again you know that the
> >>>> driver will
> >>>>>>>> stay in secure mode.
> >>>>>>>
> >>>>>>> Why do you think the control for setting secure mode is a poor
> >>>> choice?
> >>>>>>> There's various places in the driver code where functionality
> >>>> changes
> >>>>>>> based on being secure/non-secure mode, so this is very much a
> >>>> 'global'
> >>>>>>> setting for the driver. It could be inferred based off a new
> >>>> memory
> >>>>>>> type for the queues...which then sets that flag in the driver;
> >>>> but
> >>>>>>> that seems like it would be more fragile and would require
> >>>> checking
> >>>>>>> for incompatible output/capture memory types. I'm not against
> >>>> another
> >>>>>>> way of doing this; but didn't see why you think the proposed
> >>>> method is
> >>>>>>> a poor choice.
> >>>>>>
> >>>>>> I assume you are either decoding to secure memory all the time, or
> >>>> not
> >>>>>> at all. That's something you would want to select the moment you
> >>>> allocate
> >>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
> >>>> natural place
> >>>>>> for that. A control can typically be toggled at any time, and it
> >>>> makes
> >>>>>> no sense to do that for secure streaming.
> >>>>>>
> >>>>>> Related to that: if you pass a dmabuf fd you will need to check
> >>>> somewhere
> >>>>>> if the fd points to secure memory or not. You don't want to mix
> >>>> the two
> >>>>>> but you want to check that at VIDIOC_QBUF time.
> >>>>>>
> >>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
> >>>> core,
> >>>>>> drivers do not need to do that.
> >>>>>
> >>>>> Just to clarify a bit, and make sure I understand this too. You are
> >>>> proposing to
> >>>>> introduce something like:
> >>>>>
> >>>>>    V4L2_MEMORY_SECURE_DMABUF
> >>>>>
> >>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
> >>>> telling the
> >>>>> driver that the memory is secure according to the definition of
> >>>> "secure" for the
> >>>>> platform its running on.
> >>>>>
> >>>>> This drivers also allocate secure SHM (a standard tee concept) and
> >>>> have internal
> >>>>> allocation for reconstruction buffer and some hw specific reference
> >>>> metadata. So
> >>>>> the idea would be that it would keep allocation using the dmabuf
> >>>> heap internal
> >>>>> APIs ? And decide which type of memory based on the memory type
> >>>> found in the
> >>>>> queue?
> >>>>
> >>>> Yes. Once you request the first buffer you basically tell the driver
> >>>> whether it
> >>>> will operate in secure or non-secure mode, and that stays that way
> >>>> until all
> >>>> buffers are freed. I think that makes sense.
> >>>>
> >>>
> >>> According to iommu's information, the dma operation for secure and non-
> >>> secure are the same, whether just need to add one memory type in v4l2
> >>> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
> >>> videobuf2-dma-contig.c can use the same functions.
> >>
> >> So if I pass a non-secure dma fd to the capture queue of the codec, who
> >> will check that it can't write the data to that fd? Since doing so would
> >> expose the video. Presumably at some point the tee code will prevent that?
> >> (I sincerely hope so!)
> >
> > It is entirely the job of the TEE to prevent this. Nothing in the
> > kernel should allow exploitation of what happens in the TEE no matter
> > what goes on in the kernel
> >
> >>
> >> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
> >> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
> >> for that (that avoids using a control to toggle between normal and secure mode),
> >> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
> >> fd that is passed in is for secure memory. This means that mistakes by
> >> userspace are caught at QBUF time.
> >>
> >> Of course, this will not protect you (people can disable this check by
> >> recompiling the kernel), that still has to be done by the firmware, but
> >> it catches userspace errors early on.
> >>
> >> Also, while for this hardware the DMA operation is the same, that might
> >> not be the case for other hardware.
> >
> > That's a really good point. So one of the other models that is used
> > for secure video decoding is to send the encrypted buffer into the
> > video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
> > all the corresponding crypto parameters (i.e. algorithm, IV,
> > encryption pattern, etc.). Then the video driver internally does the
> > decryption and decode in one operation.  That's not what we want to
> > use here for Mediatek; but I've done other integrations that work that
> > way (that was for VAAPI [1], not V4L2...but there are other ARM
> > implementations that do operate that way).  So if we end up requiring
> > V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
> > output+capture, that'll close off other potential solutions in the
> > future.
> >
> > Expanding on your point about DMA operations being different on
> > various hardware, that also makes me think a general check for this in
> > v4l2 code may also be limiting. There are various ways secure video
> > pipelines are done, so leaving these checks up to the individual
> > drivers that implement secure video decode may be more pragmatic. If
> > there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
> > general for how drivers can handle secure video decode.
>
> No, using a control for this is really wrong.
>
> The reason why I want it as a separate memory type is that that is
> what you use when you call VIDIOC_REQBUFS, and that ioctl is also
> when things are locked down in a driver. As long as no buffers have
> been allocated, you can still change formats, parameters, etc. But
> once buffers are allocated, most of that can't be changed, since
> changing e.g. the format would also change the buffer sizes.
>
> It also locks down who owns the buffers by storing the file descriptor.
> This prevents other processes from hijacking the I/O streaming, only
> the owner can stream buffers.
>
> So it is a natural point in the sequence for selecting secure
> buffers.
>
> If you request V4L2_MEMORY_DMABUF_SECURE for the output, then the
> capture side must also use DMABUF_SECURE. Whether or not you can
> use regular DMABUF for the output side and select DMABUF_SECURE
> on the capture side is a driver decision. It can be useful to
> support this for testing the secure capture using regular video
> streams (something Nicolas discussed as well), but it depends on
> the hardware whether you can use that technique.

OK, that does work for the additional cases I mentioned.  And for
testing...we would still want to use DMABUF_SECURE on both ends for
Mediatek at least (that's the only way they support it). But rather
than having to bother with a clearkey implementation...we can just do
something that directly copies compressed video into the secure
dmabufs and then exercises the whole pipeline from there. This same
thing happens with the 'clear lead' that is sometimes there with
encrypted video (where the first X seconds are unencrypted and then it
switches to encrypted...but you're still using the secure video
pipeline on the unencrypted frames in that case).


>
> Regards,
>
>         Hans
>
> >
> > [1] - https://github.com/intel/libva/blob/master/va/va.h#L2177
> >
> >>
> >> Regards,
> >>
> >>         Hans
> >>
> >>>
> >>> Best Regards,
> >>> Yunfei Dong
> >>>
> >>
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

Hans,

I've been looking through the v4l2/vbuf2 code to get an idea of the
details for implementing a new memory type for secure buffers.  What
it comes down to essentially is that it would behave just like
V4L2_MEMORY_DMABUF, but then there would be an extra check in
__prepare_dmabuf (in videobuf2-core.c) when the memory type is SECURE
to ensure that it is actually from a secure dma-buf allocation.  So
I'm thinking an alternate solution might be cleaner so we don't have
two memory types that are handled nearly identically in most of the
code. What do you think about a new memory flag like
V4L2_MEMORY_FLAG_SECURE?  This would be set in vb2_queue struct like
the other existing memory flag. Then when it gets into
__prepare_dmabuf and invokes attach_dmabuf on each buffer...that call
could then check for the existence of that flag, and if it's there it
could validate it is actually secure memory.  Then in various other
dmabuf vb2_mem_ops (maybe alloc, get_userptr, vaddr and mmap) those
could also check for the secure flag, and if present return an
error/null.  Then also in the driver specific vb2_ops for queue_setup,
the MTK driver could recognize the flag there and then configure
itself for secure mode.

How does that sound as an overall strategy?

Cheers,
Jeff

On Mon, Sep 25, 2023 at 9:51 AM Jeffrey Kardatzke <jkardatzke@google.com> wrote:
>
> On Mon, Sep 25, 2023 at 2:00 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >
> > On 22/09/2023 21:17, Jeffrey Kardatzke wrote:
> > > On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> > >>
> > >> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
> > >>> Hi Hans,
> > >>>
> > >>> Thanks for your help to give some good advice.
> > >>> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
> > >>>>
> > >>>>>>>> In any case, using a control to switch to secure mode and using
> > >>>> a control
> > >>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
> > >>>> me.
> > >>>>>>>>
> > >>>>>>>> I was wondering if it wouldn't be better to create a new
> > >>>> V4L2_MEMORY_ type,
> > >>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> > >>>> ensures that
> > >>>>>>>> once you create buffers for the first time, the driver can
> > >>>> switch into secure
> > >>>>>>>> mode, and until all buffers are released again you know that the
> > >>>> driver will
> > >>>>>>>> stay in secure mode.
> > >>>>>>>
> > >>>>>>> Why do you think the control for setting secure mode is a poor
> > >>>> choice?
> > >>>>>>> There's various places in the driver code where functionality
> > >>>> changes
> > >>>>>>> based on being secure/non-secure mode, so this is very much a
> > >>>> 'global'
> > >>>>>>> setting for the driver. It could be inferred based off a new
> > >>>> memory
> > >>>>>>> type for the queues...which then sets that flag in the driver;
> > >>>> but
> > >>>>>>> that seems like it would be more fragile and would require
> > >>>> checking
> > >>>>>>> for incompatible output/capture memory types. I'm not against
> > >>>> another
> > >>>>>>> way of doing this; but didn't see why you think the proposed
> > >>>> method is
> > >>>>>>> a poor choice.
> > >>>>>>
> > >>>>>> I assume you are either decoding to secure memory all the time, or
> > >>>> not
> > >>>>>> at all. That's something you would want to select the moment you
> > >>>> allocate
> > >>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
> > >>>> natural place
> > >>>>>> for that. A control can typically be toggled at any time, and it
> > >>>> makes
> > >>>>>> no sense to do that for secure streaming.
> > >>>>>>
> > >>>>>> Related to that: if you pass a dmabuf fd you will need to check
> > >>>> somewhere
> > >>>>>> if the fd points to secure memory or not. You don't want to mix
> > >>>> the two
> > >>>>>> but you want to check that at VIDIOC_QBUF time.
> > >>>>>>
> > >>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
> > >>>> core,
> > >>>>>> drivers do not need to do that.
> > >>>>>
> > >>>>> Just to clarify a bit, and make sure I understand this too. You are
> > >>>> proposing to
> > >>>>> introduce something like:
> > >>>>>
> > >>>>>    V4L2_MEMORY_SECURE_DMABUF
> > >>>>>
> > >>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
> > >>>> telling the
> > >>>>> driver that the memory is secure according to the definition of
> > >>>> "secure" for the
> > >>>>> platform its running on.
> > >>>>>
> > >>>>> This drivers also allocate secure SHM (a standard tee concept) and
> > >>>> have internal
> > >>>>> allocation for reconstruction buffer and some hw specific reference
> > >>>> metadata. So
> > >>>>> the idea would be that it would keep allocation using the dmabuf
> > >>>> heap internal
> > >>>>> APIs ? And decide which type of memory based on the memory type
> > >>>> found in the
> > >>>>> queue?
> > >>>>
> > >>>> Yes. Once you request the first buffer you basically tell the driver
> > >>>> whether it
> > >>>> will operate in secure or non-secure mode, and that stays that way
> > >>>> until all
> > >>>> buffers are freed. I think that makes sense.
> > >>>>
> > >>>
> > >>> According to iommu's information, the dma operation for secure and non-
> > >>> secure are the same, whether just need to add one memory type in v4l2
> > >>> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
> > >>> videobuf2-dma-contig.c can use the same functions.
> > >>
> > >> So if I pass a non-secure dma fd to the capture queue of the codec, who
> > >> will check that it can't write the data to that fd? Since doing so would
> > >> expose the video. Presumably at some point the tee code will prevent that?
> > >> (I sincerely hope so!)
> > >
> > > It is entirely the job of the TEE to prevent this. Nothing in the
> > > kernel should allow exploitation of what happens in the TEE no matter
> > > what goes on in the kernel
> > >
> > >>
> > >> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
> > >> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
> > >> for that (that avoids using a control to toggle between normal and secure mode),
> > >> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
> > >> fd that is passed in is for secure memory. This means that mistakes by
> > >> userspace are caught at QBUF time.
> > >>
> > >> Of course, this will not protect you (people can disable this check by
> > >> recompiling the kernel), that still has to be done by the firmware, but
> > >> it catches userspace errors early on.
> > >>
> > >> Also, while for this hardware the DMA operation is the same, that might
> > >> not be the case for other hardware.
> > >
> > > That's a really good point. So one of the other models that is used
> > > for secure video decoding is to send the encrypted buffer into the
> > > video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
> > > all the corresponding crypto parameters (i.e. algorithm, IV,
> > > encryption pattern, etc.). Then the video driver internally does the
> > > decryption and decode in one operation.  That's not what we want to
> > > use here for Mediatek; but I've done other integrations that work that
> > > way (that was for VAAPI [1], not V4L2...but there are other ARM
> > > implementations that do operate that way).  So if we end up requiring
> > > V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
> > > output+capture, that'll close off other potential solutions in the
> > > future.
> > >
> > > Expanding on your point about DMA operations being different on
> > > various hardware, that also makes me think a general check for this in
> > > v4l2 code may also be limiting. There are various ways secure video
> > > pipelines are done, so leaving these checks up to the individual
> > > drivers that implement secure video decode may be more pragmatic. If
> > > there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
> > > general for how drivers can handle secure video decode.
> >
> > No, using a control for this is really wrong.
> >
> > The reason why I want it as a separate memory type is that that is
> > what you use when you call VIDIOC_REQBUFS, and that ioctl is also
> > when things are locked down in a driver. As long as no buffers have
> > been allocated, you can still change formats, parameters, etc. But
> > once buffers are allocated, most of that can't be changed, since
> > changing e.g. the format would also change the buffer sizes.
> >
> > It also locks down who owns the buffers by storing the file descriptor.
> > This prevents other processes from hijacking the I/O streaming, only
> > the owner can stream buffers.
> >
> > So it is a natural point in the sequence for selecting secure
> > buffers.
> >
> > If you request V4L2_MEMORY_DMABUF_SECURE for the output, then the
> > capture side must also use DMABUF_SECURE. Whether or not you can
> > use regular DMABUF for the output side and select DMABUF_SECURE
> > on the capture side is a driver decision. It can be useful to
> > support this for testing the secure capture using regular video
> > streams (something Nicolas discussed as well), but it depends on
> > the hardware whether you can use that technique.
>
> OK, that does work for the additional cases I mentioned.  And for
> testing...we would still want to use DMABUF_SECURE on both ends for
> Mediatek at least (that's the only way they support it). But rather
> than having to bother with a clearkey implementation...we can just do
> something that directly copies compressed video into the secure
> dmabufs and then exercises the whole pipeline from there. This same
> thing happens with the 'clear lead' that is sometimes there with
> encrypted video (where the first X seconds are unencrypted and then it
> switches to encrypted...but you're still using the secure video
> pipeline on the unencrypted frames in that case).
>
>
> >
> > Regards,
> >
> >         Hans
> >
> > >
> > > [1] - https://github.com/intel/libva/blob/master/va/va.h#L2177
> > >
> > >>
> > >> Regards,
> > >>
> > >>         Hans
> > >>
> > >>>
> > >>> Best Regards,
> > >>> Yunfei Dong
> > >>>
> > >>
> >

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Hans Verkuil]

On 26/09/2023 22:59, Jeffrey Kardatzke wrote:
> Hans,
> 
> I've been looking through the v4l2/vbuf2 code to get an idea of the
> details for implementing a new memory type for secure buffers.  What
> it comes down to essentially is that it would behave just like
> V4L2_MEMORY_DMABUF, but then there would be an extra check in
> __prepare_dmabuf (in videobuf2-core.c) when the memory type is SECURE
> to ensure that it is actually from a secure dma-buf allocation.  So
> I'm thinking an alternate solution might be cleaner so we don't have
> two memory types that are handled nearly identically in most of the
> code. What do you think about a new memory flag like
> V4L2_MEMORY_FLAG_SECURE?  This would be set in vb2_queue struct like
> the other existing memory flag. Then when it gets into
> __prepare_dmabuf and invokes attach_dmabuf on each buffer...that call
> could then check for the existence of that flag, and if it's there it
> could validate it is actually secure memory.  Then in various other
> dmabuf vb2_mem_ops (maybe alloc, get_userptr, vaddr and mmap) those
> could also check for the secure flag, and if present return an
> error/null.  Then also in the driver specific vb2_ops for queue_setup,
> the MTK driver could recognize the flag there and then configure
> itself for secure mode.
> 
> How does that sound as an overall strategy?

Yes, I actually had the same thought.

You would also need a new capability: V4L2_BUF_CAP_SUPPORTS_SECURE_MEMORY

It makes more sense than creating a new V4L2_MEMORY_ type, and it still
is handled at the right place (creating the buffers).

Regards,

	Hans

> 
> Cheers,
> Jeff
> 
> On Mon, Sep 25, 2023 at 9:51 AM Jeffrey Kardatzke <jkardatzke@google.com> wrote:
>>
>> On Mon, Sep 25, 2023 at 2:00 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>
>>> On 22/09/2023 21:17, Jeffrey Kardatzke wrote:
>>>> On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>>>
>>>>> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
>>>>>> Hi Hans,
>>>>>>
>>>>>> Thanks for your help to give some good advice.
>>>>>> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
>>>>>>>
>>>>>>>>>>> In any case, using a control to switch to secure mode and using
>>>>>>> a control
>>>>>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
>>>>>>> me.
>>>>>>>>>>>
>>>>>>>>>>> I was wondering if it wouldn't be better to create a new
>>>>>>> V4L2_MEMORY_ type,
>>>>>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
>>>>>>> ensures that
>>>>>>>>>>> once you create buffers for the first time, the driver can
>>>>>>> switch into secure
>>>>>>>>>>> mode, and until all buffers are released again you know that the
>>>>>>> driver will
>>>>>>>>>>> stay in secure mode.
>>>>>>>>>>
>>>>>>>>>> Why do you think the control for setting secure mode is a poor
>>>>>>> choice?
>>>>>>>>>> There's various places in the driver code where functionality
>>>>>>> changes
>>>>>>>>>> based on being secure/non-secure mode, so this is very much a
>>>>>>> 'global'
>>>>>>>>>> setting for the driver. It could be inferred based off a new
>>>>>>> memory
>>>>>>>>>> type for the queues...which then sets that flag in the driver;
>>>>>>> but
>>>>>>>>>> that seems like it would be more fragile and would require
>>>>>>> checking
>>>>>>>>>> for incompatible output/capture memory types. I'm not against
>>>>>>> another
>>>>>>>>>> way of doing this; but didn't see why you think the proposed
>>>>>>> method is
>>>>>>>>>> a poor choice.
>>>>>>>>>
>>>>>>>>> I assume you are either decoding to secure memory all the time, or
>>>>>>> not
>>>>>>>>> at all. That's something you would want to select the moment you
>>>>>>> allocate
>>>>>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
>>>>>>> natural place
>>>>>>>>> for that. A control can typically be toggled at any time, and it
>>>>>>> makes
>>>>>>>>> no sense to do that for secure streaming.
>>>>>>>>>
>>>>>>>>> Related to that: if you pass a dmabuf fd you will need to check
>>>>>>> somewhere
>>>>>>>>> if the fd points to secure memory or not. You don't want to mix
>>>>>>> the two
>>>>>>>>> but you want to check that at VIDIOC_QBUF time.
>>>>>>>>>
>>>>>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
>>>>>>> core,
>>>>>>>>> drivers do not need to do that.
>>>>>>>>
>>>>>>>> Just to clarify a bit, and make sure I understand this too. You are
>>>>>>> proposing to
>>>>>>>> introduce something like:
>>>>>>>>
>>>>>>>>    V4L2_MEMORY_SECURE_DMABUF
>>>>>>>>
>>>>>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
>>>>>>> telling the
>>>>>>>> driver that the memory is secure according to the definition of
>>>>>>> "secure" for the
>>>>>>>> platform its running on.
>>>>>>>>
>>>>>>>> This drivers also allocate secure SHM (a standard tee concept) and
>>>>>>> have internal
>>>>>>>> allocation for reconstruction buffer and some hw specific reference
>>>>>>> metadata. So
>>>>>>>> the idea would be that it would keep allocation using the dmabuf
>>>>>>> heap internal
>>>>>>>> APIs ? And decide which type of memory based on the memory type
>>>>>>> found in the
>>>>>>>> queue?
>>>>>>>
>>>>>>> Yes. Once you request the first buffer you basically tell the driver
>>>>>>> whether it
>>>>>>> will operate in secure or non-secure mode, and that stays that way
>>>>>>> until all
>>>>>>> buffers are freed. I think that makes sense.
>>>>>>>
>>>>>>
>>>>>> According to iommu's information, the dma operation for secure and non-
>>>>>> secure are the same, whether just need to add one memory type in v4l2
>>>>>> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
>>>>>> videobuf2-dma-contig.c can use the same functions.
>>>>>
>>>>> So if I pass a non-secure dma fd to the capture queue of the codec, who
>>>>> will check that it can't write the data to that fd? Since doing so would
>>>>> expose the video. Presumably at some point the tee code will prevent that?
>>>>> (I sincerely hope so!)
>>>>
>>>> It is entirely the job of the TEE to prevent this. Nothing in the
>>>> kernel should allow exploitation of what happens in the TEE no matter
>>>> what goes on in the kernel
>>>>
>>>>>
>>>>> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
>>>>> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
>>>>> for that (that avoids using a control to toggle between normal and secure mode),
>>>>> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
>>>>> fd that is passed in is for secure memory. This means that mistakes by
>>>>> userspace are caught at QBUF time.
>>>>>
>>>>> Of course, this will not protect you (people can disable this check by
>>>>> recompiling the kernel), that still has to be done by the firmware, but
>>>>> it catches userspace errors early on.
>>>>>
>>>>> Also, while for this hardware the DMA operation is the same, that might
>>>>> not be the case for other hardware.
>>>>
>>>> That's a really good point. So one of the other models that is used
>>>> for secure video decoding is to send the encrypted buffer into the
>>>> video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
>>>> all the corresponding crypto parameters (i.e. algorithm, IV,
>>>> encryption pattern, etc.). Then the video driver internally does the
>>>> decryption and decode in one operation.  That's not what we want to
>>>> use here for Mediatek; but I've done other integrations that work that
>>>> way (that was for VAAPI [1], not V4L2...but there are other ARM
>>>> implementations that do operate that way).  So if we end up requiring
>>>> V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
>>>> output+capture, that'll close off other potential solutions in the
>>>> future.
>>>>
>>>> Expanding on your point about DMA operations being different on
>>>> various hardware, that also makes me think a general check for this in
>>>> v4l2 code may also be limiting. There are various ways secure video
>>>> pipelines are done, so leaving these checks up to the individual
>>>> drivers that implement secure video decode may be more pragmatic. If
>>>> there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
>>>> general for how drivers can handle secure video decode.
>>>
>>> No, using a control for this is really wrong.
>>>
>>> The reason why I want it as a separate memory type is that that is
>>> what you use when you call VIDIOC_REQBUFS, and that ioctl is also
>>> when things are locked down in a driver. As long as no buffers have
>>> been allocated, you can still change formats, parameters, etc. But
>>> once buffers are allocated, most of that can't be changed, since
>>> changing e.g. the format would also change the buffer sizes.
>>>
>>> It also locks down who owns the buffers by storing the file descriptor.
>>> This prevents other processes from hijacking the I/O streaming, only
>>> the owner can stream buffers.
>>>
>>> So it is a natural point in the sequence for selecting secure
>>> buffers.
>>>
>>> If you request V4L2_MEMORY_DMABUF_SECURE for the output, then the
>>> capture side must also use DMABUF_SECURE. Whether or not you can
>>> use regular DMABUF for the output side and select DMABUF_SECURE
>>> on the capture side is a driver decision. It can be useful to
>>> support this for testing the secure capture using regular video
>>> streams (something Nicolas discussed as well), but it depends on
>>> the hardware whether you can use that technique.
>>
>> OK, that does work for the additional cases I mentioned.  And for
>> testing...we would still want to use DMABUF_SECURE on both ends for
>> Mediatek at least (that's the only way they support it). But rather
>> than having to bother with a clearkey implementation...we can just do
>> something that directly copies compressed video into the secure
>> dmabufs and then exercises the whole pipeline from there. This same
>> thing happens with the 'clear lead' that is sometimes there with
>> encrypted video (where the first X seconds are unencrypted and then it
>> switches to encrypted...but you're still using the secure video
>> pipeline on the unencrypted frames in that case).
>>
>>
>>>
>>> Regards,
>>>
>>>         Hans
>>>
>>>>
>>>> [1] - https://github.com/intel/libva/blob/master/va/va.h#L2177
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>         Hans
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Yunfei Dong
>>>>>>
>>>>>
>>>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

Sounds great Hans! I'll work with Mediatek to update their code for that.

On Wed, Sep 27, 2023 at 12:26 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 26/09/2023 22:59, Jeffrey Kardatzke wrote:
> > Hans,
> >
> > I've been looking through the v4l2/vbuf2 code to get an idea of the
> > details for implementing a new memory type for secure buffers.  What
> > it comes down to essentially is that it would behave just like
> > V4L2_MEMORY_DMABUF, but then there would be an extra check in
> > __prepare_dmabuf (in videobuf2-core.c) when the memory type is SECURE
> > to ensure that it is actually from a secure dma-buf allocation.  So
> > I'm thinking an alternate solution might be cleaner so we don't have
> > two memory types that are handled nearly identically in most of the
> > code. What do you think about a new memory flag like
> > V4L2_MEMORY_FLAG_SECURE?  This would be set in vb2_queue struct like
> > the other existing memory flag. Then when it gets into
> > __prepare_dmabuf and invokes attach_dmabuf on each buffer...that call
> > could then check for the existence of that flag, and if it's there it
> > could validate it is actually secure memory.  Then in various other
> > dmabuf vb2_mem_ops (maybe alloc, get_userptr, vaddr and mmap) those
> > could also check for the secure flag, and if present return an
> > error/null.  Then also in the driver specific vb2_ops for queue_setup,
> > the MTK driver could recognize the flag there and then configure
> > itself for secure mode.
> >
> > How does that sound as an overall strategy?
>
> Yes, I actually had the same thought.
>
> You would also need a new capability: V4L2_BUF_CAP_SUPPORTS_SECURE_MEMORY
>
> It makes more sense than creating a new V4L2_MEMORY_ type, and it still
> is handled at the right place (creating the buffers).
>
> Regards,
>
>         Hans
>
> >
> > Cheers,
> > Jeff
> >
> > On Mon, Sep 25, 2023 at 9:51 AM Jeffrey Kardatzke <jkardatzke@google.com> wrote:
> >>
> >> On Mon, Sep 25, 2023 at 2:00 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>>
> >>> On 22/09/2023 21:17, Jeffrey Kardatzke wrote:
> >>>> On Fri, Sep 22, 2023 at 1:44 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>>>>
> >>>>> On 22/09/2023 05:28, Yunfei Dong (董云飞) wrote:
> >>>>>> Hi Hans,
> >>>>>>
> >>>>>> Thanks for your help to give some good advice.
> >>>>>> On Wed, 2023-09-20 at 09:20 +0200, Hans Verkuil wrote:
> >>>>>>>
> >>>>>>>>>>> In any case, using a control to switch to secure mode and using
> >>>>>>> a control
> >>>>>>>>>>> to convert a dmabuf fd to a secure handle seems a poor choice to
> >>>>>>> me.
> >>>>>>>>>>>
> >>>>>>>>>>> I was wondering if it wouldn't be better to create a new
> >>>>>>> V4L2_MEMORY_ type,
> >>>>>>>>>>> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That
> >>>>>>> ensures that
> >>>>>>>>>>> once you create buffers for the first time, the driver can
> >>>>>>> switch into secure
> >>>>>>>>>>> mode, and until all buffers are released again you know that the
> >>>>>>> driver will
> >>>>>>>>>>> stay in secure mode.
> >>>>>>>>>>
> >>>>>>>>>> Why do you think the control for setting secure mode is a poor
> >>>>>>> choice?
> >>>>>>>>>> There's various places in the driver code where functionality
> >>>>>>> changes
> >>>>>>>>>> based on being secure/non-secure mode, so this is very much a
> >>>>>>> 'global'
> >>>>>>>>>> setting for the driver. It could be inferred based off a new
> >>>>>>> memory
> >>>>>>>>>> type for the queues...which then sets that flag in the driver;
> >>>>>>> but
> >>>>>>>>>> that seems like it would be more fragile and would require
> >>>>>>> checking
> >>>>>>>>>> for incompatible output/capture memory types. I'm not against
> >>>>>>> another
> >>>>>>>>>> way of doing this; but didn't see why you think the proposed
> >>>>>>> method is
> >>>>>>>>>> a poor choice.
> >>>>>>>>>
> >>>>>>>>> I assume you are either decoding to secure memory all the time, or
> >>>>>>> not
> >>>>>>>>> at all. That's something you would want to select the moment you
> >>>>>>> allocate
> >>>>>>>>> the first buffer. Using the V4L2_MEMORY_ value would be the
> >>>>>>> natural place
> >>>>>>>>> for that. A control can typically be toggled at any time, and it
> >>>>>>> makes
> >>>>>>>>> no sense to do that for secure streaming.
> >>>>>>>>>
> >>>>>>>>> Related to that: if you pass a dmabuf fd you will need to check
> >>>>>>> somewhere
> >>>>>>>>> if the fd points to secure memory or not. You don't want to mix
> >>>>>>> the two
> >>>>>>>>> but you want to check that at VIDIOC_QBUF time.
> >>>>>>>>>
> >>>>>>>>> Note that the V4L2_MEMORY_ value is already checked in the v4l2
> >>>>>>> core,
> >>>>>>>>> drivers do not need to do that.
> >>>>>>>>
> >>>>>>>> Just to clarify a bit, and make sure I understand this too. You are
> >>>>>>> proposing to
> >>>>>>>> introduce something like:
> >>>>>>>>
> >>>>>>>>    V4L2_MEMORY_SECURE_DMABUF
> >>>>>>>>
> >>>>>>>> Which like V4L2_MEMORY_DMABUF is meant to import dmabuf, while
> >>>>>>> telling the
> >>>>>>>> driver that the memory is secure according to the definition of
> >>>>>>> "secure" for the
> >>>>>>>> platform its running on.
> >>>>>>>>
> >>>>>>>> This drivers also allocate secure SHM (a standard tee concept) and
> >>>>>>> have internal
> >>>>>>>> allocation for reconstruction buffer and some hw specific reference
> >>>>>>> metadata. So
> >>>>>>>> the idea would be that it would keep allocation using the dmabuf
> >>>>>>> heap internal
> >>>>>>>> APIs ? And decide which type of memory based on the memory type
> >>>>>>> found in the
> >>>>>>>> queue?
> >>>>>>>
> >>>>>>> Yes. Once you request the first buffer you basically tell the driver
> >>>>>>> whether it
> >>>>>>> will operate in secure or non-secure mode, and that stays that way
> >>>>>>> until all
> >>>>>>> buffers are freed. I think that makes sense.
> >>>>>>>
> >>>>>>
> >>>>>> According to iommu's information, the dma operation for secure and non-
> >>>>>> secure are the same, whether just need to add one memory type in v4l2
> >>>>>> framework the same as V4L2_MEMORY_DMABUF? The dma operation in
> >>>>>> videobuf2-dma-contig.c can use the same functions.
> >>>>>
> >>>>> So if I pass a non-secure dma fd to the capture queue of the codec, who
> >>>>> will check that it can't write the data to that fd? Since doing so would
> >>>>> expose the video. Presumably at some point the tee code will prevent that?
> >>>>> (I sincerely hope so!)
> >>>>
> >>>> It is entirely the job of the TEE to prevent this. Nothing in the
> >>>> kernel should allow exploitation of what happens in the TEE no matter
> >>>> what goes on in the kernel
> >>>>
> >>>>>
> >>>>> Having a separate V4L2_MEMORY_DMABUF_SECURE type is to indicate to the
> >>>>> driver that 1) it can expect secure dmabuf fds, 2) it can configure itself
> >>>>> for that (that avoids using a control to toggle between normal and secure mode),
> >>>>> and at VIDIOC_QBUF time it is easy for the V4L2 core to verify that the
> >>>>> fd that is passed in is for secure memory. This means that mistakes by
> >>>>> userspace are caught at QBUF time.
> >>>>>
> >>>>> Of course, this will not protect you (people can disable this check by
> >>>>> recompiling the kernel), that still has to be done by the firmware, but
> >>>>> it catches userspace errors early on.
> >>>>>
> >>>>> Also, while for this hardware the DMA operation is the same, that might
> >>>>> not be the case for other hardware.
> >>>>
> >>>> That's a really good point. So one of the other models that is used
> >>>> for secure video decoding is to send the encrypted buffer into the
> >>>> video decoder directly (i.e. V4L2_MEMORY_MMAP) and then also send in
> >>>> all the corresponding crypto parameters (i.e. algorithm, IV,
> >>>> encryption pattern, etc.). Then the video driver internally does the
> >>>> decryption and decode in one operation.  That's not what we want to
> >>>> use here for Mediatek; but I've done other integrations that work that
> >>>> way (that was for VAAPI [1], not V4L2...but there are other ARM
> >>>> implementations that do operate that way).  So if we end up requiring
> >>>> V4L2_MEMORY_DMABUF_SECURE to indicate secure mode and enforce it on
> >>>> output+capture, that'll close off other potential solutions in the
> >>>> future.
> >>>>
> >>>> Expanding on your point about DMA operations being different on
> >>>> various hardware, that also makes me think a general check for this in
> >>>> v4l2 code may also be limiting. There are various ways secure video
> >>>> pipelines are done, so leaving these checks up to the individual
> >>>> drivers that implement secure video decode may be more pragmatic. If
> >>>> there's a generic V4L2 _CID_SECURE_MODE control, that makes it more
> >>>> general for how drivers can handle secure video decode.
> >>>
> >>> No, using a control for this is really wrong.
> >>>
> >>> The reason why I want it as a separate memory type is that that is
> >>> what you use when you call VIDIOC_REQBUFS, and that ioctl is also
> >>> when things are locked down in a driver. As long as no buffers have
> >>> been allocated, you can still change formats, parameters, etc. But
> >>> once buffers are allocated, most of that can't be changed, since
> >>> changing e.g. the format would also change the buffer sizes.
> >>>
> >>> It also locks down who owns the buffers by storing the file descriptor.
> >>> This prevents other processes from hijacking the I/O streaming, only
> >>> the owner can stream buffers.
> >>>
> >>> So it is a natural point in the sequence for selecting secure
> >>> buffers.
> >>>
> >>> If you request V4L2_MEMORY_DMABUF_SECURE for the output, then the
> >>> capture side must also use DMABUF_SECURE. Whether or not you can
> >>> use regular DMABUF for the output side and select DMABUF_SECURE
> >>> on the capture side is a driver decision. It can be useful to
> >>> support this for testing the secure capture using regular video
> >>> streams (something Nicolas discussed as well), but it depends on
> >>> the hardware whether you can use that technique.
> >>
> >> OK, that does work for the additional cases I mentioned.  And for
> >> testing...we would still want to use DMABUF_SECURE on both ends for
> >> Mediatek at least (that's the only way they support it). But rather
> >> than having to bother with a clearkey implementation...we can just do
> >> something that directly copies compressed video into the secure
> >> dmabufs and then exercises the whole pipeline from there. This same
> >> thing happens with the 'clear lead' that is sometimes there with
> >> encrypted video (where the first X seconds are unencrypted and then it
> >> switches to encrypted...but you're still using the secure video
> >> pipeline on the unencrypted frames in that case).
> >>
> >>
> >>>
> >>> Regards,
> >>>
> >>>         Hans
> >>>
> >>>>
> >>>> [1] - https://github.com/intel/libva/blob/master/va/va.h#L2177
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>         Hans
> >>>>>
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Yunfei Dong
> >>>>>>
> >>>>>
> >>>
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Tue, Sep 19, 2023 at 1:53 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 18/09/2023 22:57, Jeffrey Kardatzke wrote:
> > On Fri, Sep 15, 2023 at 1:56 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >>
> >> On 15/09/2023 10:25, Yunfei Dong (董云飞) wrote:
> >>> Hi Hans & Nicolas,
> >>>
> >>> Thanks for your advice.
> >>>
> >>> On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
> >>>>
> >>>> External email : Please do not click links or open attachments until
> >>>> you have verified the sender or the content.
> >>>>  Hi,
> >>>>
> >>>> On 9/11/23 17:54, Nicolas Dufresne wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >>>>>> Setting secure mode flag to kernel when trying to play secure
> >>>>
> >>>> video,
> >>>>>> then decoder driver will initialize tee related interface to
> >>>>
> >>>> support
> >>>>>> svp.
> >>>>>
> >>>>>
> >>>>> This is not what the patch is doing, please rework. This patch is
> >>>>
> >>>> an vendor API
> >>>>> addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> >>>>
> >>>> not have to
> >>>>> read your patch to understand this.
> >>>>>
> >>>>>>
> >>>>>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >>>>>> ---
> >>>>>>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> >>>>
> >>>> ++++++++++++++-
> >>>>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>>>>>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git
> >>>>
> >>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>> less.c
> >>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>> less.c
> >>>>>> index d2b09ce9f1cf..a981178c25d9 100644
> >>>>>> ---
> >>>>
> >>>> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>> less.c
> >>>>>> +++
> >>>>
> >>>> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> >>>> less.c
> >>>>>> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> >>>>
> >>>> *ctrl)
> >>>>>>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> >>>>
> >>>> sec_fd, ctrl->val);
> >>>>>>  break;
> >>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>
> >>>>> Stepping back a little and focusing on the API, what makes your
> >>>>
> >>>> driver so
> >>>>> special that it should be the only one having a "secure mode" ? We
> >>>>
> >>>> are touching
> >>>>> in gap in the media pipeline in Linux, and this should come with
> >>>>
> >>>> consideration
> >>>>> of the global API.
> >>>>>
> >>>>> Why is this API better then let's say Google Android one, were they
> >>>>
> >>>> expose 2
> >>>>> device nodes in their fork of the MFC driver (a secure and a non
> >>>>
> >>>> secure one) ?
> >>>>
> >>>> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> >>>> on how to
> >>>> handle secure video. I suspect this isn't mediatek specific, other
> >>>> SoCs with
> >>>> tee support could use this as well.
> >>>>
> >>>> As Nicolas said, it's long known to be a gap in our media support, so
> >>>> it is
> >>>> really great that you started work on this, but you need to look at
> >>>> this from
> >>>> a more generic point-of-view, and not mediatek-specific.
> >>>>
> >>>
> >>> Whether your have any advice about how to do a more generic driver to
> >>> handle secure video playback?
> >>>
> >>> There are several kind of buffer: output queue buffer/capture queue
> >>> buffer/working buffer.
> >>>
> >>> output and capture queue buffer: user space will call tee related
> >>> interface to allocate secure handle. Will convert to secure handle with
> >>> v4l2 framework, then send secure handle to optee-os.
> >>>
> >>> working buffer: calling dma_heap and dma_buf to get secure memory
> >>> handle, then covert secure iova in optee-os.
> >>>
> >>> Using the same kernel driver for svp and non-svp playback, just the
> >>> buffer type are different. Normal is iova and secure is secure handle.
> >>>
> >>> User driver will tell the kernel driver with CID control whether the
> >>> current playback is svp or non-svp.
> >>
> >> My understanding is that when you switch to secure mode, the driver makes
> >> some optee calls to set everything up. And userspace needs a way convert a
> >> dmabuf fd to a 'secure handle', which appears to be the DMA address of the
> >> buffer. Who uses that handle?
> >
> > The only user space usage for getting the 'secure handle' from an fd
> > is when that memory is written to. This is done when the TEE decrypts
> > the video contents. User space sends the encrypted video + 'secure
> > handle' to the TEE, and the TEE decrypts the contents to the memory
> > associated with the 'secure handle'. Then the 'secure handle' is
> > passed into the TEE again with the v4l2 driver to use as the source
> > for video decoding (but w/ v4l2, user space is passing in fds).
>
> I think I need some more background. This series is to support a 'Secure Video
> Processor' (at least, that's what svp stands for I believe, something that
> is not mentioned anywhere in this series, BTW) which is used to decode an
> encrypted h264 stream.
SVP = Secure Video Path, which is explained in what you linked to below.
>
> First question: how is that stream encrypted? Is that according to some standard?
> Nothing is mentioned about that.
The TEE does the decryption of the incoming stream to the secure
buffer...and that is then fed into the output queue of v4l2. So
there's no handling of encrypted content in the kernel patches...it's
just about handling secure buffers and secure surfaces.
>
> I gather that the encrypted stream is fed to the codec as usual (i.e. just put it
> in the output buffer and queue it to the codec), nothing special is needed for that.
> Except, how does the hardware know it is encrypted? I guess that's where the
> control comes in, you have to turn on SVP mode first.
Yeah, the driver does need to know if the FDs are from secure or
non-secure memory...which is what the SVP control was about.
>
> For the capture buffers you need to provide buffers from secure/trusted memory.
> That's a dmabuf fd, but where does that come from?
That fd is allocated from the secure dma-buf heap which is being
proposed in another patchset.
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@mediatek.com/
>
> I saw this message:
>
> https://lore.kernel.org/linux-media/CAPj87rOHctwHJM-7HiQpt8Q0b09x0WWw_T4XsL0qT=dS+XzyZQ@mail.gmail.com/T/#u
>
> so I expect that's where it comes from. But I agree that getting this from dma-heaps
> seems more natural.
>
> I assume that those capture buffers are inaccessible from the CPU? (Hence 'secure')
Correct
>
> For actually displaying these secure buffers you would use drm, and I assume that
> the hardware would mix in the contents of the secure buffer into the video output
> pipeline? I.e., the actual contents remain inaccessible. And that the video output
> (HDMI or DisplayPort) is using HDCP?
Correct
>
> >
> >>
> >> In any case, using a control to switch to secure mode and using a control
> >> to convert a dmabuf fd to a secure handle seems a poor choice to me.
> >>
> >> I was wondering if it wouldn't be better to create a new V4L2_MEMORY_ type,
> >> e.g. V4L2_MEMORY_DMABUF_SECURE (or perhaps _DMABUF_OPTEE). That ensures that
> >> once you create buffers for the first time, the driver can switch into secure
> >> mode, and until all buffers are released again you know that the driver will
> >> stay in secure mode.
> >
> > Why do you think the control for setting secure mode is a poor choice?
> > There's various places in the driver code where functionality changes
> > based on being secure/non-secure mode, so this is very much a 'global'
> > setting for the driver. It could be inferred based off a new memory
> > type for the queues...which then sets that flag in the driver; but
> > that seems like it would be more fragile and would require checking
> > for incompatible output/capture memory types. I'm not against another
> > way of doing this; but didn't see why you think the proposed method is
> > a poor choice.
>
> I assume you are either decoding to secure memory all the time, or not
> at all. That's something you would want to select the moment you allocate
> the first buffer. Using the V4L2_MEMORY_ value would be the natural place
> for that. A control can typically be toggled at any time, and it makes
> no sense to do that for secure streaming.
Ahh ok, good point about the control being able to be toggled at any
time. So adding a new V4L2_MEMORY_ type would make sense relating to
that.
>
> Related to that: if you pass a dmabuf fd you will need to check somewhere
> if the fd points to secure memory or not. You don't want to mix the two
> but you want to check that at VIDIOC_QBUF time.
>
> Note that the V4L2_MEMORY_ value is already checked in the v4l2 core,
> drivers do not need to do that.
>
> >
> >>
> >> For converting the dmabuf fd into a secure handle: a new ioctl similar to
> >> VIDIOC_EXPBUF might be more suited for that.
> >
> > I actually think the best way for converting the dmabuf fd into a
> > secure handle would be another ioctl in the dma-heap driver...since
> > that's where the memory is actually allocated from. But this really
> > depends on upstream maintainers and what they are comfortable with.
>
> That feels like a more natural place of doing this.
>
> Regards,
>
>         Hans
>
> >
> >>
> >> Note that I am the first to admit that I have no experience with secure
> >> video pipelines or optee-os, so I am looking at this purely from an uAPI
> >> perspective.
> >>
> >> Regards,
> >>
> >>         Hans
> >>
> >>>
> >>> Best Regards,
> >>> Yunfei Dong
> >>>> Regards,
> >>>>
> >>>> Hans
> >>>>
> >>>>>
> >>>>> regards,
> >>>>> Nicolas
> >>>>>
> >>>>> p.s. you forgot to document your control in the RST doc, please do
> >>>>
> >>>> in following
> >>>>> release.
> >>>>>
> >>>>>> +ctx->is_svp_mode = ctrl->val;
> >>>>>> +
> >>>>>> +if (ctx->is_svp_mode) {
> >>>>>> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >>>>>> +if (ret)
> >>>>>> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >>>>>> +else
> >>>>>> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >>>>>
> >>>>> val);
> >>>>>> +}
> >>>>>> +break;
> >>>>>>  default:
> >>>>>>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id:
> >>>>>> 0x%x\n",
> >>>>
> >>>> hdr_ctrl->id);
> >>>>>>  return ret;
> >>>>>> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>
> >>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>  unsigned int i;
> >>>>>>  struct v4l2_ctrl *ctrl;
> >>>>>>
> >>>>>> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >>>>>> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>>>>>  if (ctx->ctrl_hdl.error) {
> >>>>>>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>>>>>  return ctx->ctrl_hdl.error;
> >>>>>> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> >>>>
> >>>> mtk_vcodec_dec_ctx *ctx)
> >>>>>>
> >>>>>>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>
> >>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >>>>>> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> >>>>
> >>>> &mtk_vcodec_dec_ctrl_ops,
> >>>>>> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>>>>>
> >>>>>>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>>>>>
> >>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>
> >>>> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>> index d8cf01f76aab..a507045a3f30 100644
> >>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >>>>>> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>>>>>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return
> >>>>>> "Reference
> >>>>
> >>>> Frames for a P-Frame";
> >>>>>>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> >>>>
> >>>> SPS and PPS to IDR";
> >>>>>>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek
> >>>>>> Decoder
> >>>>
> >>>> get secure handle";
> >>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> >>>>
> >>>> set secure mode";
> >>>>>>
> >>>>>>  /* AV1 controls */
> >>>>>>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >>>>>> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> >>>>
> >>>> **name, enum v4l2_ctrl_type *type,
> >>>>>>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>>  break;
> >>>>>> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >>>>>> +*type = V4L2_CTRL_TYPE_INTEGER;
> >>>>>> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>>>>> +break;
> >>>>>>  case V4L2_CID_USER_CLASS:
> >>>>>>  case V4L2_CID_CAMERA_CLASS:
> >>>>>>  case V4L2_CID_CODEC_CLASS:
> >>>>>> diff --git a/include/uapi/linux/v4l2-controls.h
> >>>>
> >>>> b/include/uapi/linux/v4l2-controls.h
> >>>>>> index 7b3694985366..88e90d943e38 100644
> >>>>>> --- a/include/uapi/linux/v4l2-controls.h
> >>>>>> +++ b/include/uapi/linux/v4l2-controls.h
> >>>>>> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >>>>>>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> >>>>
> >>>> driver as defined by V4L2 */
> >>>>>>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>>>>>  #define
> >>>>
> >>>> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >>>>>> +#define
> >>>>
> >>>> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>>>>>
> >>>>>>  /*  Camera class control IDs */
> >>>>>>
> >>
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Yunfei Dong (董云飞)]

Hi Hans & Nicolas,

Thanks for your advice.

On Tue, 2023-09-12 at 11:30 +0200, Hans Verkuil wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Hi,
> 
> On 9/11/23 17:54, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> >> Setting secure mode flag to kernel when trying to play secure
> video,
> >> then decoder driver will initialize tee related interface to
> support
> >> svp.
> > 
> > 
> > This is not what the patch is doing, please rework. This patch is
> an vendor API
> > addition introducing V4L2_CID_MPEG_MTK_SET_SECURE_MODE. I should
> not have to
> > read your patch to understand this.
> > 
> >>
> >> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> >> ---
> >>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c     | 15
> ++++++++++++++-
> >>  drivers/media/v4l2-core/v4l2-ctrls-defs.c         |  5 +++++
> >>  include/uapi/linux/v4l2-controls.h                |  1 +
> >>  3 files changed, 20 insertions(+), 1 deletion(-)
> >>
> >> diff --git
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> >> index d2b09ce9f1cf..a981178c25d9 100644
> >> ---
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> >> +++
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_state
> less.c
> >> @@ -535,6 +535,17 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl
> *ctrl)
> >>  ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> >>  mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x",
> sec_fd, ctrl->val);
> >>  break;
> >> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> > 
> > Stepping back a little and focusing on the API, what makes your
> driver so
> > special that it should be the only one having a "secure mode" ? We
> are touching
> > in gap in the media pipeline in Linux, and this should come with
> consideration
> > of the global API.
> > 
> > Why is this API better then let's say Google Android one, were they
> expose 2
> > device nodes in their fork of the MFC driver (a secure and a non
> secure one) ?
> 
> Perhaps it is a good idea to first post an RFC with an uAPI proposal
> on how to
> handle secure video. I suspect this isn't mediatek specific, other
> SoCs with
> tee support could use this as well.
> 
> As Nicolas said, it's long known to be a gap in our media support, so
> it is
> really great that you started work on this, but you need to look at
> this from
> a more generic point-of-view, and not mediatek-specific.
> 
Whether your have any advice about how to do a more generic driver to
handle secure video playback?

There are several kind of buffer: output queue buffer/capture queue
buffer/working buffer.

output and capture queue buffer: user space will call tee related
interface to allocate secure handle. Will convert to secure handle with
v4l2 framework, then send secure handle to optee-os.

working buffer: calling dma_heap and dma_buf to get secure memory
handle, then covert secure iova in optee-os.

Using the same kernel driver for svp and non-svp playback, just the
buffer type are different. Normal is iova and secure is secure handle.

User driver will tell the kernel driver with CID control whether the
current playback is svp or non-svp.

Best Regards,
Yunfei Dong
> Regards,
> 
> Hans
> 
> > 
> > regards,
> > Nicolas
> > 
> > p.s. you forgot to document your control in the RST doc, please do
> in following
> > release.
> > 
> >> +ctx->is_svp_mode = ctrl->val;
> >> +
> >> +if (ctx->is_svp_mode) {
> >> +ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
> >> +if (ret)
> >> +mtk_v4l2_vdec_err(ctx, "open secure mode failed.");
> >> +else
> >> +mtk_v4l2_vdec_dbg(3, ctx, "decoder in secure mode: %d", ctrl-
> >val);
> >> +}
> >> +break;
> >>  default:
> >>  mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n",
> hdr_ctrl->id);
> >>  return ret;
> >> @@ -573,7 +584,7 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> mtk_vcodec_dec_ctx *ctx)
> >>  unsigned int i;
> >>  struct v4l2_ctrl *ctrl;
> >>  
> >> -v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> >> +v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 2);
> >>  if (ctx->ctrl_hdl.error) {
> >>  mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> >>  return ctx->ctrl_hdl.error;
> >> @@ -592,6 +603,8 @@ static int mtk_vcodec_dec_ctrls_setup(struct
> mtk_vcodec_dec_ctx *ctx)
> >>  
> >>  ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> &mtk_vcodec_dec_ctrl_ops,
> >>   V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> >> +ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl,
> &mtk_vcodec_dec_ctrl_ops,
> >> + V4L2_CID_MPEG_MTK_SET_SECURE_MODE, 0, 65535, 1, 0);
> >>  
> >>  v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> >>  
> >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >> index d8cf01f76aab..a507045a3f30 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> >> @@ -1042,6 +1042,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> >>  case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES:return "Reference
> Frames for a P-Frame";
> >>  case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR:return "Prepend
> SPS and PPS to IDR";
> >>  case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:return "MediaTek Decoder
> get secure handle";
> >> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:return "MediaTek Decoder
> set secure mode";
> >>  
> >>  /* AV1 controls */
> >>  case V4L2_CID_MPEG_VIDEO_AV1_PROFILE:return "AV1 Profile";
> >> @@ -1442,6 +1443,10 @@ void v4l2_ctrl_fill(u32 id, const char
> **name, enum v4l2_ctrl_type *type,
> >>  *type = V4L2_CTRL_TYPE_INTEGER;
> >>  *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >>  break;
> >> +case V4L2_CID_MPEG_MTK_SET_SECURE_MODE:
> >> +*type = V4L2_CTRL_TYPE_INTEGER;
> >> +*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> >> +break;
> >>  case V4L2_CID_USER_CLASS:
> >>  case V4L2_CID_CAMERA_CLASS:
> >>  case V4L2_CID_CODEC_CLASS:
> >> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> >> index 7b3694985366..88e90d943e38 100644
> >> --- a/include/uapi/linux/v4l2-controls.h
> >> +++ b/include/uapi/linux/v4l2-controls.h
> >> @@ -957,6 +957,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> >>  /*  MPEG-class control IDs specific to the MediaTek Decoder
> driver as defined by V4L2 */
> >>  #define V4L2_CID_MPEG_MTK_BASE(V4L2_CTRL_CLASS_CODEC | 0x2000)
> >>  #define
> V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE(V4L2_CID_MPEG_MTK_BASE+8)
> >> +#define
> V4L2_CID_MPEG_MTK_SET_SECURE_MODE(V4L2_CID_MPEG_MTK_BASE+9)
> >>  
> >>  /*  Camera class control IDs */
> >>  
> > 
> 

[PATCH 13/14] media: medkatek: vcodec: disable wait interrupt for svp mode

[Yunfei Dong]

Waiting interrupt in optee-os for svp mode, need to disable it in kernel
in case of interrupt is cleaned.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_hw.c        | 34 +++++------
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 57 +++++++++++--------
 2 files changed, 50 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
index 881d5de41e05..46fa28de3893 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
@@ -72,26 +72,28 @@ static irqreturn_t mtk_vdec_hw_irq_handler(int irq, void *priv)
 
 	ctx = mtk_vcodec_get_curr_ctx(dev->main_dev, dev->hw_idx);
 
-	/* check if HW active or not */
-	cg_status = readl(dev->reg_base[VDEC_HW_SYS] + VDEC_HW_ACTIVE_ADDR);
-	if (cg_status & VDEC_HW_ACTIVE_MASK) {
-		mtk_v4l2_vdec_err(ctx, "vdec active is not 0x0 (0x%08x)", cg_status);
-		return IRQ_HANDLED;
-	}
+	if (!ctx->is_svp_mode) {
+		/* check if HW active or not */
+		cg_status = readl(dev->reg_base[VDEC_HW_SYS] + VDEC_HW_ACTIVE_ADDR);
+		if (cg_status & VDEC_HW_ACTIVE_MASK) {
+			mtk_v4l2_vdec_err(ctx, "vdec active is not 0x0 (0x%08x)", cg_status);
+			return IRQ_HANDLED;
+		}
 
-	dec_done_status = readl(vdec_misc_addr);
-	if ((dec_done_status & MTK_VDEC_IRQ_STATUS_DEC_SUCCESS) !=
-	    MTK_VDEC_IRQ_STATUS_DEC_SUCCESS)
-		return IRQ_HANDLED;
+		dec_done_status = readl(vdec_misc_addr);
+		if ((dec_done_status & MTK_VDEC_IRQ_STATUS_DEC_SUCCESS) !=
+		    MTK_VDEC_IRQ_STATUS_DEC_SUCCESS)
+			return IRQ_HANDLED;
 
-	/* clear interrupt */
-	writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
-	writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
+		/* clear interrupt */
+		writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
+		writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
 
-	wake_up_dec_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->hw_idx);
+		wake_up_dec_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->hw_idx);
 
-	mtk_v4l2_vdec_dbg(3, ctx, "wake up ctx %d, dec_done_status=%x",
-			  ctx->id, dec_done_status);
+		mtk_v4l2_vdec_dbg(3, ctx, "wake up ctx %d, dec_done_status=%x",
+				  ctx->id, dec_done_status);
+	}
 
 	return IRQ_HANDLED;
 }
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index a0bfb4890e8e..7317f8467a8d 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -593,14 +593,16 @@ static int vdec_h264_slice_core_decode(struct vdec_lat_buf *lat_buf)
 		goto vdec_dec_end;
 	}
 
-	/* wait decoder done interrupt */
-	timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
-	if (timeout)
-		mtk_vdec_err(ctx, "core decode timeout: pic_%d", ctx->decoded_frame_cnt);
-	inst->vsi_core->dec.timeout = !!timeout;
-
-	vpu_dec_core_end(vpu);
+	if (!ctx->is_svp_mode) {
+		/* wait decoder done interrupt */
+		timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
+		if (timeout)
+			mtk_vdec_err(ctx, "core decode timeout: pic_%d", ctx->decoded_frame_cnt);
+		inst->vsi_core->dec.timeout = !!timeout;
+
+		vpu_dec_core_end(vpu);
+	}
 	mtk_vdec_debug(ctx, "pic[%d] crc: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x",
 		       ctx->decoded_frame_cnt,
 		       inst->vsi_core->dec.crc[0], inst->vsi_core->dec.crc[1],
@@ -724,14 +726,16 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		vdec_msg_queue_qbuf(&inst->ctx->msg_queue.core_ctx, lat_buf);
 	}
 
-	/* wait decoder done interrupt */
-	timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_LAT0);
-	if (timeout)
-		mtk_vdec_err(inst->ctx, "lat decode timeout: pic_%d", inst->slice_dec_num);
-	inst->vsi->dec.timeout = !!timeout;
+	if (!inst->ctx->is_svp_mode) {
+		/* wait decoder done interrupt */
+		timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_LAT0);
+		if (timeout)
+			mtk_vdec_err(inst->ctx, "lat decode timeout: pic_%d", inst->slice_dec_num);
+		inst->vsi->dec.timeout = !!timeout;
 
-	err = vpu_dec_end(vpu);
+		err = vpu_dec_end(vpu);
+	}
 	if (err == SLICE_HEADER_FULL || err == TRANS_BUFFER_FULL) {
 		if (!IS_VDEC_INNER_RACING(inst->ctx->dev->dec_capability))
 			vdec_msg_queue_qbuf(&inst->ctx->msg_queue.lat_ctx, lat_buf);
@@ -831,16 +835,19 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 	if (err)
 		goto err_free_fb_out;
 
-	/* wait decoder done interrupt */
-	err = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					   WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
-	if (err)
-		mtk_vdec_err(inst->ctx, "decode timeout: pic_%d", inst->ctx->decoded_frame_cnt);
-
-	inst->vsi->dec.timeout = !!err;
-	err = vpu_dec_end(vpu);
-	if (err)
-		goto err_free_fb_out;
+	if (!inst->ctx->is_svp_mode) {
+		/* wait decoder done interrupt */
+		err = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						   WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
+		if (err)
+			mtk_vdec_err(inst->ctx, "decode timeout: pic_%d",
+				     inst->ctx->decoded_frame_cnt);
+
+		inst->vsi->dec.timeout = !!err;
+		err = vpu_dec_end(vpu);
+		if (err)
+			goto err_free_fb_out;
+	}
 
 	memcpy(&inst->vsi_ctx, inst->vpu.vsi, sizeof(inst->vsi_ctx));
 	mtk_vdec_debug(inst->ctx, "pic[%d] crc: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x",
-- 
2.18.0

[PATCH 14/14] media: medkatek: vcodec: support tee decoder

[Yunfei Dong]

Initialize tee private data to support secure decoder.
Release tee related information for each instance when decoder
done.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
index 64e006820f43..acb6d1f0392f 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
@@ -310,6 +310,9 @@ static int fops_vcodec_release(struct file *file)
 	v4l2_fh_exit(&ctx->fh);
 	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
 
+	if (ctx->is_svp_mode)
+		mtk_vcodec_dec_optee_release(dev->optee_private);
+
 	mtk_vcodec_dbgfs_remove(dev, ctx->id);
 	list_del_init(&ctx->list);
 	kfree(ctx);
@@ -440,6 +443,11 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
 	atomic_set(&dev->dec_active_cnt, 0);
 	memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info));
 	mutex_init(&dev->dec_racing_info_mutex);
+	ret = mtk_vcodec_dec_optee_private_init(dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to init svp private.");
+		goto err_reg_cont;
+	}
 
 	ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1);
 	if (ret) {
-- 
2.18.0