[PATCH 0/5] media: mtk-vcodec: venc: variouse bug fixes

[PATCH 0/5] media: mtk-vcodec: venc: variouse bug fixes

[Dafna Hirschfeld]

Some bug fixes mainly in case of error handling

Dafna Hirschfeld (5):
  media: mtk-vcodec: enter ABORT state if encoding failed
  media: mtk-vcodec: call v4l2_m2m_ctx_release first when file is
    released
  media: mtk-vcodec: change the venc handler funcs to return int
  media: mtk-vcodec: Add two error cases upon vpu irq handling
  media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

 .../platform/mtk-vcodec/mtk_vcodec_enc.c      |  1 +
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  2 +-
 .../media/platform/mtk-vcodec/venc_vpu_if.c   | 27 +++++++++++++------
 3 files changed, 21 insertions(+), 9 deletions(-)

-- 
2.17.1

[PATCH 0/5] media: mtk-vcodec: venc: variouse bug fixes

[Dafna Hirschfeld]

Some bug fixes mainly in case of error handling

Dafna Hirschfeld (5):
  media: mtk-vcodec: enter ABORT state if encoding failed
  media: mtk-vcodec: call v4l2_m2m_ctx_release first when file is
    released
  media: mtk-vcodec: change the venc handler funcs to return int
  media: mtk-vcodec: Add two error cases upon vpu irq handling
  media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

 .../platform/mtk-vcodec/mtk_vcodec_enc.c      |  1 +
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  2 +-
 .../media/platform/mtk-vcodec/venc_vpu_if.c   | 27 +++++++++++++------
 3 files changed, 21 insertions(+), 9 deletions(-)

-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 1/5] media: mtk-vcodec: enter ABORT state if encoding failed

[Dafna Hirschfeld]

In case the encoding failed, we should set
ctx->state = MTK_STATE_ABORT, since this indicates
a fatal error and there is no point to continue
trying to encode in that case.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 416f356af363..1678c31bc9aa 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1109,6 +1109,7 @@ static void mtk_venc_worker(struct work_struct *work)
 		dst_buf->vb2_buf.planes[0].bytesused = 0;
 		v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
 		mtk_v4l2_err("venc_if_encode failed=%d", ret);
+		ctx->state = MTK_STATE_ABORT;
 	} else {
 		v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
 		dst_buf->vb2_buf.planes[0].bytesused = enc_result.bs_size;
-- 
2.17.1

[PATCH 1/5] media: mtk-vcodec: enter ABORT state if encoding failed

[Dafna Hirschfeld]

In case the encoding failed, we should set
ctx->state = MTK_STATE_ABORT, since this indicates
a fatal error and there is no point to continue
trying to encode in that case.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 416f356af363..1678c31bc9aa 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1109,6 +1109,7 @@ static void mtk_venc_worker(struct work_struct *work)
 		dst_buf->vb2_buf.planes[0].bytesused = 0;
 		v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
 		mtk_v4l2_err("venc_if_encode failed=%d", ret);
+		ctx->state = MTK_STATE_ABORT;
 	} else {
 		v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
 		dst_buf->vb2_buf.planes[0].bytesused = enc_result.bs_size;
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 2/5] media: mtk-vcodec: call v4l2_m2m_ctx_release first when file is released

[Dafna Hirschfeld]

The func v4l2_m2m_ctx_release waits for currently running jobs
to finish and then stop streaming both queues and frees the buffers.
All this should be done before the call to mtk_vcodec_enc_release
which frees the encoder handler. This fixes use-after-free bug.

Fixes: 4e855a6efa547 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 45d1870c83dd..4ced20ca647b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -218,11 +218,11 @@ static int fops_vcodec_release(struct file *file)
 	mtk_v4l2_debug(1, "[%d] encoder", ctx->id);
 	mutex_lock(&dev->dev_mutex);
 
+	v4l2_m2m_ctx_release(ctx->m2m_ctx);
 	mtk_vcodec_enc_release(ctx);
 	v4l2_fh_del(&ctx->fh);
 	v4l2_fh_exit(&ctx->fh);
 	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
-	v4l2_m2m_ctx_release(ctx->m2m_ctx);
 
 	list_del_init(&ctx->list);
 	kfree(ctx);
-- 
2.17.1

[PATCH 2/5] media: mtk-vcodec: call v4l2_m2m_ctx_release first when file is released

[Dafna Hirschfeld]

The func v4l2_m2m_ctx_release waits for currently running jobs
to finish and then stop streaming both queues and frees the buffers.
All this should be done before the call to mtk_vcodec_enc_release
which frees the encoder handler. This fixes use-after-free bug.

Fixes: 4e855a6efa547 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 45d1870c83dd..4ced20ca647b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -218,11 +218,11 @@ static int fops_vcodec_release(struct file *file)
 	mtk_v4l2_debug(1, "[%d] encoder", ctx->id);
 	mutex_lock(&dev->dev_mutex);
 
+	v4l2_m2m_ctx_release(ctx->m2m_ctx);
 	mtk_vcodec_enc_release(ctx);
 	v4l2_fh_del(&ctx->fh);
 	v4l2_fh_exit(&ctx->fh);
 	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
-	v4l2_m2m_ctx_release(ctx->m2m_ctx);
 
 	list_del_init(&ctx->list);
 	kfree(ctx);
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 3/5] media: mtk-vcodec: change the venc handler funcs to return int

[Dafna Hirschfeld]

Currently the functions handle_enc_init_msg, handle_enc_encode_msg
return void and set vpu->failure to 1 in case of failure.
Instead, change the functions to return non 0 in case of failure
and then the vpu->failure is updated to their return value.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index be6d8790a41e..32dc844d16f9 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -9,7 +9,7 @@
 #include "venc_ipi_msg.h"
 #include "venc_vpu_if.h"
 
-static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
+static int handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 {
 	const struct venc_vpu_ipi_msg_init *msg = data;
 
@@ -19,7 +19,7 @@ static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 
 	/* Firmware version field value is unspecified on MT8173. */
 	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
-		return;
+		return 0;
 
 	/* Check firmware version. */
 	mtk_vcodec_debug(vpu, "firmware version: 0x%x\n",
@@ -30,18 +30,19 @@ static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 	default:
 		mtk_vcodec_err(vpu, "unhandled firmware version 0x%x\n",
 			       msg->venc_abi_version);
-		vpu->failure = 1;
-		break;
+		return -EINVAL;
 	}
+	return 0;
 }
 
-static void handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
+static int handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
 {
 	const struct venc_vpu_ipi_msg_enc *msg = data;
 
 	vpu->state = msg->state;
 	vpu->bs_size = msg->bs_size;
 	vpu->is_key_frm = msg->is_key_frm;
+	return 0;
 }
 
 static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
@@ -60,12 +61,12 @@ static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
 
 	switch (msg->msg_id) {
 	case VPU_IPIMSG_ENC_INIT_DONE:
-		handle_enc_init_msg(vpu, data);
+		vpu->failure = handle_enc_init_msg(vpu, data);
 		break;
 	case VPU_IPIMSG_ENC_SET_PARAM_DONE:
 		break;
 	case VPU_IPIMSG_ENC_ENCODE_DONE:
-		handle_enc_encode_msg(vpu, data);
+		vpu->failure = handle_enc_encode_msg(vpu, data);
 		break;
 	case VPU_IPIMSG_ENC_DEINIT_DONE:
 		break;
-- 
2.17.1

[PATCH 3/5] media: mtk-vcodec: change the venc handler funcs to return int

[Dafna Hirschfeld]

Currently the functions handle_enc_init_msg, handle_enc_encode_msg
return void and set vpu->failure to 1 in case of failure.
Instead, change the functions to return non 0 in case of failure
and then the vpu->failure is updated to their return value.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index be6d8790a41e..32dc844d16f9 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -9,7 +9,7 @@
 #include "venc_ipi_msg.h"
 #include "venc_vpu_if.h"
 
-static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
+static int handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 {
 	const struct venc_vpu_ipi_msg_init *msg = data;
 
@@ -19,7 +19,7 @@ static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 
 	/* Firmware version field value is unspecified on MT8173. */
 	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
-		return;
+		return 0;
 
 	/* Check firmware version. */
 	mtk_vcodec_debug(vpu, "firmware version: 0x%x\n",
@@ -30,18 +30,19 @@ static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 	default:
 		mtk_vcodec_err(vpu, "unhandled firmware version 0x%x\n",
 			       msg->venc_abi_version);
-		vpu->failure = 1;
-		break;
+		return -EINVAL;
 	}
+	return 0;
 }
 
-static void handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
+static int handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
 {
 	const struct venc_vpu_ipi_msg_enc *msg = data;
 
 	vpu->state = msg->state;
 	vpu->bs_size = msg->bs_size;
 	vpu->is_key_frm = msg->is_key_frm;
+	return 0;
 }
 
 static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
@@ -60,12 +61,12 @@ static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
 
 	switch (msg->msg_id) {
 	case VPU_IPIMSG_ENC_INIT_DONE:
-		handle_enc_init_msg(vpu, data);
+		vpu->failure = handle_enc_init_msg(vpu, data);
 		break;
 	case VPU_IPIMSG_ENC_SET_PARAM_DONE:
 		break;
 	case VPU_IPIMSG_ENC_ENCODE_DONE:
-		handle_enc_encode_msg(vpu, data);
+		vpu->failure = handle_enc_encode_msg(vpu, data);
 		break;
 	case VPU_IPIMSG_ENC_DEINIT_DONE:
 		break;
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

1. Fail if the function mtk_vcodec_fw_map_dm_addr
returns ERR pointer.
2. Fail if the state from the vpu msg is either
VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index 32dc844d16f9..234705ba7cd6 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
 					     msg->vpu_inst_addr);
 
+	if (IS_ERR(vpu->vsi))
+		return PTR_ERR(vpu->vsi);
 	/* Firmware version field value is unspecified on MT8173. */
 	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
 		return 0;
@@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
 	vpu->state = msg->state;
 	vpu->bs_size = msg->bs_size;
 	vpu->is_key_frm = msg->is_key_frm;
+	if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
+	    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
+		mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
+			       vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
+		return -EINVAL;
+	}
 	return 0;
 }
 
-- 
2.17.1

[PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

1. Fail if the function mtk_vcodec_fw_map_dm_addr
returns ERR pointer.
2. Fail if the state from the vpu msg is either
VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index 32dc844d16f9..234705ba7cd6 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
 	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
 					     msg->vpu_inst_addr);
 
+	if (IS_ERR(vpu->vsi))
+		return PTR_ERR(vpu->vsi);
 	/* Firmware version field value is unspecified on MT8173. */
 	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
 		return 0;
@@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
 	vpu->state = msg->state;
 	vpu->bs_size = msg->bs_size;
 	vpu->is_key_frm = msg->is_key_frm;
+	if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
+	    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
+		mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
+			       vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
+		return -EINVAL;
+	}
 	return 0;
 }
 
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 5/5] media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

[Dafna Hirschfeld]

Each message sent to the VPU should raise a signal. The signal
handler sets vpu->signaled. Test the field and fail
if it is 0.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index 234705ba7cd6..8331b1bd1971 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -92,6 +92,7 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
 {
 	int status;
 
+	vpu->signaled = 0;
 	mtk_vcodec_debug_enter(vpu);
 
 	if (!vpu->ctx->dev->fw_handler) {
@@ -106,6 +107,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
 			       *(uint32_t *)msg, len, status);
 		return -EINVAL;
 	}
+	if (!vpu->signaled)
+		return -EINVAL;
 	if (vpu->failure)
 		return -EINVAL;
 
@@ -122,7 +125,6 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
 	mtk_vcodec_debug_enter(vpu);
 
 	init_waitqueue_head(&vpu->wq_hd);
-	vpu->signaled = 0;
 	vpu->failure = 0;
 
 	status = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, vpu->id,
-- 
2.17.1

[PATCH 5/5] media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

[Dafna Hirschfeld]

Each message sent to the VPU should raise a signal. The signal
handler sets vpu->signaled. Test the field and fail
if it is 0.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index 234705ba7cd6..8331b1bd1971 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -92,6 +92,7 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
 {
 	int status;
 
+	vpu->signaled = 0;
 	mtk_vcodec_debug_enter(vpu);
 
 	if (!vpu->ctx->dev->fw_handler) {
@@ -106,6 +107,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
 			       *(uint32_t *)msg, len, status);
 		return -EINVAL;
 	}
+	if (!vpu->signaled)
+		return -EINVAL;
 	if (vpu->failure)
 		return -EINVAL;
 
@@ -122,7 +125,6 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
 	mtk_vcodec_debug_enter(vpu);
 
 	init_waitqueue_head(&vpu->wq_hd);
-	vpu->signaled = 0;
 	vpu->failure = 0;
 
 	status = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, vpu->id,
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 5/5] media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

[Irui Wang (王瑞)]

On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> Each message sent to the VPU should raise a signal. The signal
> handler sets vpu->signaled. Test the field and fail
> if it is 0.

I suppose you want to handle the message execution result, if ipi
message can't send or acked successfully, the returned "status" of
"mtk_vcodec_fw_ipi_send" will return, so I think you don't need to
check "signaled" again.

> 
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> ---
>  drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> index 234705ba7cd6..8331b1bd1971 100644
> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> @@ -92,6 +92,7 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
> *vpu, void *msg,
>  {
>  	int status;
>  
> +	vpu->signaled = 0;
>  	mtk_vcodec_debug_enter(vpu);
>  
>  	if (!vpu->ctx->dev->fw_handler) {
> @@ -106,6 +107,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
> *vpu, void *msg,
>  			       *(uint32_t *)msg, len, status);
>  		return -EINVAL;
>  	}
> +	if (!vpu->signaled)
> +		return -EINVAL;
>  	if (vpu->failure)
>  		return -EINVAL;
>  
> @@ -122,7 +125,6 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
>  	mtk_vcodec_debug_enter(vpu);
>  
>  	init_waitqueue_head(&vpu->wq_hd);
> -	vpu->signaled = 0;
>  	vpu->failure = 0;
>  
>  	status = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
> vpu->id,

Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang (王瑞)]

On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
> returns ERR pointer.
> 2. Fail if the state from the vpu msg is either
> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
> 
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> ---
>  drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> index 32dc844d16f9..234705ba7cd6 100644
> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst
> *vpu, const void *data)
>  	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>  					     msg->vpu_inst_addr);
>  
> +	if (IS_ERR(vpu->vsi))
> +		return PTR_ERR(vpu->vsi);
>  	/* Firmware version field value is unspecified on MT8173. */
>  	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>  		return 0;
> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
> venc_vpu_inst *vpu, const void *data)
>  	vpu->state = msg->state;
>  	vpu->bs_size = msg->bs_size;
>  	vpu->is_key_frm = msg->is_key_frm;
> +	if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> +	    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> +		mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
> +			       vpu->state ==
> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> +		return -EINVAL;
> +	}

Hi Dafna,

This state check is useless, the enc result will check in
"vpu_enc_ipi_handler".

Thanks

>  	return 0;
>  }
>  

Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>> returns ERR pointer.
>> 2. Fail if the state from the vpu msg is either
>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>
>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>> ---
>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> index 32dc844d16f9..234705ba7cd6 100644
>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst
>> *vpu, const void *data)
>>   	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>   					     msg->vpu_inst_addr);
>>   
>> +	if (IS_ERR(vpu->vsi))
>> +		return PTR_ERR(vpu->vsi);
>>   	/* Firmware version field value is unspecified on MT8173. */
>>   	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>   		return 0;
>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>> venc_vpu_inst *vpu, const void *data)
>>   	vpu->state = msg->state;
>>   	vpu->bs_size = msg->bs_size;
>>   	vpu->is_key_frm = msg->is_key_frm;
>> +	if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>> +	    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>> +		mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>> +			       vpu->state ==
>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>> +		return -EINVAL;
>> +	}
> 
> Hi Dafna,
> 
> This state check is useless, the enc result will check in
> "vpu_enc_ipi_handler".
> 

Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status
and I see that the states are not tested anywhere except of "skip" state in the h264 enc.

Can't there be a scenario where msg->status is ok but the state is error?
I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving
so I try to figure out why and report any possible error.

Thanks,
Dafna

> Thanks
> 
>>   	return 0;
>>   }
>>   

Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>> returns ERR pointer.
>> 2. Fail if the state from the vpu msg is either
>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>
>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>> ---
>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> index 32dc844d16f9..234705ba7cd6 100644
>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst
>> *vpu, const void *data)
>>   	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>   					     msg->vpu_inst_addr);
>>   
>> +	if (IS_ERR(vpu->vsi))
>> +		return PTR_ERR(vpu->vsi);
>>   	/* Firmware version field value is unspecified on MT8173. */
>>   	if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>   		return 0;
>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>> venc_vpu_inst *vpu, const void *data)
>>   	vpu->state = msg->state;
>>   	vpu->bs_size = msg->bs_size;
>>   	vpu->is_key_frm = msg->is_key_frm;
>> +	if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>> +	    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>> +		mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>> +			       vpu->state ==
>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>> +		return -EINVAL;
>> +	}
> 
> Hi Dafna,
> 
> This state check is useless, the enc result will check in
> "vpu_enc_ipi_handler".
> 

Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status
and I see that the states are not tested anywhere except of "skip" state in the h264 enc.

Can't there be a scenario where msg->status is ok but the state is error?
I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving
so I try to figure out why and report any possible error.

Thanks,
Dafna

> Thanks
> 
>>   	return 0;
>>   }
>>   

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 1. Log shows wait IRQ timeout ?

Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done


> 2. Always happened  issue ?  timeout at the beginning or  in processing ?

The commands that I run is:

sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator

The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.

> 3. how about IRQ infos?
> cat /proc/interrupts | grep vcodec
> 18002000.vcodec   >> it's H.264 encoder
> 19002000.vcodec  >> it's  VP8 encoder
> 
> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?

No,
But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.

>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5


> 
> MT8173 latest VPUD firmware:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> 

I uses the latest firmware.

Thanks,
Dafna

> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月6日 15:49
> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊); eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com; mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen (陳智迪); acourbot@chromium.org
> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR 
>>> pointer.
>>> 2. Fail if the state from the vpu msg is either 
>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>
>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>> ---
>>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> index 32dc844d16f9..234705ba7cd6 100644
>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst 
>>> *vpu, const void *data)
>>>   vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>        msg->vpu_inst_addr);
>>>   
>>> +if (IS_ERR(vpu->vsi))
>>> +return PTR_ERR(vpu->vsi);
>>>   /* Firmware version field value is unspecified on MT8173. */
>>>   if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>   return 0;
>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct 
>>> venc_vpu_inst *vpu, const void *data)
>>>   vpu->state = msg->state;
>>>   vpu->bs_size = msg->bs_size;
>>>   vpu->is_key_frm = msg->is_key_frm;
>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>> +mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>>> +       vpu->state ==
>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>> +return -EINVAL;
>>> +}
>> 
>> Hi Dafna,
>> 
>> This state check is useless, the enc result will check in 
>> "vpu_enc_ipi_handler".
>> 
> 
> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
> 
> Can't there be a scenario where msg->status is ok but the state is error?
> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> 
>>>   return 0;
>>>   }
>>>   
> 
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
> 

Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 1. Log shows wait IRQ timeout ?

Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done


> 2. Always happened  issue ?  timeout at the beginning or  in processing ?

The commands that I run is:

sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator

The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.

> 3. how about IRQ infos?
> cat /proc/interrupts | grep vcodec
> 18002000.vcodec   >> it's H.264 encoder
> 19002000.vcodec  >> it's  VP8 encoder
> 
> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?

No,
But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.

>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5


> 
> MT8173 latest VPUD firmware:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> 

I uses the latest firmware.

Thanks,
Dafna

> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月6日 15:49
> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊); eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com; mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen (陳智迪); acourbot@chromium.org
> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR 
>>> pointer.
>>> 2. Fail if the state from the vpu msg is either 
>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>
>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>> ---
>>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> index 32dc844d16f9..234705ba7cd6 100644
>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct venc_vpu_inst 
>>> *vpu, const void *data)
>>>   vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>        msg->vpu_inst_addr);
>>>   
>>> +if (IS_ERR(vpu->vsi))
>>> +return PTR_ERR(vpu->vsi);
>>>   /* Firmware version field value is unspecified on MT8173. */
>>>   if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>   return 0;
>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct 
>>> venc_vpu_inst *vpu, const void *data)
>>>   vpu->state = msg->state;
>>>   vpu->bs_size = msg->bs_size;
>>>   vpu->is_key_frm = msg->is_key_frm;
>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>> +mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>>> +       vpu->state ==
>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>> +return -EINVAL;
>>> +}
>> 
>> Hi Dafna,
>> 
>> This state check is useless, the enc result will check in 
>> "vpu_enc_ipi_handler".
>> 
> 
> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
> 
> Can't there be a scenario where msg->status is ok but the state is error?
> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> 
>>>   return 0;
>>>   }
>>>   
> 
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang (王瑞)]

Hi Dafna,

>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?

>The commands that I run is:

>>sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator

>>The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.

It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:

cat /sys/kernel/debug/clk/clk_summary | grep venc:

venc_sel   > it's H.264 clock 
venclt_sel  > it's VP8 clock

the enable&prepare count is not 0 during encoding process.

Thanks
Best Regards

-----邮件原件-----
发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com] 
发送时间: 2021年8月9日 16:27
收件人: Irui Wang (王瑞)
抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling



On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 1. Log shows wait IRQ timeout ?

Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done


> 2. Always happened  issue ?  timeout at the beginning or  in processing ?

The commands that I run is:

sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator

The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.

> 3. how about IRQ infos?
> cat /proc/interrupts | grep vcodec
> 18002000.vcodec   >> it's H.264 encoder
> 19002000.vcodec  >> it's  VP8 encoder
> 
> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?

No,
But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.

>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5


> 
> MT8173 latest VPUD firmware:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> 

I uses the latest firmware.

Thanks,
Dafna

> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月6日 15:49
> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org; 
> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊); 
> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com; 
> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu 
> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen 
> (陳智迪); acourbot@chromium.org
> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu 
> irq handling
> 
> 
> 
> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR 
>>> pointer.
>>> 2. Fail if the state from the vpu msg is either 
>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>
>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>> ---
>>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> index 32dc844d16f9..234705ba7cd6 100644
>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct 
>>> venc_vpu_inst *vpu, const void *data)
>>>   vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>        msg->vpu_inst_addr);
>>>   
>>> +if (IS_ERR(vpu->vsi))
>>> +return PTR_ERR(vpu->vsi);
>>>   /* Firmware version field value is unspecified on MT8173. */
>>>   if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>   return 0;
>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct 
>>> venc_vpu_inst *vpu, const void *data)
>>>   vpu->state = msg->state;
>>>   vpu->bs_size = msg->bs_size;
>>>   vpu->is_key_frm = msg->is_key_frm;
>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { mtk_vcodec_err(vpu, 
>>> +"bad ipi-enc-state: %s",
>>> +       vpu->state ==
>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>> +return -EINVAL;
>>> +}
>> 
>> Hi Dafna,
>> 
>> This state check is useless, the enc result will check in 
>> "vpu_enc_ipi_handler".
>> 
> 
> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
> 
> Can't there be a scenario where msg->status is ok but the state is error?
> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> 
>>>   return 0;
>>>   }
>>>   
> 
> ************* MEDIATEK Confidentiality Notice ******************** The 
> information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or 
> otherwise exempt from disclosure under applicable laws. It is intended 
> to be conveyed only to the designated recipient(s). Any use, 
> dissemination, distribution, printing, retaining or copying of this 
> e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may 
> be unlawful. If you are not an intended recipient of this e-mail, or 
> believe that you have received this e-mail in error, please notify the 
> sender immediately (by replying to this e-mail), delete any and all 
> copies of this e-mail (including any attachments) from your system, 
> and do not disclose the content of this e-mail to any other person. Thank you!
> 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 11:12, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
>> The commands that I run is:
> 
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
> 
> cat /sys/kernel/debug/clk/clk_summary | grep venc:
> 
> venc_sel   > it's H.264 clock
> venclt_sel  > it's VP8 clock
> 
> the enable&prepare count is not 0 during encoding process.

I see that the values are indeed incremented while streaming.
When timeout occurs it is always in the beginning of the encoding. So upon the first call to vp8_enc_wait_venc_done.

Thanks,
Dafna


> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月9日 16:27
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>> 1. Log shows wait IRQ timeout ?
> 
> Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done
> 
> 
>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
> The commands that I run is:
> 
> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
>> 3. how about IRQ infos?
>> cat /proc/interrupts | grep vcodec
>> 18002000.vcodec   >> it's H.264 encoder
>> 19002000.vcodec  >> it's  VP8 encoder
>>
>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
> 
> No,
> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
> 
>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5
> 
> 
>>
>> MT8173 latest VPUD firmware:
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>
> 
> I uses the latest firmware.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月6日 15:49
>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>> (陳智迪); acourbot@chromium.org
>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>> irq handling
>>
>>
>>
>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>> pointer.
>>>> 2. Fail if the state from the vpu msg is either
>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>
>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>> ---
>>>>    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>         msg->vpu_inst_addr);
>>>>    
>>>> +if (IS_ERR(vpu->vsi))
>>>> +return PTR_ERR(vpu->vsi);
>>>>    /* Firmware version field value is unspecified on MT8173. */
>>>>    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>    return 0;
>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->state = msg->state;
>>>>    vpu->bs_size = msg->bs_size;
>>>>    vpu->is_key_frm = msg->is_key_frm;
>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { mtk_vcodec_err(vpu,
>>>> +"bad ipi-enc-state: %s",
>>>> +       vpu->state ==
>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>> +return -EINVAL;
>>>> +}
>>>
>>> Hi Dafna,
>>>
>>> This state check is useless, the enc result will check in
>>> "vpu_enc_ipi_handler".
>>>
>>
>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>
>> Can't there be a scenario where msg->status is ok but the state is error?
>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>>
>>>>    return 0;
>>>>    }
>>>>    
>>
>> ************* MEDIATEK Confidentiality Notice ******************** The
>> information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or
>> otherwise exempt from disclosure under applicable laws. It is intended
>> to be conveyed only to the designated recipient(s). Any use,
>> dissemination, distribution, printing, retaining or copying of this
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and may
>> be unlawful. If you are not an intended recipient of this e-mail, or
>> believe that you have received this e-mail in error, please notify the
>> sender immediately (by replying to this e-mail), delete any and all
>> copies of this e-mail (including any attachments) from your system,
>> and do not disclose the content of this e-mail to any other person. Thank you!
>>

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 11:12, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
>> The commands that I run is:
> 
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
> 
> cat /sys/kernel/debug/clk/clk_summary | grep venc:
> 
> venc_sel   > it's H.264 clock
> venclt_sel  > it's VP8 clock
> 
> the enable&prepare count is not 0 during encoding process.

I see that the values are indeed incremented while streaming.
When timeout occurs it is always in the beginning of the encoding. So upon the first call to vp8_enc_wait_venc_done.

Thanks,
Dafna


> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月9日 16:27
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>> 1. Log shows wait IRQ timeout ?
> 
> Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done
> 
> 
>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
> The commands that I run is:
> 
> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
>> 3. how about IRQ infos?
>> cat /proc/interrupts | grep vcodec
>> 18002000.vcodec   >> it's H.264 encoder
>> 19002000.vcodec  >> it's  VP8 encoder
>>
>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
> 
> No,
> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
> 
>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5
> 
> 
>>
>> MT8173 latest VPUD firmware:
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>
> 
> I uses the latest firmware.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月6日 15:49
>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>> (陳智迪); acourbot@chromium.org
>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>> irq handling
>>
>>
>>
>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>> pointer.
>>>> 2. Fail if the state from the vpu msg is either
>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>
>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>> ---
>>>>    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>         msg->vpu_inst_addr);
>>>>    
>>>> +if (IS_ERR(vpu->vsi))
>>>> +return PTR_ERR(vpu->vsi);
>>>>    /* Firmware version field value is unspecified on MT8173. */
>>>>    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>    return 0;
>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->state = msg->state;
>>>>    vpu->bs_size = msg->bs_size;
>>>>    vpu->is_key_frm = msg->is_key_frm;
>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { mtk_vcodec_err(vpu,
>>>> +"bad ipi-enc-state: %s",
>>>> +       vpu->state ==
>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>> +return -EINVAL;
>>>> +}
>>>
>>> Hi Dafna,
>>>
>>> This state check is useless, the enc result will check in
>>> "vpu_enc_ipi_handler".
>>>
>>
>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>
>> Can't there be a scenario where msg->status is ok but the state is error?
>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>>
>>>>    return 0;
>>>>    }
>>>>    
>>
>> ************* MEDIATEK Confidentiality Notice ******************** The
>> information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or
>> otherwise exempt from disclosure under applicable laws. It is intended
>> to be conveyed only to the designated recipient(s). Any use,
>> dissemination, distribution, printing, retaining or copying of this
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and may
>> be unlawful. If you are not an intended recipient of this e-mail, or
>> believe that you have received this e-mail in error, please notify the
>> sender immediately (by replying to this e-mail), delete any and all
>> copies of this e-mail (including any attachments) from your system,
>> and do not disclose the content of this e-mail to any other person. Thank you!
>>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 5/5] media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

[Dafna Hirschfeld]

On 06.08.21 08:50, Irui Wang (王瑞) wrote:
> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>> Each message sent to the VPU should raise a signal. The signal
>> handler sets vpu->signaled. Test the field and fail
>> if it is 0.
> 
> I suppose you want to handle the message execution result, if ipi
> message can't send or acked successfully, the returned "status" of
> "mtk_vcodec_fw_ipi_send" will return, so I think you don't need to
> check "signaled" again.

in that case, the field 'signaled' is not needed and can be removed
So I can send a patch to remove it.

Thanks,
Dafna

> 
>>
>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>> ---
>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> index 234705ba7cd6..8331b1bd1971 100644
>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> @@ -92,6 +92,7 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
>> *vpu, void *msg,
>>   {
>>   	int status;
>>   
>> +	vpu->signaled = 0;
>>   	mtk_vcodec_debug_enter(vpu);
>>   
>>   	if (!vpu->ctx->dev->fw_handler) {
>> @@ -106,6 +107,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
>> *vpu, void *msg,
>>   			       *(uint32_t *)msg, len, status);
>>   		return -EINVAL;
>>   	}
>> +	if (!vpu->signaled)
>> +		return -EINVAL;
>>   	if (vpu->failure)
>>   		return -EINVAL;
>>   
>> @@ -122,7 +125,6 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
>>   	mtk_vcodec_debug_enter(vpu);
>>   
>>   	init_waitqueue_head(&vpu->wq_hd);
>> -	vpu->signaled = 0;
>>   	vpu->failure = 0;
>>   
>>   	status = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
>> vpu->id,

Re: [PATCH 5/5] media: mtk-vcodec: venc: Fail if a msg sent to VPU was not signaled

[Dafna Hirschfeld]

On 06.08.21 08:50, Irui Wang (王瑞) wrote:
> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>> Each message sent to the VPU should raise a signal. The signal
>> handler sets vpu->signaled. Test the field and fail
>> if it is 0.
> 
> I suppose you want to handle the message execution result, if ipi
> message can't send or acked successfully, the returned "status" of
> "mtk_vcodec_fw_ipi_send" will return, so I think you don't need to
> check "signaled" again.

in that case, the field 'signaled' is not needed and can be removed
So I can send a patch to remove it.

Thanks,
Dafna

> 
>>
>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>> ---
>>   drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> index 234705ba7cd6..8331b1bd1971 100644
>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>> @@ -92,6 +92,7 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
>> *vpu, void *msg,
>>   {
>>   	int status;
>>   
>> +	vpu->signaled = 0;
>>   	mtk_vcodec_debug_enter(vpu);
>>   
>>   	if (!vpu->ctx->dev->fw_handler) {
>> @@ -106,6 +107,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst
>> *vpu, void *msg,
>>   			       *(uint32_t *)msg, len, status);
>>   		return -EINVAL;
>>   	}
>> +	if (!vpu->signaled)
>> +		return -EINVAL;
>>   	if (vpu->failure)
>>   		return -EINVAL;
>>   
>> @@ -122,7 +125,6 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
>>   	mtk_vcodec_debug_enter(vpu);
>>   
>>   	init_waitqueue_head(&vpu->wq_hd);
>> -	vpu->signaled = 0;
>>   	vpu->failure = 0;
>>   
>>   	status = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
>> vpu->id,

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
>> The commands that I run is:
> 
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
> 
> cat /sys/kernel/debug/clk/clk_summary | grep venc:
> 
> venc_sel   > it's H.264 clock
> venclt_sel  > it's VP8 clock
> 
> the enable&prepare count is not 0 during encoding process.
> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月9日 16:27
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>> 1. Log shows wait IRQ timeout ?
> 
> Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done
> 
> 
>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
> The commands that I run is:
> 
> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
>> 3. how about IRQ infos?
>> cat /proc/interrupts | grep vcodec
>> 18002000.vcodec   >> it's H.264 encoder
>> 19002000.vcodec  >> it's  VP8 encoder
>>
>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
> 
> No,
> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
> 
>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5

Hi,
I test the driver on debian now, I stream several instances of vp8 and h264 in parallel.
I see that those errors always occur after an iommu page fault:

[gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0 layer=1 write
[ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
[ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame() irq_status=0 failed
[ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode failed=-5

I suspect that maybe this is because the iova of the working_buffers is handed to the vpu in the function vp8_enc_alloc_work_buf:
wb[i].iova = inst->work_bufs[i].dma_addr;

Maybe the vpu keep writing to those addresses after they are already unmapped?

Thanks,
Dafna


> 
> 
>>
>> MT8173 latest VPUD firmware:
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>
> 
> I uses the latest firmware.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月6日 15:49
>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>> (陳智迪); acourbot@chromium.org
>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>> irq handling
>>
>>
>>
>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>> pointer.
>>>> 2. Fail if the state from the vpu msg is either
>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>
>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>> ---
>>>>    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>         msg->vpu_inst_addr);
>>>>    
>>>> +if (IS_ERR(vpu->vsi))
>>>> +return PTR_ERR(vpu->vsi);
>>>>    /* Firmware version field value is unspecified on MT8173. */
>>>>    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>    return 0;
>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->state = msg->state;
>>>>    vpu->bs_size = msg->bs_size;
>>>>    vpu->is_key_frm = msg->is_key_frm;
>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { mtk_vcodec_err(vpu,
>>>> +"bad ipi-enc-state: %s",
>>>> +       vpu->state ==
>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>> +return -EINVAL;
>>>> +}
>>>
>>> Hi Dafna,
>>>
>>> This state check is useless, the enc result will check in
>>> "vpu_enc_ipi_handler".
>>>
>>
>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>
>> Can't there be a scenario where msg->status is ok but the state is error?
>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>>
>>>>    return 0;
>>>>    }
>>>>    
>>
>> ************* MEDIATEK Confidentiality Notice ******************** The
>> information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or
>> otherwise exempt from disclosure under applicable laws. It is intended
>> to be conveyed only to the designated recipient(s). Any use,
>> dissemination, distribution, printing, retaining or copying of this
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and may
>> be unlawful. If you are not an intended recipient of this e-mail, or
>> believe that you have received this e-mail in error, please notify the
>> sender immediately (by replying to this e-mail), delete any and all
>> copies of this e-mail (including any attachments) from your system,
>> and do not disclose the content of this e-mail to any other person. Thank you!
>>

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
>> The commands that I run is:
> 
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
> 
> cat /sys/kernel/debug/clk/clk_summary | grep venc:
> 
> venc_sel   > it's H.264 clock
> venclt_sel  > it's VP8 clock
> 
> the enable&prepare count is not 0 during encoding process.
> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月9日 16:27
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>> 1. Log shows wait IRQ timeout ?
> 
> Hi, yes, I get timeout when waiting to the encoder interrupt. The timeout is on vp8_enc_wait_venc_done
> 
> 
>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
> The commands that I run is:
> 
> sudo --user=#1000 /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests --gtest_filter=-*NV12Dmabuf*  --codec=vp8 /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv --disable_validator
> 
> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
>> 3. how about IRQ infos?
>> cat /proc/interrupts | grep vcodec
>> 18002000.vcodec   >> it's H.264 encoder
>> 19002000.vcodec  >> it's  VP8 encoder
>>
>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
> 
> No,
> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
> 
>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5

Hi,
I test the driver on debian now, I stream several instances of vp8 and h264 in parallel.
I see that those errors always occur after an iommu page fault:

[gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0 layer=1 write
[ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
[ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame() irq_status=0 failed
[ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode failed=-5

I suspect that maybe this is because the iova of the working_buffers is handed to the vpu in the function vp8_enc_alloc_work_buf:
wb[i].iova = inst->work_bufs[i].dma_addr;

Maybe the vpu keep writing to those addresses after they are already unmapped?

Thanks,
Dafna


> 
> 
>>
>> MT8173 latest VPUD firmware:
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>
> 
> I uses the latest firmware.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月6日 15:49
>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>> (陳智迪); acourbot@chromium.org
>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>> irq handling
>>
>>
>>
>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>> pointer.
>>>> 2. Fail if the state from the vpu msg is either
>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>
>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>> ---
>>>>    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>         msg->vpu_inst_addr);
>>>>    
>>>> +if (IS_ERR(vpu->vsi))
>>>> +return PTR_ERR(vpu->vsi);
>>>>    /* Firmware version field value is unspecified on MT8173. */
>>>>    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>    return 0;
>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->state = msg->state;
>>>>    vpu->bs_size = msg->bs_size;
>>>>    vpu->is_key_frm = msg->is_key_frm;
>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { mtk_vcodec_err(vpu,
>>>> +"bad ipi-enc-state: %s",
>>>> +       vpu->state ==
>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>> +return -EINVAL;
>>>> +}
>>>
>>> Hi Dafna,
>>>
>>> This state check is useless, the enc result will check in
>>> "vpu_enc_ipi_handler".
>>>
>>
>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>
>> Can't there be a scenario where msg->status is ok but the state is error?
>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>>
>>>>    return 0;
>>>>    }
>>>>    
>>
>> ************* MEDIATEK Confidentiality Notice ******************** The
>> information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or
>> otherwise exempt from disclosure under applicable laws. It is intended
>> to be conveyed only to the designated recipient(s). Any use,
>> dissemination, distribution, printing, retaining or copying of this
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and may
>> be unlawful. If you are not an intended recipient of this e-mail, or
>> believe that you have received this e-mail in error, please notify the
>> sender immediately (by replying to this e-mail), delete any and all
>> copies of this e-mail (including any attachments) from your system,
>> and do not disclose the content of this e-mail to any other person. Thank you!
>>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

Hi, 

On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> 
> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > Hi Dafna,
> > 
> > > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > > processing ?
> > > The commands that I run is:
> > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > *NV12Dmabuf*  -->>codec=vp8
> > > > >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/
> > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > The command sometime succeed but when I run it sequentially
> > > > then at some point after few attempts I start to get those
> > > > timeout errors.
> > 
> > It seems mean VP8 encoding function OK, but failed sometimes, did
> > you have check VENC clock info during encoding:
> > 
> > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > 
> > venc_sel   > it's H.264 clock
> > venclt_sel  > it's VP8 clock
> > 
> > the enable&prepare count is not 0 during encoding process.
> > 
> > Thanks
> > Best Regards
> > 
> > -----邮件原件-----
> > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > 发送时间: 2021年8月9日 16:27
> > 收件人: Irui Wang (王瑞)
> > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
> > support; Enric Balletbo i Serra
> > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
> > vpu irq handling
> > 
> > 
> > 
> > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > Hi Dafna,
> > > 
> > > > > I am testing the vp8 encoder on chromeos and at some point
> > > > > the encoder interrupts stop arriving so I try to figure out
> > > > > why and report any possible error.
> > > 
> > > 1. Log shows wait IRQ timeout ?
> > 
> > Hi, yes, I get timeout when waiting to the encoder interrupt. The
> > timeout is on vp8_enc_wait_venc_done
> > 
> > 
> > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > processing ?
> > 
> > The commands that I run is:
> > 
> > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > tests/video_encode_accelerator_tests --gtest_filter=-
> > *NV12Dmabuf*  --codec=vp8
> > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
> > /data/tulip2-320x180.yuv --disable_validator
> > 
> > The command sometime succeed but when I run it sequentially then at
> > some point after few attempts I start to get those timeout errors.
> > 
> > > 3. how about IRQ infos?
> > > cat /proc/interrupts | grep vcodec
> > > 18002000.vcodec   >> it's H.264 encoder
> > > 19002000.vcodec  >> it's  VP8 encoder
> > > 
> > > I was told you have  met another H.264 encoding failed before,
> > > did you find reasons about that ?
> > 
> > No,
> > But since I see that the google meetup uses the vp8 encoder I
> > decided to test the vp8 first.
> > 
> > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
> > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
> > > > irq_status=0 failed
> > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > venc_if_encode failed=-5
> 
> Hi,
> I test the driver on debian now, I stream several instances of vp8
> and h264 in parallel.
> I see that those errors always occur after an iommu page fault:
> 
> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0
> layer=1 write
> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> time=1000ms out 0 0!
> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
> irq_status=0 failed
> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode
> failed=-5
> 
> I suspect that maybe this is because the iova of the working_buffers
> is handed to the vpu in the function vp8_enc_alloc_work_buf:
> wb[i].iova = inst->work_bufs[i].dma_addr;
> 
> Maybe the vpu keep writing to those addresses after they are already
> unmapped?
> 
> Thanks,
> Dafna

failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is there
any h264 encoding failed at that time? I have no ideas why these errors
happened on your platform, but when we got the "iommu: fault", the
possible reason is related to power or clock.

> 
> 
> > 
> > 
> > > 
> > > MT8173 latest VPUD firmware:
> > > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > 
> > 
> > I uses the latest firmware.
> > 
> > Thanks,
> > Dafna
> > 
> > > Thanks
> > > Best Regards
> > > 
> > > -----邮件原件-----
> > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > 发送时间: 2021年8月6日 15:49
> > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
> > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
> > > eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
> > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong
> > > Wu
> > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
> > > (陳智迪); acourbot@chromium.org
> > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
> > > vpu
> > > irq handling
> > > 
> > > 
> > > 
> > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
> > > > > pointer.
> > > > > 2. Fail if the state from the vpu msg is either
> > > > > VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
> > > > > 
> > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > dafna.hirschfeld@collabora.com>
> > > > > ---
> > > > >    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
> > > > > ++++++++
> > > > >    1 file changed, 8 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
> > > > > venc_vpu_inst *vpu, const void *data)
> > > > >    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
> > > > > >fw_handler,
> > > > >         msg->vpu_inst_addr);
> > > > >    
> > > > > +if (IS_ERR(vpu->vsi))
> > > > > +return PTR_ERR(vpu->vsi);
> > > > >    /* Firmware version field value is unspecified on MT8173.
> > > > > */
> > > > >    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
> > > > >    return 0;
> > > > > @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
> > > > > venc_vpu_inst *vpu, const void *data)
> > > > >    vpu->state = msg->state;
> > > > >    vpu->bs_size = msg->bs_size;
> > > > >    vpu->is_key_frm = msg->is_key_frm;
> > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > mtk_vcodec_err(vpu,
> > > > > +"bad ipi-enc-state: %s",
> > > > > +       vpu->state ==
> > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > +return -EINVAL;
> > > > > +}
> > > > 
> > > > Hi Dafna,
> > > > 
> > > > This state check is useless, the enc result will check in
> > > > "vpu_enc_ipi_handler".
> > > > 
> > > 
> > > Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only
> > > test the msg->status and I see that the states are not tested
> > > anywhere except of "skip" state in the h264 enc.
> > > 
> > > Can't there be a scenario where msg->status is ok but the state
> > > is error?
> > > I am testing the vp8 encoder on chromeos and at some point the
> > > encoder interrupts stop arriving so I try to figure out why and
> > > report any possible error.
> > > 
> > > Thanks,
> > > Dafna
> > > 
> > > > Thanks
> > > > 
> > > > >    return 0;
> > > > >    }
> > > > >    
> > > 
> > > ************* MEDIATEK Confidentiality Notice
> > > ******************** The
> > > information contained in this e-mail message (including any
> > > attachments) may be confidential, proprietary, privileged, or
> > > otherwise exempt from disclosure under applicable laws. It is
> > > intended
> > > to be conveyed only to the designated recipient(s). Any use,
> > > dissemination, distribution, printing, retaining or copying of
> > > this
> > > e-mail (including its
> > > attachments) by unintended recipient(s) is strictly prohibited
> > > and may
> > > be unlawful. If you are not an intended recipient of this e-mail, 
> > > or
> > > believe that you have received this e-mail in error, please
> > > notify the
> > > sender immediately (by replying to this e-mail), delete any and
> > > all
> > > copies of this e-mail (including any attachments) from your
> > > system,
> > > and do not disclose the content of this e-mail to any other
> > > person. Thank you!
> > > 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

Hi, 

On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> 
> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > Hi Dafna,
> > 
> > > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > > processing ?
> > > The commands that I run is:
> > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > *NV12Dmabuf*  -->>codec=vp8
> > > > >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/
> > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > The command sometime succeed but when I run it sequentially
> > > > then at some point after few attempts I start to get those
> > > > timeout errors.
> > 
> > It seems mean VP8 encoding function OK, but failed sometimes, did
> > you have check VENC clock info during encoding:
> > 
> > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > 
> > venc_sel   > it's H.264 clock
> > venclt_sel  > it's VP8 clock
> > 
> > the enable&prepare count is not 0 during encoding process.
> > 
> > Thanks
> > Best Regards
> > 
> > -----邮件原件-----
> > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > 发送时间: 2021年8月9日 16:27
> > 收件人: Irui Wang (王瑞)
> > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
> > support; Enric Balletbo i Serra
> > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
> > vpu irq handling
> > 
> > 
> > 
> > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > Hi Dafna,
> > > 
> > > > > I am testing the vp8 encoder on chromeos and at some point
> > > > > the encoder interrupts stop arriving so I try to figure out
> > > > > why and report any possible error.
> > > 
> > > 1. Log shows wait IRQ timeout ?
> > 
> > Hi, yes, I get timeout when waiting to the encoder interrupt. The
> > timeout is on vp8_enc_wait_venc_done
> > 
> > 
> > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > processing ?
> > 
> > The commands that I run is:
> > 
> > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > tests/video_encode_accelerator_tests --gtest_filter=-
> > *NV12Dmabuf*  --codec=vp8
> > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
> > /data/tulip2-320x180.yuv --disable_validator
> > 
> > The command sometime succeed but when I run it sequentially then at
> > some point after few attempts I start to get those timeout errors.
> > 
> > > 3. how about IRQ infos?
> > > cat /proc/interrupts | grep vcodec
> > > 18002000.vcodec   >> it's H.264 encoder
> > > 19002000.vcodec  >> it's  VP8 encoder
> > > 
> > > I was told you have  met another H.264 encoding failed before,
> > > did you find reasons about that ?
> > 
> > No,
> > But since I see that the google meetup uses the vp8 encoder I
> > decided to test the vp8 first.
> > 
> > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
> > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
> > > > irq_status=0 failed
> > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > venc_if_encode failed=-5
> 
> Hi,
> I test the driver on debian now, I stream several instances of vp8
> and h264 in parallel.
> I see that those errors always occur after an iommu page fault:
> 
> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0
> layer=1 write
> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> time=1000ms out 0 0!
> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
> irq_status=0 failed
> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode
> failed=-5
> 
> I suspect that maybe this is because the iova of the working_buffers
> is handed to the vpu in the function vp8_enc_alloc_work_buf:
> wb[i].iova = inst->work_bufs[i].dma_addr;
> 
> Maybe the vpu keep writing to those addresses after they are already
> unmapped?
> 
> Thanks,
> Dafna

failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is there
any h264 encoding failed at that time? I have no ideas why these errors
happened on your platform, but when we got the "iommu: fault", the
possible reason is related to power or clock.

> 
> 
> > 
> > 
> > > 
> > > MT8173 latest VPUD firmware:
> > > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > 
> > 
> > I uses the latest firmware.
> > 
> > Thanks,
> > Dafna
> > 
> > > Thanks
> > > Best Regards
> > > 
> > > -----邮件原件-----
> > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > 发送时间: 2021年8月6日 15:49
> > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
> > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
> > > eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
> > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong
> > > Wu
> > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
> > > (陳智迪); acourbot@chromium.org
> > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
> > > vpu
> > > irq handling
> > > 
> > > 
> > > 
> > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
> > > > > pointer.
> > > > > 2. Fail if the state from the vpu msg is either
> > > > > VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
> > > > > 
> > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > dafna.hirschfeld@collabora.com>
> > > > > ---
> > > > >    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
> > > > > ++++++++
> > > > >    1 file changed, 8 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
> > > > > venc_vpu_inst *vpu, const void *data)
> > > > >    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
> > > > > >fw_handler,
> > > > >         msg->vpu_inst_addr);
> > > > >    
> > > > > +if (IS_ERR(vpu->vsi))
> > > > > +return PTR_ERR(vpu->vsi);
> > > > >    /* Firmware version field value is unspecified on MT8173.
> > > > > */
> > > > >    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
> > > > >    return 0;
> > > > > @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
> > > > > venc_vpu_inst *vpu, const void *data)
> > > > >    vpu->state = msg->state;
> > > > >    vpu->bs_size = msg->bs_size;
> > > > >    vpu->is_key_frm = msg->is_key_frm;
> > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > mtk_vcodec_err(vpu,
> > > > > +"bad ipi-enc-state: %s",
> > > > > +       vpu->state ==
> > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > +return -EINVAL;
> > > > > +}
> > > > 
> > > > Hi Dafna,
> > > > 
> > > > This state check is useless, the enc result will check in
> > > > "vpu_enc_ipi_handler".
> > > > 
> > > 
> > > Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only
> > > test the msg->status and I see that the states are not tested
> > > anywhere except of "skip" state in the h264 enc.
> > > 
> > > Can't there be a scenario where msg->status is ok but the state
> > > is error?
> > > I am testing the vp8 encoder on chromeos and at some point the
> > > encoder interrupts stop arriving so I try to figure out why and
> > > report any possible error.
> > > 
> > > Thanks,
> > > Dafna
> > > 
> > > > Thanks
> > > > 
> > > > >    return 0;
> > > > >    }
> > > > >    
> > > 
> > > ************* MEDIATEK Confidentiality Notice
> > > ******************** The
> > > information contained in this e-mail message (including any
> > > attachments) may be confidential, proprietary, privileged, or
> > > otherwise exempt from disclosure under applicable laws. It is
> > > intended
> > > to be conveyed only to the designated recipient(s). Any use,
> > > dissemination, distribution, printing, retaining or copying of
> > > this
> > > e-mail (including its
> > > attachments) by unintended recipient(s) is strictly prohibited
> > > and may
> > > be unlawful. If you are not an intended recipient of this e-mail, 
> > > or
> > > believe that you have received this e-mail in error, please
> > > notify the
> > > sender immediately (by replying to this e-mail), delete any and
> > > all
> > > copies of this e-mail (including any attachments) from your
> > > system,
> > > and do not disclose the content of this e-mail to any other
> > > person. Thank you!
> > > 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 03:38, Irui Wang wrote:
> Hi,
> 
> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>
>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>> Hi Dafna,
>>>
>>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>>> processing ?
>>>> The commands that I run is:
>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/
>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>> The command sometime succeed but when I run it sequentially
>>>>> then at some point after few attempts I start to get those
>>>>> timeout errors.
>>>
>>> It seems mean VP8 encoding function OK, but failed sometimes, did
>>> you have check VENC clock info during encoding:
>>>
>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>
>>> venc_sel   > it's H.264 clock
>>> venclt_sel  > it's VP8 clock
>>>
>>> the enable&prepare count is not 0 during encoding process.
>>>
>>> Thanks
>>> Best Regards
>>>
>>> -----邮件原件-----
>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>> 发送时间: 2021年8月9日 16:27
>>> 收件人: Irui Wang (王瑞)
>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
>>> support; Enric Balletbo i Serra
>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>>> vpu irq handling
>>>
>>>
>>>
>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>> Hi Dafna,
>>>>
>>>>>> I am testing the vp8 encoder on chromeos and at some point
>>>>>> the encoder interrupts stop arriving so I try to figure out
>>>>>> why and report any possible error.
>>>>
>>>> 1. Log shows wait IRQ timeout ?
>>>
>>> Hi, yes, I get timeout when waiting to the encoder interrupt. The
>>> timeout is on vp8_enc_wait_venc_done
>>>
>>>
>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>> processing ?
>>>
>>> The commands that I run is:
>>>
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>> *NV12Dmabuf*  --codec=vp8
>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
>>> /data/tulip2-320x180.yuv --disable_validator
>>>
>>> The command sometime succeed but when I run it sequentially then at
>>> some point after few attempts I start to get those timeout errors.
>>>
>>>> 3. how about IRQ infos?
>>>> cat /proc/interrupts | grep vcodec
>>>> 18002000.vcodec   >> it's H.264 encoder
>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>
>>>> I was told you have  met another H.264 encoding failed before,
>>>> did you find reasons about that ?
>>>
>>> No,
>>> But since I see that the google meetup uses the vp8 encoder I
>>> decided to test the vp8 first.
>>>
>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
>>>>> irq_status=0 failed
>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>> venc_if_encode failed=-5
>>
>> Hi,
>> I test the driver on debian now, I stream several instances of vp8
>> and h264 in parallel.
>> I see that those errors always occur after an iommu page fault:
>>
>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0
>> layer=1 write
>> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>> time=1000ms out 0 0!
>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
>> irq_status=0 failed
>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode
>> failed=-5
>>
>> I suspect that maybe this is because the iova of the working_buffers
>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>
>> Maybe the vpu keep writing to those addresses after they are already
>> unmapped?
>>
>> Thanks,
>> Dafna
> 
> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is there
> any h264 encoding failed at that time? I have no ideas why these errors
> happened on your platform, but when we got the "iommu: fault", the
> possible reason is related to power or clock.

Once the iommu fault fires, both encoders constantly fail and never recover
(also not when starting new instance).

With the falut:
mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write

I looked at the iommu tracing log:

   gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU: iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096 unmapped_size=4096
   gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU: iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480 unmapped_size=20480
   gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU: iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU: iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU: iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU: iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU: iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536 unmapped_size=65536
   gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU: iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536 unmapped_size=65536
   gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU: iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096 unmapped_size=4096
      kworker/0:0-537     [000] d.h..   714.636191: io_page_fault: IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001

(I changed the iommu map/unmap trace events to print the iova range)
you can see the first line unmapping 00000000ebede000 which is the faulting iova.
So it seems that the problem is due to a device trying to access an address that is already unmapped.
This might be either the encoder or the vpu.
Since the wb[i].iova is not reset when freeing the working buffers I suspect it might be the vpu device, what do you think?

Thanks,
Dafna

> 
>>
>>
>>>
>>>
>>>>
>>>> MT8173 latest VPUD firmware:
>>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>
>>>
>>> I uses the latest firmware.
>>>
>>> Thanks,
>>> Dafna
>>>
>>>> Thanks
>>>> Best Regards
>>>>
>>>> -----邮件原件-----
>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>> 发送时间: 2021年8月6日 15:49
>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong
>>>> Wu
>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>>>> (陳智迪); acourbot@chromium.org
>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>>>> vpu
>>>> irq handling
>>>>
>>>>
>>>>
>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>>>> pointer.
>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>>
>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>> dafna.hirschfeld@collabora.com>
>>>>>> ---
>>>>>>     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
>>>>>> ++++++++
>>>>>>     1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
>>>>>>> fw_handler,
>>>>>>          msg->vpu_inst_addr);
>>>>>>     
>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>     /* Firmware version field value is unspecified on MT8173.
>>>>>> */
>>>>>>     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>>     return 0;
>>>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>     vpu->state = msg->state;
>>>>>>     vpu->bs_size = msg->bs_size;
>>>>>>     vpu->is_key_frm = msg->is_key_frm;
>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>> mtk_vcodec_err(vpu,
>>>>>> +"bad ipi-enc-state: %s",
>>>>>> +       vpu->state ==
>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>> +return -EINVAL;
>>>>>> +}
>>>>>
>>>>> Hi Dafna,
>>>>>
>>>>> This state check is useless, the enc result will check in
>>>>> "vpu_enc_ipi_handler".
>>>>>
>>>>
>>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only
>>>> test the msg->status and I see that the states are not tested
>>>> anywhere except of "skip" state in the h264 enc.
>>>>
>>>> Can't there be a scenario where msg->status is ok but the state
>>>> is error?
>>>> I am testing the vp8 encoder on chromeos and at some point the
>>>> encoder interrupts stop arriving so I try to figure out why and
>>>> report any possible error.
>>>>
>>>> Thanks,
>>>> Dafna
>>>>
>>>>> Thanks
>>>>>
>>>>>>     return 0;
>>>>>>     }
>>>>>>     
>>>>
>>>> ************* MEDIATEK Confidentiality Notice
>>>> ******************** The
>>>> information contained in this e-mail message (including any
>>>> attachments) may be confidential, proprietary, privileged, or
>>>> otherwise exempt from disclosure under applicable laws. It is
>>>> intended
>>>> to be conveyed only to the designated recipient(s). Any use,
>>>> dissemination, distribution, printing, retaining or copying of
>>>> this
>>>> e-mail (including its
>>>> attachments) by unintended recipient(s) is strictly prohibited
>>>> and may
>>>> be unlawful. If you are not an intended recipient of this e-mail,
>>>> or
>>>> believe that you have received this e-mail in error, please
>>>> notify the
>>>> sender immediately (by replying to this e-mail), delete any and
>>>> all
>>>> copies of this e-mail (including any attachments) from your
>>>> system,
>>>> and do not disclose the content of this e-mail to any other
>>>> person. Thank you!
>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 03:38, Irui Wang wrote:
> Hi,
> 
> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>
>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>> Hi Dafna,
>>>
>>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>>> processing ?
>>>> The commands that I run is:
>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/
>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>> The command sometime succeed but when I run it sequentially
>>>>> then at some point after few attempts I start to get those
>>>>> timeout errors.
>>>
>>> It seems mean VP8 encoding function OK, but failed sometimes, did
>>> you have check VENC clock info during encoding:
>>>
>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>
>>> venc_sel   > it's H.264 clock
>>> venclt_sel  > it's VP8 clock
>>>
>>> the enable&prepare count is not 0 during encoding process.
>>>
>>> Thanks
>>> Best Regards
>>>
>>> -----邮件原件-----
>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>> 发送时间: 2021年8月9日 16:27
>>> 收件人: Irui Wang (王瑞)
>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
>>> support; Enric Balletbo i Serra
>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>>> vpu irq handling
>>>
>>>
>>>
>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>> Hi Dafna,
>>>>
>>>>>> I am testing the vp8 encoder on chromeos and at some point
>>>>>> the encoder interrupts stop arriving so I try to figure out
>>>>>> why and report any possible error.
>>>>
>>>> 1. Log shows wait IRQ timeout ?
>>>
>>> Hi, yes, I get timeout when waiting to the encoder interrupt. The
>>> timeout is on vp8_enc_wait_venc_done
>>>
>>>
>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>> processing ?
>>>
>>> The commands that I run is:
>>>
>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>> *NV12Dmabuf*  --codec=vp8
>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
>>> /data/tulip2-320x180.yuv --disable_validator
>>>
>>> The command sometime succeed but when I run it sequentially then at
>>> some point after few attempts I start to get those timeout errors.
>>>
>>>> 3. how about IRQ infos?
>>>> cat /proc/interrupts | grep vcodec
>>>> 18002000.vcodec   >> it's H.264 encoder
>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>
>>>> I was told you have  met another H.264 encoding failed before,
>>>> did you find reasons about that ?
>>>
>>> No,
>>> But since I see that the google meetup uses the vp8 encoder I
>>> decided to test the vp8 first.
>>>
>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
>>>>> irq_status=0 failed
>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>> venc_if_encode failed=-5
>>
>> Hi,
>> I test the driver on debian now, I stream several instances of vp8
>> and h264 in parallel.
>> I see that those errors always occur after an iommu page fault:
>>
>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3 port=0
>> layer=1 write
>> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>> time=1000ms out 0 0!
>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
>> irq_status=0 failed
>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243: venc_if_encode
>> failed=-5
>>
>> I suspect that maybe this is because the iova of the working_buffers
>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>
>> Maybe the vpu keep writing to those addresses after they are already
>> unmapped?
>>
>> Thanks,
>> Dafna
> 
> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is there
> any h264 encoding failed at that time? I have no ideas why these errors
> happened on your platform, but when we got the "iommu: fault", the
> possible reason is related to power or clock.

Once the iommu fault fires, both encoders constantly fail and never recover
(also not when starting new instance).

With the falut:
mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write

I looked at the iommu tracing log:

   gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU: iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096 unmapped_size=4096
   gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU: iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480 unmapped_size=20480
   gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU: iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU: iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU: iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU: iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU: iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536 unmapped_size=65536
   gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU: iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536 unmapped_size=65536
   gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU: iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096 unmapped_size=4096
      kworker/0:0-537     [000] d.h..   714.636191: io_page_fault: IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001

(I changed the iommu map/unmap trace events to print the iova range)
you can see the first line unmapping 00000000ebede000 which is the faulting iova.
So it seems that the problem is due to a device trying to access an address that is already unmapped.
This might be either the encoder or the vpu.
Since the wb[i].iova is not reset when freeing the working buffers I suspect it might be the vpu device, what do you think?

Thanks,
Dafna

> 
>>
>>
>>>
>>>
>>>>
>>>> MT8173 latest VPUD firmware:
>>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>
>>>
>>> I uses the latest firmware.
>>>
>>> Thanks,
>>> Dafna
>>>
>>>> Thanks
>>>> Best Regards
>>>>
>>>> -----邮件原件-----
>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>> 发送时间: 2021年8月6日 15:49
>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong
>>>> Wu
>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>>>> (陳智迪); acourbot@chromium.org
>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>>>> vpu
>>>> irq handling
>>>>
>>>>
>>>>
>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>>>> pointer.
>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>>
>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>> dafna.hirschfeld@collabora.com>
>>>>>> ---
>>>>>>     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
>>>>>> ++++++++
>>>>>>     1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
>>>>>>> fw_handler,
>>>>>>          msg->vpu_inst_addr);
>>>>>>     
>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>     /* Firmware version field value is unspecified on MT8173.
>>>>>> */
>>>>>>     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>>     return 0;
>>>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>     vpu->state = msg->state;
>>>>>>     vpu->bs_size = msg->bs_size;
>>>>>>     vpu->is_key_frm = msg->is_key_frm;
>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>> mtk_vcodec_err(vpu,
>>>>>> +"bad ipi-enc-state: %s",
>>>>>> +       vpu->state ==
>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>> +return -EINVAL;
>>>>>> +}
>>>>>
>>>>> Hi Dafna,
>>>>>
>>>>> This state check is useless, the enc result will check in
>>>>> "vpu_enc_ipi_handler".
>>>>>
>>>>
>>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only
>>>> test the msg->status and I see that the states are not tested
>>>> anywhere except of "skip" state in the h264 enc.
>>>>
>>>> Can't there be a scenario where msg->status is ok but the state
>>>> is error?
>>>> I am testing the vp8 encoder on chromeos and at some point the
>>>> encoder interrupts stop arriving so I try to figure out why and
>>>> report any possible error.
>>>>
>>>> Thanks,
>>>> Dafna
>>>>
>>>>> Thanks
>>>>>
>>>>>>     return 0;
>>>>>>     }
>>>>>>     
>>>>
>>>> ************* MEDIATEK Confidentiality Notice
>>>> ******************** The
>>>> information contained in this e-mail message (including any
>>>> attachments) may be confidential, proprietary, privileged, or
>>>> otherwise exempt from disclosure under applicable laws. It is
>>>> intended
>>>> to be conveyed only to the designated recipient(s). Any use,
>>>> dissemination, distribution, printing, retaining or copying of
>>>> this
>>>> e-mail (including its
>>>> attachments) by unintended recipient(s) is strictly prohibited
>>>> and may
>>>> be unlawful. If you are not an intended recipient of this e-mail,
>>>> or
>>>> believe that you have received this e-mail in error, please
>>>> notify the
>>>> sender immediately (by replying to this e-mail), delete any and
>>>> all
>>>> copies of this e-mail (including any attachments) from your
>>>> system,
>>>> and do not disclose the content of this e-mail to any other
>>>> person. Thank you!
>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 03:38, Irui Wang wrote:
> > Hi,
> > 
> > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > Hi Dafna,
> > > > 
> > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > or  in
> > > > > > processing ?
> > > > > 
> > > > > The commands that I run is:
> > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/
> > > > > > > cros/
> > > > > > 
> > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > The command sometime succeed but when I run it sequentially
> > > > > > then at some point after few attempts I start to get those
> > > > > > timeout errors.
> > > > 
> > > > It seems mean VP8 encoding function OK, but failed sometimes,
> > > > did
> > > > you have check VENC clock info during encoding:
> > > > 
> > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > 
> > > > venc_sel   > it's H.264 clock
> > > > venclt_sel  > it's VP8 clock
> > > > 
> > > > the enable&prepare count is not 0 during encoding process.
> > > > 
> > > > Thanks
> > > > Best Regards
> > > > 
> > > > -----邮件原件-----
> > > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > > 发送时间: 2021年8月9日 16:27
> > > > 收件人: Irui Wang (王瑞)
> > > > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
> > > > support; Enric Balletbo i Serra
> > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases
> > > > upon
> > > > vpu irq handling
> > > > 
> > > > 
> > > > 
> > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > Hi Dafna,
> > > > > 
> > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > point
> > > > > > > the encoder interrupts stop arriving so I try to figure
> > > > > > > out
> > > > > > > why and report any possible error.
> > > > > 
> > > > > 1. Log shows wait IRQ timeout ?
> > > > 
> > > > Hi, yes, I get timeout when waiting to the encoder interrupt.
> > > > The
> > > > timeout is on vp8_enc_wait_venc_done
> > > > 
> > > > 
> > > > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > > > processing ?
> > > > 
> > > > The commands that I run is:
> > > > 
> > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > *NV12Dmabuf*  --codec=vp8
> > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/v
> > > > ideo
> > > > /data/tulip2-320x180.yuv --disable_validator
> > > > 
> > > > The command sometime succeed but when I run it sequentially
> > > > then at
> > > > some point after few attempts I start to get those timeout
> > > > errors.
> > > > 
> > > > > 3. how about IRQ infos?
> > > > > cat /proc/interrupts | grep vcodec
> > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > 
> > > > > I was told you have  met another H.264 encoding failed
> > > > > before,
> > > > > did you find reasons about that ?
> > > > 
> > > > No,
> > > > But since I see that the google meetup uses the vp8 encoder I
> > > > decided to test the vp8 first.
> > > > 
> > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
> > > > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
> > > > > > irq_status=0 failed
> > > > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > > > venc_if_encode failed=-5
> > > 
> > > Hi,
> > > I test the driver on debian now, I stream several instances of
> > > vp8
> > > and h264 in parallel.
> > > I see that those errors always occur after an iommu page fault:
> > > 
> > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
> > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
> > > port=0
> > > layer=1 write
> > > [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
> > > [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> > > time=1000ms out 0 0!
> > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
> > > irq_status=0 failed
> > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > venc_if_encode
> > > failed=-5
> > > 
> > > I suspect that maybe this is because the iova of the
> > > working_buffers
> > > is handed to the vpu in the function vp8_enc_alloc_work_buf:
> > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > 
> > > Maybe the vpu keep writing to those addresses after they are
> > > already
> > > unmapped?
> > > 
> > > Thanks,
> > > Dafna
> > 
> > failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
> > there
> > any h264 encoding failed at that time? I have no ideas why these
> > errors
> > happened on your platform, but when we got the "iommu: fault", the
> > possible reason is related to power or clock.
> 
> Once the iommu fault fires, both encoders constantly fail and never
> recover
> (also not when starting new instance).
> 
> With the falut:
> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0
> layer=1 write
> 
> I looked at the iommu tracing log:
> 
>    gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU:
> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU:
> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> unmapped_size=20480
>    gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU:
> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU:
> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU:
> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU:
> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU:
> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU:
> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU:
> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> unmapped_size=4096
>       kworker/0:0-537     [000] d.h..   714.636191: io_page_fault:
> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001
> 
> (I changed the iommu map/unmap trace events to print the iova range)
> you can see the first line unmapping 00000000ebede000 which is the
> faulting iova.
> So it seems that the problem is due to a device trying to access an
> address that is already unmapped.
> This might be either the encoder or the vpu.
> Since the wb[i].iova is not reset when freeing the working buffers I
> suspect it might be the vpu device, what do you think?
> 
> Thanks,
> Dafna

vpu device won't access the address, the fault logs:
fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write

it's h264 encoder error when writing "RCPU" data address to encoder
hardware through iommu, but why unmap happended at this time? it seems
encoding process still going on....

> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > MT8173 latest VPUD firmware:
> > > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > > > 
> > > > 
> > > > I uses the latest firmware.
> > > > 
> > > > Thanks,
> > > > Dafna
> > > > 
> > > > > Thanks
> > > > > Best Regards
> > > > > 
> > > > > -----邮件原件-----
> > > > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > > > 发送时间: 2021年8月6日 15:49
> > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > linux-media@vger.kernel.org; 
> > > > > linux-mediatek@lists.infradead.org
> > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
> > > > > eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com
> > > > > ;
> > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞);
> > > > > Yong
> > > > > Wu
> > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT
> > > > > Chen
> > > > > (陳智迪); acourbot@chromium.org
> > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases
> > > > > upon
> > > > > vpu
> > > > > irq handling
> > > > > 
> > > > > 
> > > > > 
> > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns
> > > > > > > ERR
> > > > > > > pointer.
> > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > 
> > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > ---
> > > > > > >     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
> > > > > > > ++++++++
> > > > > > >     1 file changed, 8 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > vcodec/venc_vpu_if.c
> > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
> > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > >     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
> > > > > > > > fw_handler,
> > > > > > > 
> > > > > > >          msg->vpu_inst_addr);
> > > > > > >     
> > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > >     /* Firmware version field value is unspecified on
> > > > > > > MT8173.
> > > > > > > */
> > > > > > >     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
> > > > > > >     return 0;
> > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > handle_enc_encode_msg(struct
> > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > >     vpu->state = msg->state;
> > > > > > >     vpu->bs_size = msg->bs_size;
> > > > > > >     vpu->is_key_frm = msg->is_key_frm;
> > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > mtk_vcodec_err(vpu,
> > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > +       vpu->state ==
> > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > +return -EINVAL;
> > > > > > > +}
> > > > > > 
> > > > > > Hi Dafna,
> > > > > > 
> > > > > > This state check is useless, the enc result will check in
> > > > > > "vpu_enc_ipi_handler".
> > > > > > 
> > > > > 
> > > > > Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler
> > > > > only
> > > > > test the msg->status and I see that the states are not tested
> > > > > anywhere except of "skip" state in the h264 enc.
> > > > > 
> > > > > Can't there be a scenario where msg->status is ok but the
> > > > > state
> > > > > is error?
> > > > > I am testing the vp8 encoder on chromeos and at some point
> > > > > the
> > > > > encoder interrupts stop arriving so I try to figure out why
> > > > > and
> > > > > report any possible error.
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > >     return 0;
> > > > > > >     }
> > > > > > >     
> > > > > 
> > > > > ************* MEDIATEK Confidentiality Notice
> > > > > ******************** The
> > > > > information contained in this e-mail message (including any
> > > > > attachments) may be confidential, proprietary, privileged, or
> > > > > otherwise exempt from disclosure under applicable laws. It is
> > > > > intended
> > > > > to be conveyed only to the designated recipient(s). Any use,
> > > > > dissemination, distribution, printing, retaining or copying
> > > > > of
> > > > > this
> > > > > e-mail (including its
> > > > > attachments) by unintended recipient(s) is strictly
> > > > > prohibited
> > > > > and may
> > > > > be unlawful. If you are not an intended recipient of this e-
> > > > > mail,
> > > > > or
> > > > > believe that you have received this e-mail in error, please
> > > > > notify the
> > > > > sender immediately (by replying to this e-mail), delete any
> > > > > and
> > > > > all
> > > > > copies of this e-mail (including any attachments) from your
> > > > > system,
> > > > > and do not disclose the content of this e-mail to any other
> > > > > person. Thank you!
> > > > > 
> > 
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 03:38, Irui Wang wrote:
> > Hi,
> > 
> > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > Hi Dafna,
> > > > 
> > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > or  in
> > > > > > processing ?
> > > > > 
> > > > > The commands that I run is:
> > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/
> > > > > > > cros/
> > > > > > 
> > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > The command sometime succeed but when I run it sequentially
> > > > > > then at some point after few attempts I start to get those
> > > > > > timeout errors.
> > > > 
> > > > It seems mean VP8 encoding function OK, but failed sometimes,
> > > > did
> > > > you have check VENC clock info during encoding:
> > > > 
> > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > 
> > > > venc_sel   > it's H.264 clock
> > > > venclt_sel  > it's VP8 clock
> > > > 
> > > > the enable&prepare count is not 0 during encoding process.
> > > > 
> > > > Thanks
> > > > Best Regards
> > > > 
> > > > -----邮件原件-----
> > > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > > 发送时间: 2021年8月9日 16:27
> > > > 收件人: Irui Wang (王瑞)
> > > > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
> > > > support; Enric Balletbo i Serra
> > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases
> > > > upon
> > > > vpu irq handling
> > > > 
> > > > 
> > > > 
> > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > Hi Dafna,
> > > > > 
> > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > point
> > > > > > > the encoder interrupts stop arriving so I try to figure
> > > > > > > out
> > > > > > > why and report any possible error.
> > > > > 
> > > > > 1. Log shows wait IRQ timeout ?
> > > > 
> > > > Hi, yes, I get timeout when waiting to the encoder interrupt.
> > > > The
> > > > timeout is on vp8_enc_wait_venc_done
> > > > 
> > > > 
> > > > > 2. Always happened  issue ?  timeout at the beginning or  in
> > > > > processing ?
> > > > 
> > > > The commands that I run is:
> > > > 
> > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > *NV12Dmabuf*  --codec=vp8
> > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/v
> > > > ideo
> > > > /data/tulip2-320x180.yuv --disable_validator
> > > > 
> > > > The command sometime succeed but when I run it sequentially
> > > > then at
> > > > some point after few attempts I start to get those timeout
> > > > errors.
> > > > 
> > > > > 3. how about IRQ infos?
> > > > > cat /proc/interrupts | grep vcodec
> > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > 
> > > > > I was told you have  met another H.264 encoding failed
> > > > > before,
> > > > > did you find reasons about that ?
> > > > 
> > > > No,
> > > > But since I see that the google meetup uses the vp8 encoder I
> > > > decided to test the vp8 first.
> > > > 
> > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
> > > > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
> > > > > > irq_status=0 failed
> > > > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > > > venc_if_encode failed=-5
> > > 
> > > Hi,
> > > I test the driver on debian now, I stream several instances of
> > > vp8
> > > and h264 in parallel.
> > > I see that those errors always occur after an iommu page fault:
> > > 
> > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
> > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
> > > port=0
> > > layer=1 write
> > > [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
> > > [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> > > time=1000ms out 0 0!
> > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
> > > irq_status=0 failed
> > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > venc_if_encode
> > > failed=-5
> > > 
> > > I suspect that maybe this is because the iova of the
> > > working_buffers
> > > is handed to the vpu in the function vp8_enc_alloc_work_buf:
> > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > 
> > > Maybe the vpu keep writing to those addresses after they are
> > > already
> > > unmapped?
> > > 
> > > Thanks,
> > > Dafna
> > 
> > failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
> > there
> > any h264 encoding failed at that time? I have no ideas why these
> > errors
> > happened on your platform, but when we got the "iommu: fault", the
> > possible reason is related to power or clock.
> 
> Once the iommu fault fires, both encoders constantly fail and never
> recover
> (also not when starting new instance).
> 
> With the falut:
> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0
> layer=1 write
> 
> I looked at the iommu tracing log:
> 
>    gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU:
> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU:
> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> unmapped_size=20480
>    gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU:
> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU:
> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU:
> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU:
> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU:
> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU:
> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU:
> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> unmapped_size=4096
>       kworker/0:0-537     [000] d.h..   714.636191: io_page_fault:
> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001
> 
> (I changed the iommu map/unmap trace events to print the iova range)
> you can see the first line unmapping 00000000ebede000 which is the
> faulting iova.
> So it seems that the problem is due to a device trying to access an
> address that is already unmapped.
> This might be either the encoder or the vpu.
> Since the wb[i].iova is not reset when freeing the working buffers I
> suspect it might be the vpu device, what do you think?
> 
> Thanks,
> Dafna

vpu device won't access the address, the fault logs:
fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write

it's h264 encoder error when writing "RCPU" data address to encoder
hardware through iommu, but why unmap happended at this time? it seems
encoding process still going on....

> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > MT8173 latest VPUD firmware:
> > > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > > > 
> > > > 
> > > > I uses the latest firmware.
> > > > 
> > > > Thanks,
> > > > Dafna
> > > > 
> > > > > Thanks
> > > > > Best Regards
> > > > > 
> > > > > -----邮件原件-----
> > > > > 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> > > > > 发送时间: 2021年8月6日 15:49
> > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > linux-media@vger.kernel.org; 
> > > > > linux-mediatek@lists.infradead.org
> > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
> > > > > eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com
> > > > > ;
> > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞);
> > > > > Yong
> > > > > Wu
> > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT
> > > > > Chen
> > > > > (陳智迪); acourbot@chromium.org
> > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases
> > > > > upon
> > > > > vpu
> > > > > irq handling
> > > > > 
> > > > > 
> > > > > 
> > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
> > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns
> > > > > > > ERR
> > > > > > > pointer.
> > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > 
> > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > ---
> > > > > > >     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
> > > > > > > ++++++++
> > > > > > >     1 file changed, 8 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > vcodec/venc_vpu_if.c
> > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
> > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > >     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
> > > > > > > > fw_handler,
> > > > > > > 
> > > > > > >          msg->vpu_inst_addr);
> > > > > > >     
> > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > >     /* Firmware version field value is unspecified on
> > > > > > > MT8173.
> > > > > > > */
> > > > > > >     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
> > > > > > >     return 0;
> > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > handle_enc_encode_msg(struct
> > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > >     vpu->state = msg->state;
> > > > > > >     vpu->bs_size = msg->bs_size;
> > > > > > >     vpu->is_key_frm = msg->is_key_frm;
> > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > mtk_vcodec_err(vpu,
> > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > +       vpu->state ==
> > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > +return -EINVAL;
> > > > > > > +}
> > > > > > 
> > > > > > Hi Dafna,
> > > > > > 
> > > > > > This state check is useless, the enc result will check in
> > > > > > "vpu_enc_ipi_handler".
> > > > > > 
> > > > > 
> > > > > Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler
> > > > > only
> > > > > test the msg->status and I see that the states are not tested
> > > > > anywhere except of "skip" state in the h264 enc.
> > > > > 
> > > > > Can't there be a scenario where msg->status is ok but the
> > > > > state
> > > > > is error?
> > > > > I am testing the vp8 encoder on chromeos and at some point
> > > > > the
> > > > > encoder interrupts stop arriving so I try to figure out why
> > > > > and
> > > > > report any possible error.
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > >     return 0;
> > > > > > >     }
> > > > > > >     
> > > > > 
> > > > > ************* MEDIATEK Confidentiality Notice
> > > > > ******************** The
> > > > > information contained in this e-mail message (including any
> > > > > attachments) may be confidential, proprietary, privileged, or
> > > > > otherwise exempt from disclosure under applicable laws. It is
> > > > > intended
> > > > > to be conveyed only to the designated recipient(s). Any use,
> > > > > dissemination, distribution, printing, retaining or copying
> > > > > of
> > > > > this
> > > > > e-mail (including its
> > > > > attachments) by unintended recipient(s) is strictly
> > > > > prohibited
> > > > > and may
> > > > > be unlawful. If you are not an intended recipient of this e-
> > > > > mail,
> > > > > or
> > > > > believe that you have received this e-mail in error, please
> > > > > notify the
> > > > > sender immediately (by replying to this e-mail), delete any
> > > > > and
> > > > > all
> > > > > copies of this e-mail (including any attachments) from your
> > > > > system,
> > > > > and do not disclose the content of this e-mail to any other
> > > > > person. Thank you!
> > > > > 
> > 
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 11:16, Irui Wang wrote:
> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 03:38, Irui Wang wrote:
>>> Hi,
>>>
>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>> Hi Dafna,
>>>>>
>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>> or  in
>>>>>>> processing ?
>>>>>>
>>>>>> The commands that I run is:
>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/
>>>>>>>> cros/
>>>>>>>
>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>> The command sometime succeed but when I run it sequentially
>>>>>>> then at some point after few attempts I start to get those
>>>>>>> timeout errors.
>>>>>
>>>>> It seems mean VP8 encoding function OK, but failed sometimes,
>>>>> did
>>>>> you have check VENC clock info during encoding:
>>>>>
>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>
>>>>> venc_sel   > it's H.264 clock
>>>>> venclt_sel  > it's VP8 clock
>>>>>
>>>>> the enable&prepare count is not 0 during encoding process.
>>>>>
>>>>> Thanks
>>>>> Best Regards
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>>> 发送时间: 2021年8月9日 16:27
>>>>> 收件人: Irui Wang (王瑞)
>>>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
>>>>> support; Enric Balletbo i Serra
>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases
>>>>> upon
>>>>> vpu irq handling
>>>>>
>>>>>
>>>>>
>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>> Hi Dafna,
>>>>>>
>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>> point
>>>>>>>> the encoder interrupts stop arriving so I try to figure
>>>>>>>> out
>>>>>>>> why and report any possible error.
>>>>>>
>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>
>>>>> Hi, yes, I get timeout when waiting to the encoder interrupt.
>>>>> The
>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>
>>>>>
>>>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>>>> processing ?
>>>>>
>>>>> The commands that I run is:
>>>>>
>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>> *NV12Dmabuf*  --codec=vp8
>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/v
>>>>> ideo
>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>
>>>>> The command sometime succeed but when I run it sequentially
>>>>> then at
>>>>> some point after few attempts I start to get those timeout
>>>>> errors.
>>>>>
>>>>>> 3. how about IRQ infos?
>>>>>> cat /proc/interrupts | grep vcodec
>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>
>>>>>> I was told you have  met another H.264 encoding failed
>>>>>> before,
>>>>>> did you find reasons about that ?
>>>>>
>>>>> No,
>>>>> But since I see that the google meetup uses the vp8 encoder I
>>>>> decided to test the vp8 first.
>>>>>
>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
>>>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
>>>>>>> irq_status=0 failed
>>>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>>>> venc_if_encode failed=-5
>>>>
>>>> Hi,
>>>> I test the driver on debian now, I stream several instances of
>>>> vp8
>>>> and h264 in parallel.
>>>> I see that those errors always occur after an iommu page fault:
>>>>
>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
>>>> port=0
>>>> layer=1 write
>>>> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
>>>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>>>> time=1000ms out 0 0!
>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
>>>> irq_status=0 failed
>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>> venc_if_encode
>>>> failed=-5
>>>>
>>>> I suspect that maybe this is because the iova of the
>>>> working_buffers
>>>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>
>>>> Maybe the vpu keep writing to those addresses after they are
>>>> already
>>>> unmapped?
>>>>
>>>> Thanks,
>>>> Dafna
>>>
>>> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
>>> there
>>> any h264 encoding failed at that time? I have no ideas why these
>>> errors
>>> happened on your platform, but when we got the "iommu: fault", the
>>> possible reason is related to power or clock.
>>
>> Once the iommu fault fires, both encoders constantly fail and never
>> recover
>> (also not when starting new instance).
>>
>> With the falut:
>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0
>> layer=1 write
>>
>> I looked at the iommu tracing log:
>>
>>     gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU:
>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU:
>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>> unmapped_size=20480
>>     gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU:
>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU:
>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU:
>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU:
>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU:
>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU:
>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU:
>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>> unmapped_size=4096
>>        kworker/0:0-537     [000] d.h..   714.636191: io_page_fault:
>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001
>>
>> (I changed the iommu map/unmap trace events to print the iova range)
>> you can see the first line unmapping 00000000ebede000 which is the
>> faulting iova.
>> So it seems that the problem is due to a device trying to access an
>> address that is already unmapped.
>> This might be either the encoder or the vpu.
>> Since the wb[i].iova is not reset when freeing the working buffers I
>> suspect it might be the vpu device, what do you think?
>>
>> Thanks,
>> Dafna
> 
> vpu device won't access the address, the fault logs:


Looking at the line:
wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;

in both vp8 and h264 it seems that the codec drivers give the vpu access to the allocated iova address.
If the vpu doesn't access those addresses then what is the purpose of this line?


> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
> 
> it's h264 encoder error when writing "RCPU" data address to encoder
> hardware through iommu, but why unmap happended at this time? it seems
> encoding process still going on....

Why is it seems so?

> 
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> MT8173 latest VPUD firmware:
>>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>>>
>>>>>
>>>>> I uses the latest firmware.
>>>>>
>>>>> Thanks,
>>>>> Dafna
>>>>>
>>>>>> Thanks
>>>>>> Best Regards
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>> linux-media@vger.kernel.org;
>>>>>> linux-mediatek@lists.infradead.org
>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com
>>>>>> ;
>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞);
>>>>>> Yong
>>>>>> Wu
>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT
>>>>>> Chen
>>>>>> (陳智迪); acourbot@chromium.org
>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases
>>>>>> upon
>>>>>> vpu
>>>>>> irq handling
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns
>>>>>>>> ERR
>>>>>>>> pointer.
>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>
>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>> ---
>>>>>>>>      drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
>>>>>>>> ++++++++
>>>>>>>>      1 file changed, 8 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>      vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
>>>>>>>>> fw_handler,
>>>>>>>>
>>>>>>>>           msg->vpu_inst_addr);
>>>>>>>>      
>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>      /* Firmware version field value is unspecified on
>>>>>>>> MT8173.
>>>>>>>> */
>>>>>>>>      if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>>>>      return 0;
>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>      vpu->state = msg->state;
>>>>>>>>      vpu->bs_size = msg->bs_size;
>>>>>>>>      vpu->is_key_frm = msg->is_key_frm;
>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>> +       vpu->state ==
>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>> +return -EINVAL;
>>>>>>>> +}
>>>>>>>
>>>>>>> Hi Dafna,
>>>>>>>
>>>>>>> This state check is useless, the enc result will check in
>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>
>>>>>>
>>>>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler
>>>>>> only
>>>>>> test the msg->status and I see that the states are not tested
>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>
>>>>>> Can't there be a scenario where msg->status is ok but the
>>>>>> state
>>>>>> is error?
>>>>>> I am testing the vp8 encoder on chromeos and at some point
>>>>>> the
>>>>>> encoder interrupts stop arriving so I try to figure out why
>>>>>> and
>>>>>> report any possible error.
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>>      return 0;
>>>>>>>>      }
>>>>>>>>      
>>>>>>
>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>> ******************** The
>>>>>> information contained in this e-mail message (including any
>>>>>> attachments) may be confidential, proprietary, privileged, or
>>>>>> otherwise exempt from disclosure under applicable laws. It is
>>>>>> intended
>>>>>> to be conveyed only to the designated recipient(s). Any use,
>>>>>> dissemination, distribution, printing, retaining or copying
>>>>>> of
>>>>>> this
>>>>>> e-mail (including its
>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>> prohibited
>>>>>> and may
>>>>>> be unlawful. If you are not an intended recipient of this e-
>>>>>> mail,
>>>>>> or
>>>>>> believe that you have received this e-mail in error, please
>>>>>> notify the
>>>>>> sender immediately (by replying to this e-mail), delete any
>>>>>> and
>>>>>> all
>>>>>> copies of this e-mail (including any attachments) from your
>>>>>> system,
>>>>>> and do not disclose the content of this e-mail to any other
>>>>>> person. Thank you!
>>>>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 11:16, Irui Wang wrote:
> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 03:38, Irui Wang wrote:
>>> Hi,
>>>
>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>> Hi Dafna,
>>>>>
>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>> or  in
>>>>>>> processing ?
>>>>>>
>>>>>> The commands that I run is:
>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/
>>>>>>>> cros/
>>>>>>>
>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>> The command sometime succeed but when I run it sequentially
>>>>>>> then at some point after few attempts I start to get those
>>>>>>> timeout errors.
>>>>>
>>>>> It seems mean VP8 encoding function OK, but failed sometimes,
>>>>> did
>>>>> you have check VENC clock info during encoding:
>>>>>
>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>
>>>>> venc_sel   > it's H.264 clock
>>>>> venclt_sel  > it's VP8 clock
>>>>>
>>>>> the enable&prepare count is not 0 during encoding process.
>>>>>
>>>>> Thanks
>>>>> Best Regards
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>>> 发送时间: 2021年8月9日 16:27
>>>>> 收件人: Irui Wang (王瑞)
>>>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC
>>>>> support; Enric Balletbo i Serra
>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases
>>>>> upon
>>>>> vpu irq handling
>>>>>
>>>>>
>>>>>
>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>> Hi Dafna,
>>>>>>
>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>> point
>>>>>>>> the encoder interrupts stop arriving so I try to figure
>>>>>>>> out
>>>>>>>> why and report any possible error.
>>>>>>
>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>
>>>>> Hi, yes, I get timeout when waiting to the encoder interrupt.
>>>>> The
>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>
>>>>>
>>>>>> 2. Always happened  issue ?  timeout at the beginning or  in
>>>>>> processing ?
>>>>>
>>>>> The commands that I run is:
>>>>>
>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>> *NV12Dmabuf*  --codec=vp8
>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/v
>>>>> ideo
>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>
>>>>> The command sometime succeed but when I run it sequentially
>>>>> then at
>>>>> some point after few attempts I start to get those timeout
>>>>> errors.
>>>>>
>>>>>> 3. how about IRQ infos?
>>>>>> cat /proc/interrupts | grep vcodec
>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>
>>>>>> I was told you have  met another H.264 encoding failed
>>>>>> before,
>>>>>> did you find reasons about that ?
>>>>>
>>>>> No,
>>>>> But since I see that the google meetup uses the vp8 encoder I
>>>>> decided to test the vp8 first.
>>>>>
>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1,
>>>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame()
>>>>>>> irq_status=0 failed
>>>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>>>> venc_if_encode failed=-5
>>>>
>>>> Hi,
>>>> I test the driver on debian now, I stream several instances of
>>>> vp8
>>>> and h264 in parallel.
>>>> I see that those errors always occur after an iommu page fault:
>>>>
>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-iommu
>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
>>>> port=0
>>>> layer=1 write
>>>> [ 5744.204964] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32:
>>>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>>>> time=1000ms out 0 0!
>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]: vp8_enc_encode_frame()
>>>> irq_status=0 failed
>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>> venc_if_encode
>>>> failed=-5
>>>>
>>>> I suspect that maybe this is because the iova of the
>>>> working_buffers
>>>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>
>>>> Maybe the vpu keep writing to those addresses after they are
>>>> already
>>>> unmapped?
>>>>
>>>> Thanks,
>>>> Dafna
>>>
>>> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
>>> there
>>> any h264 encoding failed at that time? I have no ideas why these
>>> errors
>>> happened on your platform, but when we got the "iommu: fault", the
>>> possible reason is related to power or clock.
>>
>> Once the iommu fault fires, both encoders constantly fail and never
>> recover
>> (also not when starting new instance).
>>
>> With the falut:
>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0
>> layer=1 write
>>
>> I looked at the iommu tracing log:
>>
>>     gst-launch-1.0-606     [000] .....   714.634398: unmap: IOMMU:
>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-606     [000] .....   714.634417: unmap: IOMMU:
>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>> unmapped_size=20480
>>     gst-launch-1.0-606     [000] .....   714.634435: unmap: IOMMU:
>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-606     [000] .N...   714.634891: unmap: IOMMU:
>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-606     [000] .N...   714.635481: unmap: IOMMU:
>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-606     [000] .....   714.635934: unmap: IOMMU:
>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-606     [000] .....   714.636041: unmap: IOMMU:
>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-606     [000] .....   714.636056: unmap: IOMMU:
>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-606     [000] .....   714.636069: unmap: IOMMU:
>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>> unmapped_size=4096
>>        kworker/0:0-537     [000] d.h..   714.636191: io_page_fault:
>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003 flags=0x0001
>>
>> (I changed the iommu map/unmap trace events to print the iova range)
>> you can see the first line unmapping 00000000ebede000 which is the
>> faulting iova.
>> So it seems that the problem is due to a device trying to access an
>> address that is already unmapped.
>> This might be either the encoder or the vpu.
>> Since the wb[i].iova is not reset when freeing the working buffers I
>> suspect it might be the vpu device, what do you think?
>>
>> Thanks,
>> Dafna
> 
> vpu device won't access the address, the fault logs:


Looking at the line:
wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;

in both vp8 and h264 it seems that the codec drivers give the vpu access to the allocated iova address.
If the vpu doesn't access those addresses then what is the purpose of this line?


> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
> 
> it's h264 encoder error when writing "RCPU" data address to encoder
> hardware through iommu, but why unmap happended at this time? it seems
> encoding process still going on....

Why is it seems so?

> 
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> MT8173 latest VPUD firmware:
>>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>>>
>>>>>
>>>>> I uses the latest firmware.
>>>>>
>>>>> Thanks,
>>>>> Dafna
>>>>>
>>>>>> Thanks
>>>>>> Best Regards
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>> linux-media@vger.kernel.org;
>>>>>> linux-mediatek@lists.infradead.org
>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com
>>>>>> ;
>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞);
>>>>>> Yong
>>>>>> Wu
>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT
>>>>>> Chen
>>>>>> (陳智迪); acourbot@chromium.org
>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases
>>>>>> upon
>>>>>> vpu
>>>>>> irq handling
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns
>>>>>>>> ERR
>>>>>>>> pointer.
>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>
>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>> ---
>>>>>>>>      drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8
>>>>>>>> ++++++++
>>>>>>>>      1 file changed, 8 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>      vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev-
>>>>>>>>> fw_handler,
>>>>>>>>
>>>>>>>>           msg->vpu_inst_addr);
>>>>>>>>      
>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>      /* Firmware version field value is unspecified on
>>>>>>>> MT8173.
>>>>>>>> */
>>>>>>>>      if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>>>>      return 0;
>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>      vpu->state = msg->state;
>>>>>>>>      vpu->bs_size = msg->bs_size;
>>>>>>>>      vpu->is_key_frm = msg->is_key_frm;
>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>> +       vpu->state ==
>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>> +return -EINVAL;
>>>>>>>> +}
>>>>>>>
>>>>>>> Hi Dafna,
>>>>>>>
>>>>>>> This state check is useless, the enc result will check in
>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>
>>>>>>
>>>>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler
>>>>>> only
>>>>>> test the msg->status and I see that the states are not tested
>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>
>>>>>> Can't there be a scenario where msg->status is ok but the
>>>>>> state
>>>>>> is error?
>>>>>> I am testing the vp8 encoder on chromeos and at some point
>>>>>> the
>>>>>> encoder interrupts stop arriving so I try to figure out why
>>>>>> and
>>>>>> report any possible error.
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>>      return 0;
>>>>>>>>      }
>>>>>>>>      
>>>>>>
>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>> ******************** The
>>>>>> information contained in this e-mail message (including any
>>>>>> attachments) may be confidential, proprietary, privileged, or
>>>>>> otherwise exempt from disclosure under applicable laws. It is
>>>>>> intended
>>>>>> to be conveyed only to the designated recipient(s). Any use,
>>>>>> dissemination, distribution, printing, retaining or copying
>>>>>> of
>>>>>> this
>>>>>> e-mail (including its
>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>> prohibited
>>>>>> and may
>>>>>> be unlawful. If you are not an intended recipient of this e-
>>>>>> mail,
>>>>>> or
>>>>>> believe that you have received this e-mail in error, please
>>>>>> notify the
>>>>>> sender immediately (by replying to this e-mail), delete any
>>>>>> and
>>>>>> all
>>>>>> copies of this e-mail (including any attachments) from your
>>>>>> system,
>>>>>> and do not disclose the content of this e-mail to any other
>>>>>> person. Thank you!
>>>>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 11:16, Irui Wang wrote:
> > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 03:38, Irui Wang wrote:
> > > > Hi,
> > > > 
> > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > Hi Dafna,
> > > > > > 
> > > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > > or  in
> > > > > > > > processing ?
> > > > > > > 
> > > > > > > The commands that I run is:
> > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bund
> > > > > > > > > les/
> > > > > > > > > cros/
> > > > > > > > 
> > > > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > > > The command sometime succeed but when I run it
> > > > > > > > sequentially
> > > > > > > > then at some point after few attempts I start to get
> > > > > > > > those
> > > > > > > > timeout errors.
> > > > > > 
> > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > sometimes,
> > > > > > did
> > > > > > you have check VENC clock info during encoding:
> > > > > > 
> > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > 
> > > > > > venc_sel   > it's H.264 clock
> > > > > > venclt_sel  > it's VP8 clock
> > > > > > 
> > > > > > the enable&prepare count is not 0 during encoding process.
> > > > > > 
> > > > > > Thanks
> > > > > > Best Regards
> > > > > > 
> > > > > > -----邮件原件-----
> > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > dafna.hirschfeld@collabora.com]
> > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > 收件人: Irui Wang (王瑞)
> > > > > > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek
> > > > > > SoC
> > > > > > support; Enric Balletbo i Serra
> > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > cases
> > > > > > upon
> > > > > > vpu irq handling
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > Hi Dafna,
> > > > > > > 
> > > > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > > > point
> > > > > > > > > the encoder interrupts stop arriving so I try to
> > > > > > > > > figure
> > > > > > > > > out
> > > > > > > > > why and report any possible error.
> > > > > > > 
> > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > 
> > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > interrupt.
> > > > > > The
> > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > 
> > > > > > 
> > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > or  in
> > > > > > > processing ?
> > > > > > 
> > > > > > The commands that I run is:
> > > > > > 
> > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cr
> > > > > > os/v
> > > > > > ideo
> > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > 
> > > > > > The command sometime succeed but when I run it sequentially
> > > > > > then at
> > > > > > some point after few attempts I start to get those timeout
> > > > > > errors.
> > > > > > 
> > > > > > > 3. how about IRQ infos?
> > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > 
> > > > > > > I was told you have  met another H.264 encoding failed
> > > > > > > before,
> > > > > > > did you find reasons about that ?
> > > > > > 
> > > > > > No,
> > > > > > But since I see that the google meetup uses the vp8 encoder
> > > > > > I
> > > > > > decided to test the vp8 first.
> > > > > > 
> > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
> > > > > > > > cmd=1,
> > > > > > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > h264_encode_frame()
> > > > > > > > irq_status=0 failed
> > > > > > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > > > > > venc_if_encode failed=-5
> > > > > 
> > > > > Hi,
> > > > > I test the driver on debian now, I stream several instances
> > > > > of
> > > > > vp8
> > > > > and h264 in parallel.
> > > > > I see that those errors always occur after an iommu page
> > > > > fault:
> > > > > 
> > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
> > > > > iommu
> > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
> > > > > port=0
> > > > > layer=1 write
> > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> > > > > time=1000ms out 0 0!
> > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > vp8_enc_encode_frame()
> > > > > irq_status=0 failed
> > > > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > > > venc_if_encode
> > > > > failed=-5
> > > > > 
> > > > > I suspect that maybe this is because the iova of the
> > > > > working_buffers
> > > > > is handed to the vpu in the function vp8_enc_alloc_work_buf:
> > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > 
> > > > > Maybe the vpu keep writing to those addresses after they are
> > > > > already
> > > > > unmapped?
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > 
> > > > failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
> > > > there
> > > > any h264 encoding failed at that time? I have no ideas why
> > > > these
> > > > errors
> > > > happened on your platform, but when we got the "iommu: fault",
> > > > the
> > > > possible reason is related to power or clock.
> > > 
> > > Once the iommu fault fires, both encoders constantly fail and
> > > never
> > > recover
> > > (also not when starting new instance).
> > > 
> > > With the falut:
> > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
> > > port=0
> > > layer=1 write
> > > 
> > > I looked at the iommu tracing log:
> > > 
> > >     gst-launch-1.0-606     [000] .....   714.634398: unmap:
> > > IOMMU:
> > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-606     [000] .....   714.634417: unmap:
> > > IOMMU:
> > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > unmapped_size=20480
> > >     gst-launch-1.0-606     [000] .....   714.634435: unmap:
> > > IOMMU:
> > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-606     [000] .N...   714.634891: unmap:
> > > IOMMU:
> > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-606     [000] .N...   714.635481: unmap:
> > > IOMMU:
> > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-606     [000] .....   714.635934: unmap:
> > > IOMMU:
> > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-606     [000] .....   714.636041: unmap:
> > > IOMMU:
> > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-606     [000] .....   714.636056: unmap:
> > > IOMMU:
> > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-606     [000] .....   714.636069: unmap:
> > > IOMMU:
> > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > unmapped_size=4096
> > >        kworker/0:0-537     [000] d.h..   714.636191:
> > > io_page_fault:
> > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > flags=0x0001
> > > 
> > > (I changed the iommu map/unmap trace events to print the iova
> > > range)
> > > you can see the first line unmapping 00000000ebede000 which is
> > > the
> > > faulting iova.
> > > So it seems that the problem is due to a device trying to access
> > > an
> > > address that is already unmapped.
> > > This might be either the encoder or the vpu.
> > > Since the wb[i].iova is not reset when freeing the working
> > > buffers I
> > > suspect it might be the vpu device, what do you think?
> > > 
> > > Thanks,
> > > Dafna
> > 
> > vpu device won't access the address, the fault logs:
> 
> 
> Looking at the line:
> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> 
> in both vp8 and h264 it seems that the codec drivers give the vpu
> access to the allocated iova address.
> If the vpu doesn't access those addresses then what is the purpose of
> this line?
> 
"wb" is a shared buffer between AP-kernel and VPU firmware, to store
these encoder working buffers informations, the architecture like this:
1. VPU firmware will set working buffers informations(size, iova(is 0
now));
2. AP-kernel allocate these working buffers and get a truly
memory(iova), so VPU firmware can get these wbs' iova after allocate
done.
3. when encoding, these iova will set to encoder hardware in VPU
firmware.
4. encoder hardware can get the data from these "iova" to do encoding.

I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver ?

> 
> > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
> > 
> > it's h264 encoder error when writing "RCPU" data address to encoder
> > hardware through iommu, but why unmap happended at this time? it
> > seems
> > encoding process still going on....
> 
> Why is it seems so?

the fault means errors happended while reading prepared encode data, so
I think encoding is still going on.
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > MT8173 latest VPUD firmware:
> > > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > > > > > 
> > > > > > 
> > > > > > I uses the latest firmware.
> > > > > > 
> > > > > > Thanks,
> > > > > > Dafna
> > > > > > 
> > > > > > > Thanks
> > > > > > > Best Regards
> > > > > > > 
> > > > > > > -----邮件原件-----
> > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > > > linux-media@vger.kernel.org;
> > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
> > > > > > > (林慧珊);
> > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广); 
> > > > > > > kernel@collabora.com
> > > > > > > ;
> > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
> > > > > > > (董云飞);
> > > > > > > Yong
> > > > > > > Wu
> > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
> > > > > > > Andrew-CT
> > > > > > > Chen
> > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > > cases
> > > > > > > upon
> > > > > > > vpu
> > > > > > > irq handling
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
> > > > > > > > wrote:
> > > > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr
> > > > > > > > > returns
> > > > > > > > > ERR
> > > > > > > > > pointer.
> > > > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > ---
> > > > > > > > >      drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > | 8
> > > > > > > > > ++++++++
> > > > > > > > >      1 file changed, 8 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > >      vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx-
> > > > > > > > > >dev-
> > > > > > > > > > fw_handler,
> > > > > > > > > 
> > > > > > > > >           msg->vpu_inst_addr);
> > > > > > > > >      
> > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > >      /* Firmware version field value is unspecified
> > > > > > > > > on
> > > > > > > > > MT8173.
> > > > > > > > > */
> > > > > > > > >      if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > MTK_MT8173)
> > > > > > > > >      return 0;
> > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > >      vpu->state = msg->state;
> > > > > > > > >      vpu->bs_size = msg->bs_size;
> > > > > > > > >      vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > +       vpu->state ==
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > > > +return -EINVAL;
> > > > > > > > > +}
> > > > > > > > 
> > > > > > > > Hi Dafna,
> > > > > > > > 
> > > > > > > > This state check is useless, the enc result will check
> > > > > > > > in
> > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > 
> > > > > > > 
> > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > vpu_enc_ipi_handler
> > > > > > > only
> > > > > > > test the msg->status and I see that the states are not
> > > > > > > tested
> > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > 
> > > > > > > Can't there be a scenario where msg->status is ok but the
> > > > > > > state
> > > > > > > is error?
> > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > point
> > > > > > > the
> > > > > > > encoder interrupts stop arriving so I try to figure out
> > > > > > > why
> > > > > > > and
> > > > > > > report any possible error.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > > 
> > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > >      return 0;
> > > > > > > > >      }
> > > > > > > > >      
> > > > > > > 
> > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > ******************** The
> > > > > > > information contained in this e-mail message (including
> > > > > > > any
> > > > > > > attachments) may be confidential, proprietary,
> > > > > > > privileged, or
> > > > > > > otherwise exempt from disclosure under applicable laws.
> > > > > > > It is
> > > > > > > intended
> > > > > > > to be conveyed only to the designated recipient(s). Any
> > > > > > > use,
> > > > > > > dissemination, distribution, printing, retaining or
> > > > > > > copying
> > > > > > > of
> > > > > > > this
> > > > > > > e-mail (including its
> > > > > > > attachments) by unintended recipient(s) is strictly
> > > > > > > prohibited
> > > > > > > and may
> > > > > > > be unlawful. If you are not an intended recipient of this
> > > > > > > e-
> > > > > > > mail,
> > > > > > > or
> > > > > > > believe that you have received this e-mail in error,
> > > > > > > please
> > > > > > > notify the
> > > > > > > sender immediately (by replying to this e-mail), delete
> > > > > > > any
> > > > > > > and
> > > > > > > all
> > > > > > > copies of this e-mail (including any attachments) from
> > > > > > > your
> > > > > > > system,
> > > > > > > and do not disclose the content of this e-mail to any
> > > > > > > other
> > > > > > > person. Thank you!
> > > > > > > 
> > > > 
> > > > _______________________________________________
> > > > Linux-mediatek mailing list
> > > > Linux-mediatek@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 11:16, Irui Wang wrote:
> > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 03:38, Irui Wang wrote:
> > > > Hi,
> > > > 
> > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > Hi Dafna,
> > > > > > 
> > > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > > or  in
> > > > > > > > processing ?
> > > > > > > 
> > > > > > > The commands that I run is:
> > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bund
> > > > > > > > > les/
> > > > > > > > > cros/
> > > > > > > > 
> > > > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > > > The command sometime succeed but when I run it
> > > > > > > > sequentially
> > > > > > > > then at some point after few attempts I start to get
> > > > > > > > those
> > > > > > > > timeout errors.
> > > > > > 
> > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > sometimes,
> > > > > > did
> > > > > > you have check VENC clock info during encoding:
> > > > > > 
> > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > 
> > > > > > venc_sel   > it's H.264 clock
> > > > > > venclt_sel  > it's VP8 clock
> > > > > > 
> > > > > > the enable&prepare count is not 0 during encoding process.
> > > > > > 
> > > > > > Thanks
> > > > > > Best Regards
> > > > > > 
> > > > > > -----邮件原件-----
> > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > dafna.hirschfeld@collabora.com]
> > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > 收件人: Irui Wang (王瑞)
> > > > > > 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek
> > > > > > SoC
> > > > > > support; Enric Balletbo i Serra
> > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > cases
> > > > > > upon
> > > > > > vpu irq handling
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > Hi Dafna,
> > > > > > > 
> > > > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > > > point
> > > > > > > > > the encoder interrupts stop arriving so I try to
> > > > > > > > > figure
> > > > > > > > > out
> > > > > > > > > why and report any possible error.
> > > > > > > 
> > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > 
> > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > interrupt.
> > > > > > The
> > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > 
> > > > > > 
> > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > or  in
> > > > > > > processing ?
> > > > > > 
> > > > > > The commands that I run is:
> > > > > > 
> > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundles/cr
> > > > > > os/v
> > > > > > ideo
> > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > 
> > > > > > The command sometime succeed but when I run it sequentially
> > > > > > then at
> > > > > > some point after few attempts I start to get those timeout
> > > > > > errors.
> > > > > > 
> > > > > > > 3. how about IRQ infos?
> > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > 
> > > > > > > I was told you have  met another H.264 encoding failed
> > > > > > > before,
> > > > > > > did you find reasons about that ?
> > > > > > 
> > > > > > No,
> > > > > > But since I see that the google meetup uses the vp8 encoder
> > > > > > I
> > > > > > decided to test the vp8 first.
> > > > > > 
> > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
> > > > > > > > cmd=1,
> > > > > > > > wait_event_interruptible_timeout time=1000ms out 0 0!
> > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > h264_encode_frame()
> > > > > > > > irq_status=0 failed
> > > > > > > > [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
> > > > > > > > venc_if_encode failed=-5
> > > > > 
> > > > > Hi,
> > > > > I test the driver on debian now, I stream several instances
> > > > > of
> > > > > vp8
> > > > > and h264 in parallel.
> > > > > I see that those errors always occur after an iommu page
> > > > > fault:
> > > > > 
> > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
> > > > > iommu
> > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
> > > > > port=0
> > > > > layer=1 write
> > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
> > > > > time=1000ms out 0 0!
> > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > vp8_enc_encode_frame()
> > > > > irq_status=0 failed
> > > > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > > > venc_if_encode
> > > > > failed=-5
> > > > > 
> > > > > I suspect that maybe this is because the iova of the
> > > > > working_buffers
> > > > > is handed to the vpu in the function vp8_enc_alloc_work_buf:
> > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > 
> > > > > Maybe the vpu keep writing to those addresses after they are
> > > > > already
> > > > > unmapped?
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > 
> > > > failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
> > > > there
> > > > any h264 encoding failed at that time? I have no ideas why
> > > > these
> > > > errors
> > > > happened on your platform, but when we got the "iommu: fault",
> > > > the
> > > > possible reason is related to power or clock.
> > > 
> > > Once the iommu fault fires, both encoders constantly fail and
> > > never
> > > recover
> > > (also not when starting new instance).
> > > 
> > > With the falut:
> > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
> > > port=0
> > > layer=1 write
> > > 
> > > I looked at the iommu tracing log:
> > > 
> > >     gst-launch-1.0-606     [000] .....   714.634398: unmap:
> > > IOMMU:
> > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-606     [000] .....   714.634417: unmap:
> > > IOMMU:
> > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > unmapped_size=20480
> > >     gst-launch-1.0-606     [000] .....   714.634435: unmap:
> > > IOMMU:
> > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-606     [000] .N...   714.634891: unmap:
> > > IOMMU:
> > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-606     [000] .N...   714.635481: unmap:
> > > IOMMU:
> > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-606     [000] .....   714.635934: unmap:
> > > IOMMU:
> > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-606     [000] .....   714.636041: unmap:
> > > IOMMU:
> > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-606     [000] .....   714.636056: unmap:
> > > IOMMU:
> > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-606     [000] .....   714.636069: unmap:
> > > IOMMU:
> > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > unmapped_size=4096
> > >        kworker/0:0-537     [000] d.h..   714.636191:
> > > io_page_fault:
> > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > flags=0x0001
> > > 
> > > (I changed the iommu map/unmap trace events to print the iova
> > > range)
> > > you can see the first line unmapping 00000000ebede000 which is
> > > the
> > > faulting iova.
> > > So it seems that the problem is due to a device trying to access
> > > an
> > > address that is already unmapped.
> > > This might be either the encoder or the vpu.
> > > Since the wb[i].iova is not reset when freeing the working
> > > buffers I
> > > suspect it might be the vpu device, what do you think?
> > > 
> > > Thanks,
> > > Dafna
> > 
> > vpu device won't access the address, the fault logs:
> 
> 
> Looking at the line:
> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> 
> in both vp8 and h264 it seems that the codec drivers give the vpu
> access to the allocated iova address.
> If the vpu doesn't access those addresses then what is the purpose of
> this line?
> 
"wb" is a shared buffer between AP-kernel and VPU firmware, to store
these encoder working buffers informations, the architecture like this:
1. VPU firmware will set working buffers informations(size, iova(is 0
now));
2. AP-kernel allocate these working buffers and get a truly
memory(iova), so VPU firmware can get these wbs' iova after allocate
done.
3. when encoding, these iova will set to encoder hardware in VPU
firmware.
4. encoder hardware can get the data from these "iova" to do encoding.

I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver ?

> 
> > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
> > 
> > it's h264 encoder error when writing "RCPU" data address to encoder
> > hardware through iommu, but why unmap happended at this time? it
> > seems
> > encoding process still going on....
> 
> Why is it seems so?

the fault means errors happended while reading prepared encode data, so
I think encoding is still going on.
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > MT8173 latest VPUD firmware:
> > > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
> > > > > > > 
> > > > > > 
> > > > > > I uses the latest firmware.
> > > > > > 
> > > > > > Thanks,
> > > > > > Dafna
> > > > > > 
> > > > > > > Thanks
> > > > > > > Best Regards
> > > > > > > 
> > > > > > > -----邮件原件-----
> > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > > > linux-media@vger.kernel.org;
> > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
> > > > > > > (林慧珊);
> > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广); 
> > > > > > > kernel@collabora.com
> > > > > > > ;
> > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
> > > > > > > (董云飞);
> > > > > > > Yong
> > > > > > > Wu
> > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
> > > > > > > Andrew-CT
> > > > > > > Chen
> > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > > cases
> > > > > > > upon
> > > > > > > vpu
> > > > > > > irq handling
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
> > > > > > > > wrote:
> > > > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr
> > > > > > > > > returns
> > > > > > > > > ERR
> > > > > > > > > pointer.
> > > > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > ---
> > > > > > > > >      drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > | 8
> > > > > > > > > ++++++++
> > > > > > > > >      1 file changed, 8 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > >      vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx-
> > > > > > > > > >dev-
> > > > > > > > > > fw_handler,
> > > > > > > > > 
> > > > > > > > >           msg->vpu_inst_addr);
> > > > > > > > >      
> > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > >      /* Firmware version field value is unspecified
> > > > > > > > > on
> > > > > > > > > MT8173.
> > > > > > > > > */
> > > > > > > > >      if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > MTK_MT8173)
> > > > > > > > >      return 0;
> > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > >      vpu->state = msg->state;
> > > > > > > > >      vpu->bs_size = msg->bs_size;
> > > > > > > > >      vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > +       vpu->state ==
> > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > > > +return -EINVAL;
> > > > > > > > > +}
> > > > > > > > 
> > > > > > > > Hi Dafna,
> > > > > > > > 
> > > > > > > > This state check is useless, the enc result will check
> > > > > > > > in
> > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > 
> > > > > > > 
> > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > vpu_enc_ipi_handler
> > > > > > > only
> > > > > > > test the msg->status and I see that the states are not
> > > > > > > tested
> > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > 
> > > > > > > Can't there be a scenario where msg->status is ok but the
> > > > > > > state
> > > > > > > is error?
> > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > point
> > > > > > > the
> > > > > > > encoder interrupts stop arriving so I try to figure out
> > > > > > > why
> > > > > > > and
> > > > > > > report any possible error.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > > 
> > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > >      return 0;
> > > > > > > > >      }
> > > > > > > > >      
> > > > > > > 
> > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > ******************** The
> > > > > > > information contained in this e-mail message (including
> > > > > > > any
> > > > > > > attachments) may be confidential, proprietary,
> > > > > > > privileged, or
> > > > > > > otherwise exempt from disclosure under applicable laws.
> > > > > > > It is
> > > > > > > intended
> > > > > > > to be conveyed only to the designated recipient(s). Any
> > > > > > > use,
> > > > > > > dissemination, distribution, printing, retaining or
> > > > > > > copying
> > > > > > > of
> > > > > > > this
> > > > > > > e-mail (including its
> > > > > > > attachments) by unintended recipient(s) is strictly
> > > > > > > prohibited
> > > > > > > and may
> > > > > > > be unlawful. If you are not an intended recipient of this
> > > > > > > e-
> > > > > > > mail,
> > > > > > > or
> > > > > > > believe that you have received this e-mail in error,
> > > > > > > please
> > > > > > > notify the
> > > > > > > sender immediately (by replying to this e-mail), delete
> > > > > > > any
> > > > > > > and
> > > > > > > all
> > > > > > > copies of this e-mail (including any attachments) from
> > > > > > > your
> > > > > > > system,
> > > > > > > and do not disclose the content of this e-mail to any
> > > > > > > other
> > > > > > > person. Thank you!
> > > > > > > 
> > > > 
> > > > _______________________________________________
> > > > Linux-mediatek mailing list
> > > > Linux-mediatek@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 11:51, Irui Wang wrote:
> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 11:16, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>> Hi Dafna,
>>>>>>>
>>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>>> or  in
>>>>>>>>> processing ?
>>>>>>>>
>>>>>>>> The commands that I run is:
>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bund
>>>>>>>>>> les/
>>>>>>>>>> cros/
>>>>>>>>>
>>>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>> sequentially
>>>>>>>>> then at some point after few attempts I start to get
>>>>>>>>> those
>>>>>>>>> timeout errors.
>>>>>>>
>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>> sometimes,
>>>>>>> did
>>>>>>> you have check VENC clock info during encoding:
>>>>>>>
>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>
>>>>>>> venc_sel   > it's H.264 clock
>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>
>>>>>>> the enable&prepare count is not 0 during encoding process.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Best Regards
>>>>>>>
>>>>>>> -----邮件原件-----
>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek
>>>>>>> SoC
>>>>>>> support; Enric Balletbo i Serra
>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>> cases
>>>>>>> upon
>>>>>>> vpu irq handling
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>> Hi Dafna,
>>>>>>>>
>>>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>>>> point
>>>>>>>>>> the encoder interrupts stop arriving so I try to
>>>>>>>>>> figure
>>>>>>>>>> out
>>>>>>>>>> why and report any possible error.
>>>>>>>>
>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>
>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>> interrupt.
>>>>>>> The
>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>
>>>>>>>
>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>> or  in
>>>>>>>> processing ?
>>>>>>>
>>>>>>> The commands that I run is:
>>>>>>>
>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cr
>>>>>>> os/v
>>>>>>> ideo
>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>
>>>>>>> The command sometime succeed but when I run it sequentially
>>>>>>> then at
>>>>>>> some point after few attempts I start to get those timeout
>>>>>>> errors.
>>>>>>>
>>>>>>>> 3. how about IRQ infos?
>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>
>>>>>>>> I was told you have  met another H.264 encoding failed
>>>>>>>> before,
>>>>>>>> did you find reasons about that ?
>>>>>>>
>>>>>>> No,
>>>>>>> But since I see that the google meetup uses the vp8 encoder
>>>>>>> I
>>>>>>> decided to test the vp8 first.
>>>>>>>
>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
>>>>>>>>> cmd=1,
>>>>>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>> h264_encode_frame()
>>>>>>>>> irq_status=0 failed
>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>>>>>> venc_if_encode failed=-5
>>>>>>
>>>>>> Hi,
>>>>>> I test the driver on debian now, I stream several instances
>>>>>> of
>>>>>> vp8
>>>>>> and h264 in parallel.
>>>>>> I see that those errors always occur after an iommu page
>>>>>> fault:
>>>>>>
>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
>>>>>> iommu
>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
>>>>>> port=0
>>>>>> layer=1 write
>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>>>>>> time=1000ms out 0 0!
>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>> vp8_enc_encode_frame()
>>>>>> irq_status=0 failed
>>>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>>>> venc_if_encode
>>>>>> failed=-5
>>>>>>
>>>>>> I suspect that maybe this is because the iova of the
>>>>>> working_buffers
>>>>>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>
>>>>>> Maybe the vpu keep writing to those addresses after they are
>>>>>> already
>>>>>> unmapped?
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>
>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
>>>>> there
>>>>> any h264 encoding failed at that time? I have no ideas why
>>>>> these
>>>>> errors
>>>>> happened on your platform, but when we got the "iommu: fault",
>>>>> the
>>>>> possible reason is related to power or clock.
>>>>
>>>> Once the iommu fault fires, both encoders constantly fail and
>>>> never
>>>> recover
>>>> (also not when starting new instance).
>>>>
>>>> With the falut:
>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
>>>> port=0
>>>> layer=1 write
>>>>
>>>> I looked at the iommu tracing log:
>>>>
>>>>      gst-launch-1.0-606     [000] .....   714.634398: unmap:
>>>> IOMMU:
>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-606     [000] .....   714.634417: unmap:
>>>> IOMMU:
>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>> unmapped_size=20480
>>>>      gst-launch-1.0-606     [000] .....   714.634435: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-606     [000] .N...   714.634891: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-606     [000] .N...   714.635481: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-606     [000] .....   714.635934: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-606     [000] .....   714.636041: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-606     [000] .....   714.636056: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-606     [000] .....   714.636069: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>> unmapped_size=4096
>>>>         kworker/0:0-537     [000] d.h..   714.636191:
>>>> io_page_fault:
>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>> flags=0x0001
>>>>
>>>> (I changed the iommu map/unmap trace events to print the iova
>>>> range)
>>>> you can see the first line unmapping 00000000ebede000 which is
>>>> the
>>>> faulting iova.
>>>> So it seems that the problem is due to a device trying to access
>>>> an
>>>> address that is already unmapped.
>>>> This might be either the encoder or the vpu.
>>>> Since the wb[i].iova is not reset when freeing the working
>>>> buffers I
>>>> suspect it might be the vpu device, what do you think?
>>>>
>>>> Thanks,
>>>> Dafna
>>>
>>> vpu device won't access the address, the fault logs:
>>
>>
>> Looking at the line:
>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>
>> in both vp8 and h264 it seems that the codec drivers give the vpu
>> access to the allocated iova address.
>> If the vpu doesn't access those addresses then what is the purpose of
>> this line?
>>
> "wb" is a shared buffer between AP-kernel and VPU firmware, to store
> these encoder working buffers informations, the architecture like this:
> 1. VPU firmware will set working buffers informations(size, iova(is 0
> now));
> 2. AP-kernel allocate these working buffers and get a truly
> memory(iova), so VPU firmware can get these wbs' iova after allocate
> done.
> 3. when encoding, these iova will set to encoder hardware in VPU
> firmware
> 4. encoder hardware can get the data from these "iova" to do encoding.

ok, thanks for the explanation, so vpu firmware only hand the iova adresses further to the encoder hw but never access them itself?

> 
> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver ?

yes,

> 
>>
>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
>>>
>>> it's h264 encoder error when writing "RCPU" data address to encoder
>>> hardware through iommu, but why unmap happended at this time? it
>>> seems
>>> encoding process still going on....
>>
>> Why is it seems so?
> 
> the fault means errors happended while reading prepared encode data, so
> I think encoding is still going on.

I added more trace_printk debug, adding log before and after the working buffers are freed: see 'BEFORE/AFTER' log

   gst-launch-1.0-590     [000] .....   353.825276: h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
   gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU: iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096 unmapped_size=4096
   gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU: iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480 unmapped_size=20480
   gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU: iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU: iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU: iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU: iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU: iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536 unmapped_size=65536
   gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU: iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536 unmapped_size=65536
   gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU: iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096 unmapped_size=4096
   gst-launch-1.0-590     [000] .....   353.826515: h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
      kworker/0:3-67      [000] d.h..   353.826631: io_page_fault: IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001

It is clear that the fault happen for the first working buffer that is unmapped, and the freeing of the working buffers happens only
after streaming is done in the '.deinit' cb of the encoder.
So it is clear that the encoder device writes to that working buffer that was just unmapped. Maybe it is a firmware bug?
Or Maybe the encoder should  indeed write to those buffers and the kernel should wait a while before freeing them?

>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>>>>>
>>>>>>>
>>>>>>> I uses the latest firmware.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dafna
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>> -----邮件原件-----
>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
>>>>>>>> (林慧珊);
>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>> kernel@collabora.com
>>>>>>>> ;
>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
>>>>>>>> (董云飞);
>>>>>>>> Yong
>>>>>>>> Wu
>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
>>>>>>>> Andrew-CT
>>>>>>>> Chen
>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>>> cases
>>>>>>>> upon
>>>>>>>> vpu
>>>>>>>> irq handling
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
>>>>>>>>> wrote:
>>>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>>>>>>>>>> returns
>>>>>>>>>> ERR
>>>>>>>>>> pointer.
>>>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> | 8
>>>>>>>>>> ++++++++
>>>>>>>>>>       1 file changed, 8 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>       vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx-
>>>>>>>>>>> dev-
>>>>>>>>>>> fw_handler,
>>>>>>>>>>
>>>>>>>>>>            msg->vpu_inst_addr);
>>>>>>>>>>       
>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>       /* Firmware version field value is unspecified
>>>>>>>>>> on
>>>>>>>>>> MT8173.
>>>>>>>>>> */
>>>>>>>>>>       if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>       return 0;
>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>       vpu->state = msg->state;
>>>>>>>>>>       vpu->bs_size = msg->bs_size;
>>>>>>>>>>       vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>> +       vpu->state ==
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>>>> +return -EINVAL;
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> Hi Dafna,
>>>>>>>>>
>>>>>>>>> This state check is useless, the enc result will check
>>>>>>>>> in
>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>> vpu_enc_ipi_handler
>>>>>>>> only
>>>>>>>> test the msg->status and I see that the states are not
>>>>>>>> tested
>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>
>>>>>>>> Can't there be a scenario where msg->status is ok but the
>>>>>>>> state
>>>>>>>> is error?
>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>> point
>>>>>>>> the
>>>>>>>> encoder interrupts stop arriving so I try to figure out
>>>>>>>> why
>>>>>>>> and
>>>>>>>> report any possible error.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>>       return 0;
>>>>>>>>>>       }
>>>>>>>>>>       
>>>>>>>>
>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>> ******************** The
>>>>>>>> information contained in this e-mail message (including
>>>>>>>> any
>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>> privileged, or
>>>>>>>> otherwise exempt from disclosure under applicable laws.
>>>>>>>> It is
>>>>>>>> intended
>>>>>>>> to be conveyed only to the designated recipient(s). Any
>>>>>>>> use,
>>>>>>>> dissemination, distribution, printing, retaining or
>>>>>>>> copying
>>>>>>>> of
>>>>>>>> this
>>>>>>>> e-mail (including its
>>>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>>>> prohibited
>>>>>>>> and may
>>>>>>>> be unlawful. If you are not an intended recipient of this
>>>>>>>> e-
>>>>>>>> mail,
>>>>>>>> or
>>>>>>>> believe that you have received this e-mail in error,
>>>>>>>> please
>>>>>>>> notify the
>>>>>>>> sender immediately (by replying to this e-mail), delete
>>>>>>>> any
>>>>>>>> and
>>>>>>>> all
>>>>>>>> copies of this e-mail (including any attachments) from
>>>>>>>> your
>>>>>>>> system,
>>>>>>>> and do not disclose the content of this e-mail to any
>>>>>>>> other
>>>>>>>> person. Thank you!
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 11:51, Irui Wang wrote:
> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 11:16, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>> Hi Dafna,
>>>>>>>
>>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>>> or  in
>>>>>>>>> processing ?
>>>>>>>>
>>>>>>>> The commands that I run is:
>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bund
>>>>>>>>>> les/
>>>>>>>>>> cros/
>>>>>>>>>
>>>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>> sequentially
>>>>>>>>> then at some point after few attempts I start to get
>>>>>>>>> those
>>>>>>>>> timeout errors.
>>>>>>>
>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>> sometimes,
>>>>>>> did
>>>>>>> you have check VENC clock info during encoding:
>>>>>>>
>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>
>>>>>>> venc_sel   > it's H.264 clock
>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>
>>>>>>> the enable&prepare count is not 0 during encoding process.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Best Regards
>>>>>>>
>>>>>>> -----邮件原件-----
>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek
>>>>>>> SoC
>>>>>>> support; Enric Balletbo i Serra
>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>> cases
>>>>>>> upon
>>>>>>> vpu irq handling
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>> Hi Dafna,
>>>>>>>>
>>>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>>>> point
>>>>>>>>>> the encoder interrupts stop arriving so I try to
>>>>>>>>>> figure
>>>>>>>>>> out
>>>>>>>>>> why and report any possible error.
>>>>>>>>
>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>
>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>> interrupt.
>>>>>>> The
>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>
>>>>>>>
>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>> or  in
>>>>>>>> processing ?
>>>>>>>
>>>>>>> The commands that I run is:
>>>>>>>
>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cr
>>>>>>> os/v
>>>>>>> ideo
>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>
>>>>>>> The command sometime succeed but when I run it sequentially
>>>>>>> then at
>>>>>>> some point after few attempts I start to get those timeout
>>>>>>> errors.
>>>>>>>
>>>>>>>> 3. how about IRQ infos?
>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>
>>>>>>>> I was told you have  met another H.264 encoding failed
>>>>>>>> before,
>>>>>>>> did you find reasons about that ?
>>>>>>>
>>>>>>> No,
>>>>>>> But since I see that the google meetup uses the vp8 encoder
>>>>>>> I
>>>>>>> decided to test the vp8 first.
>>>>>>>
>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
>>>>>>>>> cmd=1,
>>>>>>>>> wait_event_interruptible_timeout time=1000ms out 0 0!
>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>> h264_encode_frame()
>>>>>>>>> irq_status=0 failed
>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219:
>>>>>>>>> venc_if_encode failed=-5
>>>>>>
>>>>>> Hi,
>>>>>> I test the driver on debian now, I stream several instances
>>>>>> of
>>>>>> vp8
>>>>>> and h264 in parallel.
>>>>>> I see that those errors always occur after an iommu page
>>>>>> fault:
>>>>>>
>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
>>>>>> iommu
>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0 larb=3
>>>>>> port=0
>>>>>> layer=1 write
>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>> [2706] ctx->type=1, cmd=1, wait_event_interruptible_timeout
>>>>>> time=1000ms out 0 0!
>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>> vp8_enc_encode_frame()
>>>>>> irq_status=0 failed
>>>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>>>> venc_if_encode
>>>>>> failed=-5
>>>>>>
>>>>>> I suspect that maybe this is because the iova of the
>>>>>> working_buffers
>>>>>> is handed to the vpu in the function vp8_enc_alloc_work_buf:
>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>
>>>>>> Maybe the vpu keep writing to those addresses after they are
>>>>>> already
>>>>>> unmapped?
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>
>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is larb5, is
>>>>> there
>>>>> any h264 encoding failed at that time? I have no ideas why
>>>>> these
>>>>> errors
>>>>> happened on your platform, but when we got the "iommu: fault",
>>>>> the
>>>>> possible reason is related to power or clock.
>>>>
>>>> Once the iommu fault fires, both encoders constantly fail and
>>>> never
>>>> recover
>>>> (also not when starting new instance).
>>>>
>>>> With the falut:
>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
>>>> port=0
>>>> layer=1 write
>>>>
>>>> I looked at the iommu tracing log:
>>>>
>>>>      gst-launch-1.0-606     [000] .....   714.634398: unmap:
>>>> IOMMU:
>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-606     [000] .....   714.634417: unmap:
>>>> IOMMU:
>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>> unmapped_size=20480
>>>>      gst-launch-1.0-606     [000] .....   714.634435: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-606     [000] .N...   714.634891: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-606     [000] .N...   714.635481: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-606     [000] .....   714.635934: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-606     [000] .....   714.636041: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-606     [000] .....   714.636056: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-606     [000] .....   714.636069: unmap:
>>>> IOMMU:
>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>> unmapped_size=4096
>>>>         kworker/0:0-537     [000] d.h..   714.636191:
>>>> io_page_fault:
>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>> flags=0x0001
>>>>
>>>> (I changed the iommu map/unmap trace events to print the iova
>>>> range)
>>>> you can see the first line unmapping 00000000ebede000 which is
>>>> the
>>>> faulting iova.
>>>> So it seems that the problem is due to a device trying to access
>>>> an
>>>> address that is already unmapped.
>>>> This might be either the encoder or the vpu.
>>>> Since the wb[i].iova is not reset when freeing the working
>>>> buffers I
>>>> suspect it might be the vpu device, what do you think?
>>>>
>>>> Thanks,
>>>> Dafna
>>>
>>> vpu device won't access the address, the fault logs:
>>
>>
>> Looking at the line:
>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>
>> in both vp8 and h264 it seems that the codec drivers give the vpu
>> access to the allocated iova address.
>> If the vpu doesn't access those addresses then what is the purpose of
>> this line?
>>
> "wb" is a shared buffer between AP-kernel and VPU firmware, to store
> these encoder working buffers informations, the architecture like this:
> 1. VPU firmware will set working buffers informations(size, iova(is 0
> now));
> 2. AP-kernel allocate these working buffers and get a truly
> memory(iova), so VPU firmware can get these wbs' iova after allocate
> done.
> 3. when encoding, these iova will set to encoder hardware in VPU
> firmware
> 4. encoder hardware can get the data from these "iova" to do encoding.

ok, thanks for the explanation, so vpu firmware only hand the iova adresses further to the encoder hw but never access them itself?

> 
> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver ?

yes,

> 
>>
>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1 write
>>>
>>> it's h264 encoder error when writing "RCPU" data address to encoder
>>> hardware through iommu, but why unmap happended at this time? it
>>> seems
>>> encoding process still going on....
>>
>> Why is it seems so?
> 
> the fault means errors happended while reading prepared encode data, so
> I think encoding is still going on.

I added more trace_printk debug, adding log before and after the working buffers are freed: see 'BEFORE/AFTER' log

   gst-launch-1.0-590     [000] .....   353.825276: h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
   gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU: iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096 unmapped_size=4096
   gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU: iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480 unmapped_size=20480
   gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU: iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU: iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU: iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688 unmapped_size=3186688
   gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU: iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480 unmapped_size=1044480
   gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU: iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536 unmapped_size=65536
   gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU: iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536 unmapped_size=65536
   gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU: iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096 unmapped_size=4096
   gst-launch-1.0-590     [000] .....   353.826515: h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
      kworker/0:3-67      [000] d.h..   353.826631: io_page_fault: IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001

It is clear that the fault happen for the first working buffer that is unmapped, and the freeing of the working buffers happens only
after streaming is done in the '.deinit' cb of the encoder.
So it is clear that the encoder device writes to that working buffer that was just unmapped. Maybe it is a firmware bug?
Or Maybe the encoder should  indeed write to those buffers and the kernel should wait a while before freeing them?

>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>>>>>>
>>>>>>>
>>>>>>> I uses the latest firmware.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dafna
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>> -----邮件原件-----
>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
>>>>>>>> (林慧珊);
>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>> kernel@collabora.com
>>>>>>>> ;
>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
>>>>>>>> (董云飞);
>>>>>>>> Yong
>>>>>>>> Wu
>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
>>>>>>>> Andrew-CT
>>>>>>>> Chen
>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>>> cases
>>>>>>>> upon
>>>>>>>> vpu
>>>>>>>> irq handling
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
>>>>>>>>> wrote:
>>>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>>>>>>>>>> returns
>>>>>>>>>> ERR
>>>>>>>>>> pointer.
>>>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> | 8
>>>>>>>>>> ++++++++
>>>>>>>>>>       1 file changed, 8 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>       vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx-
>>>>>>>>>>> dev-
>>>>>>>>>>> fw_handler,
>>>>>>>>>>
>>>>>>>>>>            msg->vpu_inst_addr);
>>>>>>>>>>       
>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>       /* Firmware version field value is unspecified
>>>>>>>>>> on
>>>>>>>>>> MT8173.
>>>>>>>>>> */
>>>>>>>>>>       if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>       return 0;
>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>       vpu->state = msg->state;
>>>>>>>>>>       vpu->bs_size = msg->bs_size;
>>>>>>>>>>       vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>> +       vpu->state ==
>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>>>> +return -EINVAL;
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> Hi Dafna,
>>>>>>>>>
>>>>>>>>> This state check is useless, the enc result will check
>>>>>>>>> in
>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>> vpu_enc_ipi_handler
>>>>>>>> only
>>>>>>>> test the msg->status and I see that the states are not
>>>>>>>> tested
>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>
>>>>>>>> Can't there be a scenario where msg->status is ok but the
>>>>>>>> state
>>>>>>>> is error?
>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>> point
>>>>>>>> the
>>>>>>>> encoder interrupts stop arriving so I try to figure out
>>>>>>>> why
>>>>>>>> and
>>>>>>>> report any possible error.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>>       return 0;
>>>>>>>>>>       }
>>>>>>>>>>       
>>>>>>>>
>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>> ******************** The
>>>>>>>> information contained in this e-mail message (including
>>>>>>>> any
>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>> privileged, or
>>>>>>>> otherwise exempt from disclosure under applicable laws.
>>>>>>>> It is
>>>>>>>> intended
>>>>>>>> to be conveyed only to the designated recipient(s). Any
>>>>>>>> use,
>>>>>>>> dissemination, distribution, printing, retaining or
>>>>>>>> copying
>>>>>>>> of
>>>>>>>> this
>>>>>>>> e-mail (including its
>>>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>>>> prohibited
>>>>>>>> and may
>>>>>>>> be unlawful. If you are not an intended recipient of this
>>>>>>>> e-
>>>>>>>> mail,
>>>>>>>> or
>>>>>>>> believe that you have received this e-mail in error,
>>>>>>>> please
>>>>>>>> notify the
>>>>>>>> sender immediately (by replying to this e-mail), delete
>>>>>>>> any
>>>>>>>> and
>>>>>>>> all
>>>>>>>> copies of this e-mail (including any attachments) from
>>>>>>>> your
>>>>>>>> system,
>>>>>>>> and do not disclose the content of this e-mail to any
>>>>>>>> other
>>>>>>>> person. Thank you!
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 11:51, Irui Wang wrote:
> > On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 11:16, Irui Wang wrote:
> > > > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 04.11.21 03:38, Irui Wang wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > > > > > 
> > > > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > > > Hi Dafna,
> > > > > > > > 
> > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > beginning
> > > > > > > > > > or  in
> > > > > > > > > > processing ?
> > > > > > > > > 
> > > > > > > > > The commands that I run is:
> > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > gtest_filter=-
> > > > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/
> > > > > > > > > > > bund
> > > > > > > > > > > les/
> > > > > > > > > > > cros/
> > > > > > > > > > 
> > > > > > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > sequentially
> > > > > > > > > > then at some point after few attempts I start to
> > > > > > > > > > get
> > > > > > > > > > those
> > > > > > > > > > timeout errors.
> > > > > > > > 
> > > > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > > > sometimes,
> > > > > > > > did
> > > > > > > > you have check VENC clock info during encoding:
> > > > > > > > 
> > > > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > > > 
> > > > > > > > venc_sel   > it's H.264 clock
> > > > > > > > venclt_sel  > it's VP8 clock
> > > > > > > > 
> > > > > > > > the enable&prepare count is not 0 during encoding
> > > > > > > > process.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Best Regards
> > > > > > > > 
> > > > > > > > -----邮件原件-----
> > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > > > 收件人: Irui Wang (王瑞)
> > > > > > > > 抄送: Linux Media Mailing List; moderated
> > > > > > > > list:ARM/Mediatek
> > > > > > > > SoC
> > > > > > > > support; Enric Balletbo i Serra
> > > > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > error
> > > > > > > > cases
> > > > > > > > upon
> > > > > > > > vpu irq handling
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > > > Hi Dafna,
> > > > > > > > > 
> > > > > > > > > > > I am testing the vp8 encoder on chromeos and at
> > > > > > > > > > > some
> > > > > > > > > > > point
> > > > > > > > > > > the encoder interrupts stop arriving so I try to
> > > > > > > > > > > figure
> > > > > > > > > > > out
> > > > > > > > > > > why and report any possible error.
> > > > > > > > > 
> > > > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > > > 
> > > > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > > > interrupt.
> > > > > > > > The
> > > > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > > > or  in
> > > > > > > > > processing ?
> > > > > > > > 
> > > > > > > > The commands that I run is:
> > > > > > > > 
> > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundle
> > > > > > > > s/cr
> > > > > > > > os/v
> > > > > > > > ideo
> > > > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > > > 
> > > > > > > > The command sometime succeed but when I run it
> > > > > > > > sequentially
> > > > > > > > then at
> > > > > > > > some point after few attempts I start to get those
> > > > > > > > timeout
> > > > > > > > errors.
> > > > > > > > 
> > > > > > > > > 3. how about IRQ infos?
> > > > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > > > 
> > > > > > > > > I was told you have  met another H.264 encoding
> > > > > > > > > failed
> > > > > > > > > before,
> > > > > > > > > did you find reasons about that ?
> > > > > > > > 
> > > > > > > > No,
> > > > > > > > But since I see that the google meetup uses the vp8
> > > > > > > > encoder
> > > > > > > > I
> > > > > > > > decided to test the vp8 first.
> > > > > > > > 
> > > > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
> > > > > > > > > > cmd=1,
> > > > > > > > > > wait_event_interruptible_timeout time=1000ms out 0
> > > > > > > > > > 0!
> > > > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > > > h264_encode_frame()
> > > > > > > > > > irq_status=0 failed
> > > > > > > > > > [   81.938470] [MTK_V4L2][ERROR]
> > > > > > > > > > mtk_venc_worker:1219:
> > > > > > > > > > venc_if_encode failed=-5
> > > > > > > 
> > > > > > > Hi,
> > > > > > > I test the driver on debian now, I stream several
> > > > > > > instances
> > > > > > > of
> > > > > > > vp8
> > > > > > > and h264 in parallel.
> > > > > > > I see that those errors always occur after an iommu page
> > > > > > > fault:
> > > > > > > 
> > > > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
> > > > > > > iommu
> > > > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
> > > > > > > larb=3
> > > > > > > port=0
> > > > > > > layer=1 write
> > > > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > > > [2706] ctx->type=1, cmd=1,
> > > > > > > wait_event_interruptible_timeout
> > > > > > > time=1000ms out 0 0!
> > > > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > > > vp8_enc_encode_frame()
> > > > > > > irq_status=0 failed
> > > > > > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > > > > > venc_if_encode
> > > > > > > failed=-5
> > > > > > > 
> > > > > > > I suspect that maybe this is because the iova of the
> > > > > > > working_buffers
> > > > > > > is handed to the vpu in the function
> > > > > > > vp8_enc_alloc_work_buf:
> > > > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > > > 
> > > > > > > Maybe the vpu keep writing to those addresses after they
> > > > > > > are
> > > > > > > already
> > > > > > > unmapped?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > 
> > > > > > failed larb=3, it's for h264 encoder,  vp8 encoder is
> > > > > > larb5, is
> > > > > > there
> > > > > > any h264 encoding failed at that time? I have no ideas why
> > > > > > these
> > > > > > errors
> > > > > > happened on your platform, but when we got the "iommu:
> > > > > > fault",
> > > > > > the
> > > > > > possible reason is related to power or clock.
> > > > > 
> > > > > Once the iommu fault fires, both encoders constantly fail and
> > > > > never
> > > > > recover
> > > > > (also not when starting new instance).
> > > > > 
> > > > > With the falut:
> > > > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
> > > > > port=0
> > > > > layer=1 write
> > > > > 
> > > > > I looked at the iommu tracing log:
> > > > > 
> > > > >      gst-launch-1.0-606     [000] .....   714.634398: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > > > unmapped_size=4096
> > > > >      gst-launch-1.0-606     [000] .....   714.634417: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > > > unmapped_size=20480
> > > > >      gst-launch-1.0-606     [000] .....   714.634435: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > > > unmapped_size=3186688
> > > > >      gst-launch-1.0-606     [000] .N...   714.634891: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > > > unmapped_size=1044480
> > > > >      gst-launch-1.0-606     [000] .N...   714.635481: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > > > unmapped_size=3186688
> > > > >      gst-launch-1.0-606     [000] .....   714.635934: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > > > unmapped_size=1044480
> > > > >      gst-launch-1.0-606     [000] .....   714.636041: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > > > unmapped_size=65536
> > > > >      gst-launch-1.0-606     [000] .....   714.636056: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > > > unmapped_size=65536
> > > > >      gst-launch-1.0-606     [000] .....   714.636069: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > > > unmapped_size=4096
> > > > >         kworker/0:0-537     [000] d.h..   714.636191:
> > > > > io_page_fault:
> > > > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > > > flags=0x0001
> > > > > 
> > > > > (I changed the iommu map/unmap trace events to print the iova
> > > > > range)
> > > > > you can see the first line unmapping 00000000ebede000 which
> > > > > is
> > > > > the
> > > > > faulting iova.
> > > > > So it seems that the problem is due to a device trying to
> > > > > access
> > > > > an
> > > > > address that is already unmapped.
> > > > > This might be either the encoder or the vpu.
> > > > > Since the wb[i].iova is not reset when freeing the working
> > > > > buffers I
> > > > > suspect it might be the vpu device, what do you think?
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > 
> > > > vpu device won't access the address, the fault logs:
> > > 
> > > 
> > > Looking at the line:
> > > wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> > > 
> > > in both vp8 and h264 it seems that the codec drivers give the vpu
> > > access to the allocated iova address.
> > > If the vpu doesn't access those addresses then what is the
> > > purpose of
> > > this line?
> > > 
> > 
> > "wb" is a shared buffer between AP-kernel and VPU firmware, to
> > store
> > these encoder working buffers informations, the architecture like
> > this:
> > 1. VPU firmware will set working buffers informations(size, iova(is
> > 0
> > now));
> > 2. AP-kernel allocate these working buffers and get a truly
> > memory(iova), so VPU firmware can get these wbs' iova after
> > allocate
> > done.
> > 3. when encoding, these iova will set to encoder hardware in VPU
> > firmware
> > 4. encoder hardware can get the data from these "iova" to do
> > encoding.
> 
> ok, thanks for the explanation, so vpu firmware only hand the iova
> adresses further to the encoder hw but never access them itself?
> 
> > 
> > I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver
> > ?
> 
> yes,
> 
> > 
> > > 
> > > > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
> > > > write
> > > > 
> > > > it's h264 encoder error when writing "RCPU" data address to
> > > > encoder
> > > > hardware through iommu, but why unmap happended at this time?
> > > > it
> > > > seems
> > > > encoding process still going on....
> > > 
> > > Why is it seems so?
> > 
> > the fault means errors happended while reading prepared encode
> > data, so
> > I think encoding is still going on.
> 
> I added more trace_printk debug, adding log before and after the
> working buffers are freed: see 'BEFORE/AFTER' log
> 
>    gst-launch-1.0-590     [000] .....   353.825276:
> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>    gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU:
> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU:
> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
> unmapped_size=20480
>    gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU:
> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU:
> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU:
> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU:
> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU:
> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU:
> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU:
> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-590     [000] .....   353.826515:
> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>       kworker/0:3-67      [000] d.h..   353.826631: io_page_fault:
> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001
> 
> It is clear that the fault happen for the first working buffer that
> is unmapped, and the freeing of the working buffers happens only
> after streaming is done in the '.deinit' cb of the encoder.
no, free working buffers can also happen when streaming on after
streaming off, call "set_param" again.
 
> So it is clear that the encoder device writes to that working buffer
> that was just unmapped. Maybe it is a firmware bug?
> Or Maybe the encoder should  indeed write to those buffers and the
> kernel should wait a while before freeing them?
did you have tried patch:

https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
> 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > MT8173 latest VPUD firmware:
> > > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd8
> > > > > > > > > 8b59
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I uses the latest firmware.
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Dafna
> > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > Best Regards
> > > > > > > > > 
> > > > > > > > > -----邮件原件-----
> > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > > > > > linux-media@vger.kernel.org;
> > > > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
> > > > > > > > > (林慧珊);
> > > > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广);
> > > > > > > > > kernel@collabora.com
> > > > > > > > > ;
> > > > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
> > > > > > > > > (董云飞);
> > > > > > > > > Yong
> > > > > > > > > Wu
> > > > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
> > > > > > > > > Andrew-CT
> > > > > > > > > Chen
> > > > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > > > > cases
> > > > > > > > > upon
> > > > > > > > > vpu
> > > > > > > > > irq handling
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
> > > > > > > > > > wrote:
> > > > > > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr
> > > > > > > > > > > returns
> > > > > > > > > > > ERR
> > > > > > > > > > > pointer.
> > > > > > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > > > ---
> > > > > > > > > > >       drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > 8
> > > > > > > > > > > 
> > > > > > > > > > > ++++++++
> > > > > > > > > > >       1 file changed, 8 insertions(+)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > > > --- a/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > +++ b/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > >       vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu-
> > > > > > > > > > > >ctx-
> > > > > > > > > > > > dev-
> > > > > > > > > > > > fw_handler,
> > > > > > > > > > > 
> > > > > > > > > > >            msg->vpu_inst_addr);
> > > > > > > > > > >       
> > > > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > > > >       /* Firmware version field value is
> > > > > > > > > > > unspecified
> > > > > > > > > > > on
> > > > > > > > > > > MT8173.
> > > > > > > > > > > */
> > > > > > > > > > >       if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > > > MTK_MT8173)
> > > > > > > > > > >       return 0;
> > > > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > >       vpu->state = msg->state;
> > > > > > > > > > >       vpu->bs_size = msg->bs_size;
> > > > > > > > > > >       vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > > > +       vpu->state ==
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > > > > > +return -EINVAL;
> > > > > > > > > > > +}
> > > > > > > > > > 
> > > > > > > > > > Hi Dafna,
> > > > > > > > > > 
> > > > > > > > > > This state check is useless, the enc result will
> > > > > > > > > > check
> > > > > > > > > > in
> > > > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > > > vpu_enc_ipi_handler
> > > > > > > > > only
> > > > > > > > > test the msg->status and I see that the states are
> > > > > > > > > not
> > > > > > > > > tested
> > > > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > > > 
> > > > > > > > > Can't there be a scenario where msg->status is ok but
> > > > > > > > > the
> > > > > > > > > state
> > > > > > > > > is error?
> > > > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > > > point
> > > > > > > > > the
> > > > > > > > > encoder interrupts stop arriving so I try to figure
> > > > > > > > > out
> > > > > > > > > why
> > > > > > > > > and
> > > > > > > > > report any possible error.
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Dafna
> > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > 
> > > > > > > > > > >       return 0;
> > > > > > > > > > >       }
> > > > > > > > > > >       
> > > > > > > > > 
> > > > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > > > ******************** The
> > > > > > > > > information contained in this e-mail message
> > > > > > > > > (including
> > > > > > > > > any
> > > > > > > > > attachments) may be confidential, proprietary,
> > > > > > > > > privileged, or
> > > > > > > > > otherwise exempt from disclosure under applicable
> > > > > > > > > laws.
> > > > > > > > > It is
> > > > > > > > > intended
> > > > > > > > > to be conveyed only to the designated recipient(s).
> > > > > > > > > Any
> > > > > > > > > use,
> > > > > > > > > dissemination, distribution, printing, retaining or
> > > > > > > > > copying
> > > > > > > > > of
> > > > > > > > > this
> > > > > > > > > e-mail (including its
> > > > > > > > > attachments) by unintended recipient(s) is strictly
> > > > > > > > > prohibited
> > > > > > > > > and may
> > > > > > > > > be unlawful. If you are not an intended recipient of
> > > > > > > > > this
> > > > > > > > > e-
> > > > > > > > > mail,
> > > > > > > > > or
> > > > > > > > > believe that you have received this e-mail in error,
> > > > > > > > > please
> > > > > > > > > notify the
> > > > > > > > > sender immediately (by replying to this e-mail),
> > > > > > > > > delete
> > > > > > > > > any
> > > > > > > > > and
> > > > > > > > > all
> > > > > > > > > copies of this e-mail (including any attachments)
> > > > > > > > > from
> > > > > > > > > your
> > > > > > > > > system,
> > > > > > > > > and do not disclose the content of this e-mail to any
> > > > > > > > > other
> > > > > > > > > person. Thank you!
> > > > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Linux-mediatek mailing list
> > > > > > Linux-mediatek@lists.infradead.org
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > > > 
> > 
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 11:51, Irui Wang wrote:
> > On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 11:16, Irui Wang wrote:
> > > > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 04.11.21 03:38, Irui Wang wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
> > > > > > > 
> > > > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > > > Hi Dafna,
> > > > > > > > 
> > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > beginning
> > > > > > > > > > or  in
> > > > > > > > > > processing ?
> > > > > > > > > 
> > > > > > > > > The commands that I run is:
> > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > gtest_filter=-
> > > > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/
> > > > > > > > > > > bund
> > > > > > > > > > > les/
> > > > > > > > > > > cros/
> > > > > > > > > > 
> > > > > > > > > > video/data/tulip2-320x180.yuv --disable_validator
> > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > sequentially
> > > > > > > > > > then at some point after few attempts I start to
> > > > > > > > > > get
> > > > > > > > > > those
> > > > > > > > > > timeout errors.
> > > > > > > > 
> > > > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > > > sometimes,
> > > > > > > > did
> > > > > > > > you have check VENC clock info during encoding:
> > > > > > > > 
> > > > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > > > 
> > > > > > > > venc_sel   > it's H.264 clock
> > > > > > > > venclt_sel  > it's VP8 clock
> > > > > > > > 
> > > > > > > > the enable&prepare count is not 0 during encoding
> > > > > > > > process.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Best Regards
> > > > > > > > 
> > > > > > > > -----邮件原件-----
> > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > > > 收件人: Irui Wang (王瑞)
> > > > > > > > 抄送: Linux Media Mailing List; moderated
> > > > > > > > list:ARM/Mediatek
> > > > > > > > SoC
> > > > > > > > support; Enric Balletbo i Serra
> > > > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > error
> > > > > > > > cases
> > > > > > > > upon
> > > > > > > > vpu irq handling
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > > > Hi Dafna,
> > > > > > > > > 
> > > > > > > > > > > I am testing the vp8 encoder on chromeos and at
> > > > > > > > > > > some
> > > > > > > > > > > point
> > > > > > > > > > > the encoder interrupts stop arriving so I try to
> > > > > > > > > > > figure
> > > > > > > > > > > out
> > > > > > > > > > > why and report any possible error.
> > > > > > > > > 
> > > > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > > > 
> > > > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > > > interrupt.
> > > > > > > > The
> > > > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 2. Always happened  issue ?  timeout at the beginning
> > > > > > > > > or  in
> > > > > > > > > processing ?
> > > > > > > > 
> > > > > > > > The commands that I run is:
> > > > > > > > 
> > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > tests/video_encode_accelerator_tests --gtest_filter=-
> > > > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bundle
> > > > > > > > s/cr
> > > > > > > > os/v
> > > > > > > > ideo
> > > > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > > > 
> > > > > > > > The command sometime succeed but when I run it
> > > > > > > > sequentially
> > > > > > > > then at
> > > > > > > > some point after few attempts I start to get those
> > > > > > > > timeout
> > > > > > > > errors.
> > > > > > > > 
> > > > > > > > > 3. how about IRQ infos?
> > > > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > > > 
> > > > > > > > > I was told you have  met another H.264 encoding
> > > > > > > > > failed
> > > > > > > > > before,
> > > > > > > > > did you find reasons about that ?
> > > > > > > > 
> > > > > > > > No,
> > > > > > > > But since I see that the google meetup uses the vp8
> > > > > > > > encoder
> > > > > > > > I
> > > > > > > > decided to test the vp8 first.
> > > > > > > > 
> > > > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
> > > > > > > > > > cmd=1,
> > > > > > > > > > wait_event_interruptible_timeout time=1000ms out 0
> > > > > > > > > > 0!
> > > > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > > > h264_encode_frame()
> > > > > > > > > > irq_status=0 failed
> > > > > > > > > > [   81.938470] [MTK_V4L2][ERROR]
> > > > > > > > > > mtk_venc_worker:1219:
> > > > > > > > > > venc_if_encode failed=-5
> > > > > > > 
> > > > > > > Hi,
> > > > > > > I test the driver on debian now, I stream several
> > > > > > > instances
> > > > > > > of
> > > > > > > vp8
> > > > > > > and h264 in parallel.
> > > > > > > I see that those errors always occur after an iommu page
> > > > > > > fault:
> > > > > > > 
> > > > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
> > > > > > > iommu
> > > > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
> > > > > > > larb=3
> > > > > > > port=0
> > > > > > > layer=1 write
> > > > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > > > [2706] ctx->type=1, cmd=1,
> > > > > > > wait_event_interruptible_timeout
> > > > > > > time=1000ms out 0 0!
> > > > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > > > vp8_enc_encode_frame()
> > > > > > > irq_status=0 failed
> > > > > > > [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
> > > > > > > venc_if_encode
> > > > > > > failed=-5
> > > > > > > 
> > > > > > > I suspect that maybe this is because the iova of the
> > > > > > > working_buffers
> > > > > > > is handed to the vpu in the function
> > > > > > > vp8_enc_alloc_work_buf:
> > > > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > > > 
> > > > > > > Maybe the vpu keep writing to those addresses after they
> > > > > > > are
> > > > > > > already
> > > > > > > unmapped?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > 
> > > > > > failed larb=3, it's for h264 encoder,  vp8 encoder is
> > > > > > larb5, is
> > > > > > there
> > > > > > any h264 encoding failed at that time? I have no ideas why
> > > > > > these
> > > > > > errors
> > > > > > happened on your platform, but when we got the "iommu:
> > > > > > fault",
> > > > > > the
> > > > > > possible reason is related to power or clock.
> > > > > 
> > > > > Once the iommu fault fires, both encoders constantly fail and
> > > > > never
> > > > > recover
> > > > > (also not when starting new instance).
> > > > > 
> > > > > With the falut:
> > > > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
> > > > > port=0
> > > > > layer=1 write
> > > > > 
> > > > > I looked at the iommu tracing log:
> > > > > 
> > > > >      gst-launch-1.0-606     [000] .....   714.634398: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > > > unmapped_size=4096
> > > > >      gst-launch-1.0-606     [000] .....   714.634417: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > > > unmapped_size=20480
> > > > >      gst-launch-1.0-606     [000] .....   714.634435: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > > > unmapped_size=3186688
> > > > >      gst-launch-1.0-606     [000] .N...   714.634891: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > > > unmapped_size=1044480
> > > > >      gst-launch-1.0-606     [000] .N...   714.635481: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > > > unmapped_size=3186688
> > > > >      gst-launch-1.0-606     [000] .....   714.635934: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > > > unmapped_size=1044480
> > > > >      gst-launch-1.0-606     [000] .....   714.636041: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > > > unmapped_size=65536
> > > > >      gst-launch-1.0-606     [000] .....   714.636056: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > > > unmapped_size=65536
> > > > >      gst-launch-1.0-606     [000] .....   714.636069: unmap:
> > > > > IOMMU:
> > > > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > > > unmapped_size=4096
> > > > >         kworker/0:0-537     [000] d.h..   714.636191:
> > > > > io_page_fault:
> > > > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > > > flags=0x0001
> > > > > 
> > > > > (I changed the iommu map/unmap trace events to print the iova
> > > > > range)
> > > > > you can see the first line unmapping 00000000ebede000 which
> > > > > is
> > > > > the
> > > > > faulting iova.
> > > > > So it seems that the problem is due to a device trying to
> > > > > access
> > > > > an
> > > > > address that is already unmapped.
> > > > > This might be either the encoder or the vpu.
> > > > > Since the wb[i].iova is not reset when freeing the working
> > > > > buffers I
> > > > > suspect it might be the vpu device, what do you think?
> > > > > 
> > > > > Thanks,
> > > > > Dafna
> > > > 
> > > > vpu device won't access the address, the fault logs:
> > > 
> > > 
> > > Looking at the line:
> > > wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> > > 
> > > in both vp8 and h264 it seems that the codec drivers give the vpu
> > > access to the allocated iova address.
> > > If the vpu doesn't access those addresses then what is the
> > > purpose of
> > > this line?
> > > 
> > 
> > "wb" is a shared buffer between AP-kernel and VPU firmware, to
> > store
> > these encoder working buffers informations, the architecture like
> > this:
> > 1. VPU firmware will set working buffers informations(size, iova(is
> > 0
> > now));
> > 2. AP-kernel allocate these working buffers and get a truly
> > memory(iova), so VPU firmware can get these wbs' iova after
> > allocate
> > done.
> > 3. when encoding, these iova will set to encoder hardware in VPU
> > firmware
> > 4. encoder hardware can get the data from these "iova" to do
> > encoding.
> 
> ok, thanks for the explanation, so vpu firmware only hand the iova
> adresses further to the encoder hw but never access them itself?
> 
> > 
> > I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver
> > ?
> 
> yes,
> 
> > 
> > > 
> > > > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
> > > > write
> > > > 
> > > > it's h264 encoder error when writing "RCPU" data address to
> > > > encoder
> > > > hardware through iommu, but why unmap happended at this time?
> > > > it
> > > > seems
> > > > encoding process still going on....
> > > 
> > > Why is it seems so?
> > 
> > the fault means errors happended while reading prepared encode
> > data, so
> > I think encoding is still going on.
> 
> I added more trace_printk debug, adding log before and after the
> working buffers are freed: see 'BEFORE/AFTER' log
> 
>    gst-launch-1.0-590     [000] .....   353.825276:
> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>    gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU:
> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU:
> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
> unmapped_size=20480
>    gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU:
> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU:
> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU:
> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
> unmapped_size=3186688
>    gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU:
> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
> unmapped_size=1044480
>    gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU:
> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU:
> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
> unmapped_size=65536
>    gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU:
> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
> unmapped_size=4096
>    gst-launch-1.0-590     [000] .....   353.826515:
> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>       kworker/0:3-67      [000] d.h..   353.826631: io_page_fault:
> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001
> 
> It is clear that the fault happen for the first working buffer that
> is unmapped, and the freeing of the working buffers happens only
> after streaming is done in the '.deinit' cb of the encoder.
no, free working buffers can also happen when streaming on after
streaming off, call "set_param" again.
 
> So it is clear that the encoder device writes to that working buffer
> that was just unmapped. Maybe it is a firmware bug?
> Or Maybe the encoder should  indeed write to those buffers and the
> kernel should wait a while before freeing them?
did you have tried patch:

https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
> 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > MT8173 latest VPUD firmware:
> > > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd8
> > > > > > > > > 8b59
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I uses the latest firmware.
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Dafna
> > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > Best Regards
> > > > > > > > > 
> > > > > > > > > -----邮件原件-----
> > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
> > > > > > > > > linux-media@vger.kernel.org;
> > > > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
> > > > > > > > > (林慧珊);
> > > > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广);
> > > > > > > > > kernel@collabora.com
> > > > > > > > > ;
> > > > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
> > > > > > > > > (董云飞);
> > > > > > > > > Yong
> > > > > > > > > Wu
> > > > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
> > > > > > > > > Andrew-CT
> > > > > > > > > Chen
> > > > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
> > > > > > > > > cases
> > > > > > > > > upon
> > > > > > > > > vpu
> > > > > > > > > irq handling
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
> > > > > > > > > > wrote:
> > > > > > > > > > > 1. Fail if the function mtk_vcodec_fw_map_dm_addr
> > > > > > > > > > > returns
> > > > > > > > > > > ERR
> > > > > > > > > > > pointer.
> > > > > > > > > > > 2. Fail if the state from the vpu msg is either
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > > > ---
> > > > > > > > > > >       drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > 8
> > > > > > > > > > > 
> > > > > > > > > > > ++++++++
> > > > > > > > > > >       1 file changed, 8 insertions(+)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
> > > > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > > > --- a/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > +++ b/drivers/media/platform/mtk-
> > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > >       vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu-
> > > > > > > > > > > >ctx-
> > > > > > > > > > > > dev-
> > > > > > > > > > > > fw_handler,
> > > > > > > > > > > 
> > > > > > > > > > >            msg->vpu_inst_addr);
> > > > > > > > > > >       
> > > > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > > > >       /* Firmware version field value is
> > > > > > > > > > > unspecified
> > > > > > > > > > > on
> > > > > > > > > > > MT8173.
> > > > > > > > > > > */
> > > > > > > > > > >       if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > > > MTK_MT8173)
> > > > > > > > > > >       return 0;
> > > > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > >       vpu->state = msg->state;
> > > > > > > > > > >       vpu->bs_size = msg->bs_size;
> > > > > > > > > > >       vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > > > +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > > > +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > > > +       vpu->state ==
> > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
> > > > > > > > > > > +return -EINVAL;
> > > > > > > > > > > +}
> > > > > > > > > > 
> > > > > > > > > > Hi Dafna,
> > > > > > > > > > 
> > > > > > > > > > This state check is useless, the enc result will
> > > > > > > > > > check
> > > > > > > > > > in
> > > > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > > > vpu_enc_ipi_handler
> > > > > > > > > only
> > > > > > > > > test the msg->status and I see that the states are
> > > > > > > > > not
> > > > > > > > > tested
> > > > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > > > 
> > > > > > > > > Can't there be a scenario where msg->status is ok but
> > > > > > > > > the
> > > > > > > > > state
> > > > > > > > > is error?
> > > > > > > > > I am testing the vp8 encoder on chromeos and at some
> > > > > > > > > point
> > > > > > > > > the
> > > > > > > > > encoder interrupts stop arriving so I try to figure
> > > > > > > > > out
> > > > > > > > > why
> > > > > > > > > and
> > > > > > > > > report any possible error.
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Dafna
> > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > 
> > > > > > > > > > >       return 0;
> > > > > > > > > > >       }
> > > > > > > > > > >       
> > > > > > > > > 
> > > > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > > > ******************** The
> > > > > > > > > information contained in this e-mail message
> > > > > > > > > (including
> > > > > > > > > any
> > > > > > > > > attachments) may be confidential, proprietary,
> > > > > > > > > privileged, or
> > > > > > > > > otherwise exempt from disclosure under applicable
> > > > > > > > > laws.
> > > > > > > > > It is
> > > > > > > > > intended
> > > > > > > > > to be conveyed only to the designated recipient(s).
> > > > > > > > > Any
> > > > > > > > > use,
> > > > > > > > > dissemination, distribution, printing, retaining or
> > > > > > > > > copying
> > > > > > > > > of
> > > > > > > > > this
> > > > > > > > > e-mail (including its
> > > > > > > > > attachments) by unintended recipient(s) is strictly
> > > > > > > > > prohibited
> > > > > > > > > and may
> > > > > > > > > be unlawful. If you are not an intended recipient of
> > > > > > > > > this
> > > > > > > > > e-
> > > > > > > > > mail,
> > > > > > > > > or
> > > > > > > > > believe that you have received this e-mail in error,
> > > > > > > > > please
> > > > > > > > > notify the
> > > > > > > > > sender immediately (by replying to this e-mail),
> > > > > > > > > delete
> > > > > > > > > any
> > > > > > > > > and
> > > > > > > > > all
> > > > > > > > > copies of this e-mail (including any attachments)
> > > > > > > > > from
> > > > > > > > > your
> > > > > > > > > system,
> > > > > > > > > and do not disclose the content of this e-mail to any
> > > > > > > > > other
> > > > > > > > > person. Thank you!
> > > > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Linux-mediatek mailing list
> > > > > > Linux-mediatek@lists.infradead.org
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > > > 
> > 
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 14:21, Irui Wang wrote:
> On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 11:51, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 11:16, Irui Wang wrote:
>>>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>>>>>
>>>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>>>> Hi Dafna,
>>>>>>>>>
>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>> beginning
>>>>>>>>>>> or  in
>>>>>>>>>>> processing ?
>>>>>>>>>>
>>>>>>>>>> The commands that I run is:
>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/
>>>>>>>>>>>> bund
>>>>>>>>>>>> les/
>>>>>>>>>>>> cros/
>>>>>>>>>>>
>>>>>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>> sequentially
>>>>>>>>>>> then at some point after few attempts I start to
>>>>>>>>>>> get
>>>>>>>>>>> those
>>>>>>>>>>> timeout errors.
>>>>>>>>>
>>>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>>>> sometimes,
>>>>>>>>> did
>>>>>>>>> you have check VENC clock info during encoding:
>>>>>>>>>
>>>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>>>
>>>>>>>>> venc_sel   > it's H.264 clock
>>>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>>>
>>>>>>>>> the enable&prepare count is not 0 during encoding
>>>>>>>>> process.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>> -----邮件原件-----
>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>>>> 抄送: Linux Media Mailing List; moderated
>>>>>>>>> list:ARM/Mediatek
>>>>>>>>> SoC
>>>>>>>>> support; Enric Balletbo i Serra
>>>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>> error
>>>>>>>>> cases
>>>>>>>>> upon
>>>>>>>>> vpu irq handling
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>>>> Hi Dafna,
>>>>>>>>>>
>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and at
>>>>>>>>>>>> some
>>>>>>>>>>>> point
>>>>>>>>>>>> the encoder interrupts stop arriving so I try to
>>>>>>>>>>>> figure
>>>>>>>>>>>> out
>>>>>>>>>>>> why and report any possible error.
>>>>>>>>>>
>>>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>>>
>>>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>>>> interrupt.
>>>>>>>>> The
>>>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>>>> or  in
>>>>>>>>>> processing ?
>>>>>>>>>
>>>>>>>>> The commands that I run is:
>>>>>>>>>
>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundle
>>>>>>>>> s/cr
>>>>>>>>> os/v
>>>>>>>>> ideo
>>>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>
>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>> sequentially
>>>>>>>>> then at
>>>>>>>>> some point after few attempts I start to get those
>>>>>>>>> timeout
>>>>>>>>> errors.
>>>>>>>>>
>>>>>>>>>> 3. how about IRQ infos?
>>>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>>>
>>>>>>>>>> I was told you have  met another H.264 encoding
>>>>>>>>>> failed
>>>>>>>>>> before,
>>>>>>>>>> did you find reasons about that ?
>>>>>>>>>
>>>>>>>>> No,
>>>>>>>>> But since I see that the google meetup uses the vp8
>>>>>>>>> encoder
>>>>>>>>> I
>>>>>>>>> decided to test the vp8 first.
>>>>>>>>>
>>>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
>>>>>>>>>>> cmd=1,
>>>>>>>>>>> wait_event_interruptible_timeout time=1000ms out 0
>>>>>>>>>>> 0!
>>>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>>>> h264_encode_frame()
>>>>>>>>>>> irq_status=0 failed
>>>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR]
>>>>>>>>>>> mtk_venc_worker:1219:
>>>>>>>>>>> venc_if_encode failed=-5
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I test the driver on debian now, I stream several
>>>>>>>> instances
>>>>>>>> of
>>>>>>>> vp8
>>>>>>>> and h264 in parallel.
>>>>>>>> I see that those errors always occur after an iommu page
>>>>>>>> fault:
>>>>>>>>
>>>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
>>>>>>>> iommu
>>>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
>>>>>>>> larb=3
>>>>>>>> port=0
>>>>>>>> layer=1 write
>>>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>>>> [2706] ctx->type=1, cmd=1,
>>>>>>>> wait_event_interruptible_timeout
>>>>>>>> time=1000ms out 0 0!
>>>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>>>> vp8_enc_encode_frame()
>>>>>>>> irq_status=0 failed
>>>>>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>>>>>> venc_if_encode
>>>>>>>> failed=-5
>>>>>>>>
>>>>>>>> I suspect that maybe this is because the iova of the
>>>>>>>> working_buffers
>>>>>>>> is handed to the vpu in the function
>>>>>>>> vp8_enc_alloc_work_buf:
>>>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>>>
>>>>>>>> Maybe the vpu keep writing to those addresses after they
>>>>>>>> are
>>>>>>>> already
>>>>>>>> unmapped?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>
>>>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is
>>>>>>> larb5, is
>>>>>>> there
>>>>>>> any h264 encoding failed at that time? I have no ideas why
>>>>>>> these
>>>>>>> errors
>>>>>>> happened on your platform, but when we got the "iommu:
>>>>>>> fault",
>>>>>>> the
>>>>>>> possible reason is related to power or clock.
>>>>>>
>>>>>> Once the iommu fault fires, both encoders constantly fail and
>>>>>> never
>>>>>> recover
>>>>>> (also not when starting new instance).
>>>>>>
>>>>>> With the falut:
>>>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
>>>>>> port=0
>>>>>> layer=1 write
>>>>>>
>>>>>> I looked at the iommu tracing log:
>>>>>>
>>>>>>       gst-launch-1.0-606     [000] .....   714.634398: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>>>> unmapped_size=4096
>>>>>>       gst-launch-1.0-606     [000] .....   714.634417: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>>>> unmapped_size=20480
>>>>>>       gst-launch-1.0-606     [000] .....   714.634435: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>>>> unmapped_size=3186688
>>>>>>       gst-launch-1.0-606     [000] .N...   714.634891: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>>>> unmapped_size=1044480
>>>>>>       gst-launch-1.0-606     [000] .N...   714.635481: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>>>> unmapped_size=3186688
>>>>>>       gst-launch-1.0-606     [000] .....   714.635934: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>>>> unmapped_size=1044480
>>>>>>       gst-launch-1.0-606     [000] .....   714.636041: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>>>> unmapped_size=65536
>>>>>>       gst-launch-1.0-606     [000] .....   714.636056: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>>>> unmapped_size=65536
>>>>>>       gst-launch-1.0-606     [000] .....   714.636069: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>>>> unmapped_size=4096
>>>>>>          kworker/0:0-537     [000] d.h..   714.636191:
>>>>>> io_page_fault:
>>>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>>>> flags=0x0001
>>>>>>
>>>>>> (I changed the iommu map/unmap trace events to print the iova
>>>>>> range)
>>>>>> you can see the first line unmapping 00000000ebede000 which
>>>>>> is
>>>>>> the
>>>>>> faulting iova.
>>>>>> So it seems that the problem is due to a device trying to
>>>>>> access
>>>>>> an
>>>>>> address that is already unmapped.
>>>>>> This might be either the encoder or the vpu.
>>>>>> Since the wb[i].iova is not reset when freeing the working
>>>>>> buffers I
>>>>>> suspect it might be the vpu device, what do you think?
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>
>>>>> vpu device won't access the address, the fault logs:
>>>>
>>>>
>>>> Looking at the line:
>>>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>
>>>> in both vp8 and h264 it seems that the codec drivers give the vpu
>>>> access to the allocated iova address.
>>>> If the vpu doesn't access those addresses then what is the
>>>> purpose of
>>>> this line?
>>>>
>>>
>>> "wb" is a shared buffer between AP-kernel and VPU firmware, to
>>> store
>>> these encoder working buffers informations, the architecture like
>>> this:
>>> 1. VPU firmware will set working buffers informations(size, iova(is
>>> 0
>>> now));
>>> 2. AP-kernel allocate these working buffers and get a truly
>>> memory(iova), so VPU firmware can get these wbs' iova after
>>> allocate
>>> done.
>>> 3. when encoding, these iova will set to encoder hardware in VPU
>>> firmware
>>> 4. encoder hardware can get the data from these "iova" to do
>>> encoding.
>>
>> ok, thanks for the explanation, so vpu firmware only hand the iova
>> adresses further to the encoder hw but never access them itself?
>>
>>>
>>> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver
>>> ?
>>
>> yes,
>>
>>>
>>>>
>>>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
>>>>> write
>>>>>
>>>>> it's h264 encoder error when writing "RCPU" data address to
>>>>> encoder
>>>>> hardware through iommu, but why unmap happended at this time?
>>>>> it
>>>>> seems
>>>>> encoding process still going on....
>>>>
>>>> Why is it seems so?
>>>
>>> the fault means errors happended while reading prepared encode
>>> data, so
>>> I think encoding is still going on.
>>
>> I added more trace_printk debug, adding log before and after the
>> working buffers are freed: see 'BEFORE/AFTER' log
>>
>>     gst-launch-1.0-590     [000] .....   353.825276:
>> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>>     gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU:
>> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU:
>> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
>> unmapped_size=20480
>>     gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU:
>> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU:
>> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU:
>> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU:
>> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU:
>> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU:
>> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU:
>> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-590     [000] .....   353.826515:
>> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>>        kworker/0:3-67      [000] d.h..   353.826631: io_page_fault:
>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001
>>
>> It is clear that the fault happen for the first working buffer that
>> is unmapped, and the freeing of the working buffers happens only
>> after streaming is done in the '.deinit' cb of the encoder.
> no, free working buffers can also happen when streaming on after
> streaming off, call "set_param" again.

There is actually a problem with the stream_start/stream_stop logic
It might cause asymetricall call to runtime_pm_put/get
I sent a patch fixing it, patch 2/3 in the series:

https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0

could you please review it?

I test my code with this patch applied,
that means that the working buffers are freed only upon deinit which is only when streaming ends.

Thanks,
Dafna

>   
>> So it is clear that the encoder device writes to that working buffer
>> that was just unmapped. Maybe it is a firmware bug?
>> Or Maybe the encoder should  indeed write to those buffers and the
>> kernel should wait a while before freeing them?
> did you have tried patch:
> 
> https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd

The patch is already in mainline, (so yes)

>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd8
>>>>>>>>>> 8b59
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I uses the latest firmware.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dafna
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Best Regards
>>>>>>>>>>
>>>>>>>>>> -----邮件原件-----
>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
>>>>>>>>>> (林慧珊);
>>>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>>>> kernel@collabora.com
>>>>>>>>>> ;
>>>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
>>>>>>>>>> (董云飞);
>>>>>>>>>> Yong
>>>>>>>>>> Wu
>>>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
>>>>>>>>>> Andrew-CT
>>>>>>>>>> Chen
>>>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>>>>> cases
>>>>>>>>>> upon
>>>>>>>>>> vpu
>>>>>>>>>> irq handling
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>>>>>>>>>>>> returns
>>>>>>>>>>>> ERR
>>>>>>>>>>>> pointer.
>>>>>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>        drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>> 8
>>>>>>>>>>>>
>>>>>>>>>>>> ++++++++
>>>>>>>>>>>>        1 file changed, 8 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>>>> --- a/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> +++ b/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>        vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu-
>>>>>>>>>>>>> ctx-
>>>>>>>>>>>>> dev-
>>>>>>>>>>>>> fw_handler,
>>>>>>>>>>>>
>>>>>>>>>>>>             msg->vpu_inst_addr);
>>>>>>>>>>>>        
>>>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>>>        /* Firmware version field value is
>>>>>>>>>>>> unspecified
>>>>>>>>>>>> on
>>>>>>>>>>>> MT8173.
>>>>>>>>>>>> */
>>>>>>>>>>>>        if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>>>        return 0;
>>>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>        vpu->state = msg->state;
>>>>>>>>>>>>        vpu->bs_size = msg->bs_size;
>>>>>>>>>>>>        vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>>>> +       vpu->state ==
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>>>>>> +return -EINVAL;
>>>>>>>>>>>> +}
>>>>>>>>>>>
>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>
>>>>>>>>>>> This state check is useless, the enc result will
>>>>>>>>>>> check
>>>>>>>>>>> in
>>>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>>>> vpu_enc_ipi_handler
>>>>>>>>>> only
>>>>>>>>>> test the msg->status and I see that the states are
>>>>>>>>>> not
>>>>>>>>>> tested
>>>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>>>
>>>>>>>>>> Can't there be a scenario where msg->status is ok but
>>>>>>>>>> the
>>>>>>>>>> state
>>>>>>>>>> is error?
>>>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>>>> point
>>>>>>>>>> the
>>>>>>>>>> encoder interrupts stop arriving so I try to figure
>>>>>>>>>> out
>>>>>>>>>> why
>>>>>>>>>> and
>>>>>>>>>> report any possible error.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dafna
>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>>        return 0;
>>>>>>>>>>>>        }
>>>>>>>>>>>>        
>>>>>>>>>>
>>>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>>>> ******************** The
>>>>>>>>>> information contained in this e-mail message
>>>>>>>>>> (including
>>>>>>>>>> any
>>>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>>>> privileged, or
>>>>>>>>>> otherwise exempt from disclosure under applicable
>>>>>>>>>> laws.
>>>>>>>>>> It is
>>>>>>>>>> intended
>>>>>>>>>> to be conveyed only to the designated recipient(s).
>>>>>>>>>> Any
>>>>>>>>>> use,
>>>>>>>>>> dissemination, distribution, printing, retaining or
>>>>>>>>>> copying
>>>>>>>>>> of
>>>>>>>>>> this
>>>>>>>>>> e-mail (including its
>>>>>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>>>>>> prohibited
>>>>>>>>>> and may
>>>>>>>>>> be unlawful. If you are not an intended recipient of
>>>>>>>>>> this
>>>>>>>>>> e-
>>>>>>>>>> mail,
>>>>>>>>>> or
>>>>>>>>>> believe that you have received this e-mail in error,
>>>>>>>>>> please
>>>>>>>>>> notify the
>>>>>>>>>> sender immediately (by replying to this e-mail),
>>>>>>>>>> delete
>>>>>>>>>> any
>>>>>>>>>> and
>>>>>>>>>> all
>>>>>>>>>> copies of this e-mail (including any attachments)
>>>>>>>>>> from
>>>>>>>>>> your
>>>>>>>>>> system,
>>>>>>>>>> and do not disclose the content of this e-mail to any
>>>>>>>>>> other
>>>>>>>>>> person. Thank you!
>>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-mediatek mailing list
>>>>>>> Linux-mediatek@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 04.11.21 14:21, Irui Wang wrote:
> On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 11:51, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 11:16, Irui Wang wrote:
>>>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld wrote:
>>>>>>>>
>>>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>>>> Hi Dafna,
>>>>>>>>>
>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>> beginning
>>>>>>>>>>> or  in
>>>>>>>>>>> processing ?
>>>>>>>>>>
>>>>>>>>>> The commands that I run is:
>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/
>>>>>>>>>>>> bund
>>>>>>>>>>>> les/
>>>>>>>>>>>> cros/
>>>>>>>>>>>
>>>>>>>>>>> video/data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>> sequentially
>>>>>>>>>>> then at some point after few attempts I start to
>>>>>>>>>>> get
>>>>>>>>>>> those
>>>>>>>>>>> timeout errors.
>>>>>>>>>
>>>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>>>> sometimes,
>>>>>>>>> did
>>>>>>>>> you have check VENC clock info during encoding:
>>>>>>>>>
>>>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>>>
>>>>>>>>> venc_sel   > it's H.264 clock
>>>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>>>
>>>>>>>>> the enable&prepare count is not 0 during encoding
>>>>>>>>> process.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>> -----邮件原件-----
>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>>>> 抄送: Linux Media Mailing List; moderated
>>>>>>>>> list:ARM/Mediatek
>>>>>>>>> SoC
>>>>>>>>> support; Enric Balletbo i Serra
>>>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>> error
>>>>>>>>> cases
>>>>>>>>> upon
>>>>>>>>> vpu irq handling
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>>>> Hi Dafna,
>>>>>>>>>>
>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and at
>>>>>>>>>>>> some
>>>>>>>>>>>> point
>>>>>>>>>>>> the encoder interrupts stop arriving so I try to
>>>>>>>>>>>> figure
>>>>>>>>>>>> out
>>>>>>>>>>>> why and report any possible error.
>>>>>>>>>>
>>>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>>>
>>>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>>>> interrupt.
>>>>>>>>> The
>>>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2. Always happened  issue ?  timeout at the beginning
>>>>>>>>>> or  in
>>>>>>>>>> processing ?
>>>>>>>>>
>>>>>>>>> The commands that I run is:
>>>>>>>>>
>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>> tests/video_encode_accelerator_tests --gtest_filter=-
>>>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundle
>>>>>>>>> s/cr
>>>>>>>>> os/v
>>>>>>>>> ideo
>>>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>
>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>> sequentially
>>>>>>>>> then at
>>>>>>>>> some point after few attempts I start to get those
>>>>>>>>> timeout
>>>>>>>>> errors.
>>>>>>>>>
>>>>>>>>>> 3. how about IRQ infos?
>>>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>>>
>>>>>>>>>> I was told you have  met another H.264 encoding
>>>>>>>>>> failed
>>>>>>>>>> before,
>>>>>>>>>> did you find reasons about that ?
>>>>>>>>>
>>>>>>>>> No,
>>>>>>>>> But since I see that the google meetup uses the vp8
>>>>>>>>> encoder
>>>>>>>>> I
>>>>>>>>> decided to test the vp8 first.
>>>>>>>>>
>>>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1,
>>>>>>>>>>> cmd=1,
>>>>>>>>>>> wait_event_interruptible_timeout time=1000ms out 0
>>>>>>>>>>> 0!
>>>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>>>> h264_encode_frame()
>>>>>>>>>>> irq_status=0 failed
>>>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR]
>>>>>>>>>>> mtk_venc_worker:1219:
>>>>>>>>>>> venc_if_encode failed=-5
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I test the driver on debian now, I stream several
>>>>>>>> instances
>>>>>>>> of
>>>>>>>> vp8
>>>>>>>> and h264 in parallel.
>>>>>>>> I see that those errors always occur after an iommu page
>>>>>>>> fault:
>>>>>>>>
>>>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014] mtk-
>>>>>>>> iommu
>>>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
>>>>>>>> larb=3
>>>>>>>> port=0
>>>>>>>> layer=1 write
>>>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>>>> [2706] ctx->type=1, cmd=1,
>>>>>>>> wait_event_interruptible_timeout
>>>>>>>> time=1000ms out 0 0!
>>>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>>>> vp8_enc_encode_frame()
>>>>>>>> irq_status=0 failed
>>>>>>>> [ 5744.225359] [MTK_V4L2][ERROR] mtk_venc_worker:1243:
>>>>>>>> venc_if_encode
>>>>>>>> failed=-5
>>>>>>>>
>>>>>>>> I suspect that maybe this is because the iova of the
>>>>>>>> working_buffers
>>>>>>>> is handed to the vpu in the function
>>>>>>>> vp8_enc_alloc_work_buf:
>>>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>>>
>>>>>>>> Maybe the vpu keep writing to those addresses after they
>>>>>>>> are
>>>>>>>> already
>>>>>>>> unmapped?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>
>>>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is
>>>>>>> larb5, is
>>>>>>> there
>>>>>>> any h264 encoding failed at that time? I have no ideas why
>>>>>>> these
>>>>>>> errors
>>>>>>> happened on your platform, but when we got the "iommu:
>>>>>>> fault",
>>>>>>> the
>>>>>>> possible reason is related to power or clock.
>>>>>>
>>>>>> Once the iommu fault fires, both encoders constantly fail and
>>>>>> never
>>>>>> recover
>>>>>> (also not when starting new instance).
>>>>>>
>>>>>> With the falut:
>>>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0 larb=3
>>>>>> port=0
>>>>>> layer=1 write
>>>>>>
>>>>>> I looked at the iommu tracing log:
>>>>>>
>>>>>>       gst-launch-1.0-606     [000] .....   714.634398: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>>>> unmapped_size=4096
>>>>>>       gst-launch-1.0-606     [000] .....   714.634417: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>>>> unmapped_size=20480
>>>>>>       gst-launch-1.0-606     [000] .....   714.634435: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>>>> unmapped_size=3186688
>>>>>>       gst-launch-1.0-606     [000] .N...   714.634891: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>>>> unmapped_size=1044480
>>>>>>       gst-launch-1.0-606     [000] .N...   714.635481: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>>>> unmapped_size=3186688
>>>>>>       gst-launch-1.0-606     [000] .....   714.635934: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>>>> unmapped_size=1044480
>>>>>>       gst-launch-1.0-606     [000] .....   714.636041: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>>>> unmapped_size=65536
>>>>>>       gst-launch-1.0-606     [000] .....   714.636056: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>>>> unmapped_size=65536
>>>>>>       gst-launch-1.0-606     [000] .....   714.636069: unmap:
>>>>>> IOMMU:
>>>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>>>> unmapped_size=4096
>>>>>>          kworker/0:0-537     [000] d.h..   714.636191:
>>>>>> io_page_fault:
>>>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>>>> flags=0x0001
>>>>>>
>>>>>> (I changed the iommu map/unmap trace events to print the iova
>>>>>> range)
>>>>>> you can see the first line unmapping 00000000ebede000 which
>>>>>> is
>>>>>> the
>>>>>> faulting iova.
>>>>>> So it seems that the problem is due to a device trying to
>>>>>> access
>>>>>> an
>>>>>> address that is already unmapped.
>>>>>> This might be either the encoder or the vpu.
>>>>>> Since the wb[i].iova is not reset when freeing the working
>>>>>> buffers I
>>>>>> suspect it might be the vpu device, what do you think?
>>>>>>
>>>>>> Thanks,
>>>>>> Dafna
>>>>>
>>>>> vpu device won't access the address, the fault logs:
>>>>
>>>>
>>>> Looking at the line:
>>>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>
>>>> in both vp8 and h264 it seems that the codec drivers give the vpu
>>>> access to the allocated iova address.
>>>> If the vpu doesn't access those addresses then what is the
>>>> purpose of
>>>> this line?
>>>>
>>>
>>> "wb" is a shared buffer between AP-kernel and VPU firmware, to
>>> store
>>> these encoder working buffers informations, the architecture like
>>> this:
>>> 1. VPU firmware will set working buffers informations(size, iova(is
>>> 0
>>> now));
>>> 2. AP-kernel allocate these working buffers and get a truly
>>> memory(iova), so VPU firmware can get these wbs' iova after
>>> allocate
>>> done.
>>> 3. when encoding, these iova will set to encoder hardware in VPU
>>> firmware
>>> 4. encoder hardware can get the data from these "iova" to do
>>> encoding.
>>
>> ok, thanks for the explanation, so vpu firmware only hand the iova
>> adresses further to the encoder hw but never access them itself?
>>
>>>
>>> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu driver
>>> ?
>>
>> yes,
>>
>>>
>>>>
>>>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
>>>>> write
>>>>>
>>>>> it's h264 encoder error when writing "RCPU" data address to
>>>>> encoder
>>>>> hardware through iommu, but why unmap happended at this time?
>>>>> it
>>>>> seems
>>>>> encoding process still going on....
>>>>
>>>> Why is it seems so?
>>>
>>> the fault means errors happended while reading prepared encode
>>> data, so
>>> I think encoding is still going on.
>>
>> I added more trace_printk debug, adding log before and after the
>> working buffers are freed: see 'BEFORE/AFTER' log
>>
>>     gst-launch-1.0-590     [000] .....   353.825276:
>> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>>     gst-launch-1.0-590     [000] .....   353.825282: unmap: IOMMU:
>> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-590     [000] .....   353.825300: unmap: IOMMU:
>> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
>> unmapped_size=20480
>>     gst-launch-1.0-590     [000] .....   353.825317: unmap: IOMMU:
>> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-590     [000] .....   353.825740: unmap: IOMMU:
>> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-590     [000] .....   353.825854: unmap: IOMMU:
>> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
>> unmapped_size=3186688
>>     gst-launch-1.0-590     [000] .....   353.826273: unmap: IOMMU:
>> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
>> unmapped_size=1044480
>>     gst-launch-1.0-590     [000] .....   353.826477: unmap: IOMMU:
>> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-590     [000] .....   353.826494: unmap: IOMMU:
>> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
>> unmapped_size=65536
>>     gst-launch-1.0-590     [000] .....   353.826507: unmap: IOMMU:
>> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
>> unmapped_size=4096
>>     gst-launch-1.0-590     [000] .....   353.826515:
>> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>>        kworker/0:3-67      [000] d.h..   353.826631: io_page_fault:
>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003 flags=0x0001
>>
>> It is clear that the fault happen for the first working buffer that
>> is unmapped, and the freeing of the working buffers happens only
>> after streaming is done in the '.deinit' cb of the encoder.
> no, free working buffers can also happen when streaming on after
> streaming off, call "set_param" again.

There is actually a problem with the stream_start/stream_stop logic
It might cause asymetricall call to runtime_pm_put/get
I sent a patch fixing it, patch 2/3 in the series:

https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0

could you please review it?

I test my code with this patch applied,
that means that the working buffers are freed only upon deinit which is only when streaming ends.

Thanks,
Dafna

>   
>> So it is clear that the encoder device writes to that working buffer
>> that was just unmapped. Maybe it is a firmware bug?
>> Or Maybe the encoder should  indeed write to those buffers and the
>> kernel should wait a while before freeing them?
> did you have tried patch:
> 
> https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd

The patch is already in mainline, (so yes)

>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd8
>>>>>>>>>> 8b59
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I uses the latest firmware.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dafna
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Best Regards
>>>>>>>>>>
>>>>>>>>>> -----邮件原件-----
>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin
>>>>>>>>>> (林慧珊);
>>>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>>>> kernel@collabora.com
>>>>>>>>>> ;
>>>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong
>>>>>>>>>> (董云飞);
>>>>>>>>>> Yong
>>>>>>>>>> Wu
>>>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com;
>>>>>>>>>> Andrew-CT
>>>>>>>>>> Chen
>>>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error
>>>>>>>>>> cases
>>>>>>>>>> upon
>>>>>>>>>> vpu
>>>>>>>>>> irq handling
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr
>>>>>>>>>>>> returns
>>>>>>>>>>>> ERR
>>>>>>>>>>>> pointer.
>>>>>>>>>>>> 2. Fail if the state from the vpu msg is either
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>        drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>> 8
>>>>>>>>>>>>
>>>>>>>>>>>> ++++++++
>>>>>>>>>>>>        1 file changed, 8 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>>>> --- a/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> +++ b/drivers/media/platform/mtk-
>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>        vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu-
>>>>>>>>>>>>> ctx-
>>>>>>>>>>>>> dev-
>>>>>>>>>>>>> fw_handler,
>>>>>>>>>>>>
>>>>>>>>>>>>             msg->vpu_inst_addr);
>>>>>>>>>>>>        
>>>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>>>        /* Firmware version field value is
>>>>>>>>>>>> unspecified
>>>>>>>>>>>> on
>>>>>>>>>>>> MT8173.
>>>>>>>>>>>> */
>>>>>>>>>>>>        if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>>>        return 0;
>>>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>        vpu->state = msg->state;
>>>>>>>>>>>>        vpu->bs_size = msg->bs_size;
>>>>>>>>>>>>        vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>>>> +       vpu->state ==
>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>>>>>>>>> +return -EINVAL;
>>>>>>>>>>>> +}
>>>>>>>>>>>
>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>
>>>>>>>>>>> This state check is useless, the enc result will
>>>>>>>>>>> check
>>>>>>>>>>> in
>>>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>>>> vpu_enc_ipi_handler
>>>>>>>>>> only
>>>>>>>>>> test the msg->status and I see that the states are
>>>>>>>>>> not
>>>>>>>>>> tested
>>>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>>>
>>>>>>>>>> Can't there be a scenario where msg->status is ok but
>>>>>>>>>> the
>>>>>>>>>> state
>>>>>>>>>> is error?
>>>>>>>>>> I am testing the vp8 encoder on chromeos and at some
>>>>>>>>>> point
>>>>>>>>>> the
>>>>>>>>>> encoder interrupts stop arriving so I try to figure
>>>>>>>>>> out
>>>>>>>>>> why
>>>>>>>>>> and
>>>>>>>>>> report any possible error.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dafna
>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>>        return 0;
>>>>>>>>>>>>        }
>>>>>>>>>>>>        
>>>>>>>>>>
>>>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>>>> ******************** The
>>>>>>>>>> information contained in this e-mail message
>>>>>>>>>> (including
>>>>>>>>>> any
>>>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>>>> privileged, or
>>>>>>>>>> otherwise exempt from disclosure under applicable
>>>>>>>>>> laws.
>>>>>>>>>> It is
>>>>>>>>>> intended
>>>>>>>>>> to be conveyed only to the designated recipient(s).
>>>>>>>>>> Any
>>>>>>>>>> use,
>>>>>>>>>> dissemination, distribution, printing, retaining or
>>>>>>>>>> copying
>>>>>>>>>> of
>>>>>>>>>> this
>>>>>>>>>> e-mail (including its
>>>>>>>>>> attachments) by unintended recipient(s) is strictly
>>>>>>>>>> prohibited
>>>>>>>>>> and may
>>>>>>>>>> be unlawful. If you are not an intended recipient of
>>>>>>>>>> this
>>>>>>>>>> e-
>>>>>>>>>> mail,
>>>>>>>>>> or
>>>>>>>>>> believe that you have received this e-mail in error,
>>>>>>>>>> please
>>>>>>>>>> notify the
>>>>>>>>>> sender immediately (by replying to this e-mail),
>>>>>>>>>> delete
>>>>>>>>>> any
>>>>>>>>>> and
>>>>>>>>>> all
>>>>>>>>>> copies of this e-mail (including any attachments)
>>>>>>>>>> from
>>>>>>>>>> your
>>>>>>>>>> system,
>>>>>>>>>> and do not disclose the content of this e-mail to any
>>>>>>>>>> other
>>>>>>>>>> person. Thank you!
>>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-mediatek mailing list
>>>>>>> Linux-mediatek@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Fri, 2021-11-05 at 10:16 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 14:21, Irui Wang wrote:
> > On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 11:51, Irui Wang wrote:
> > > > On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 04.11.21 11:16, Irui Wang wrote:
> > > > > > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > > > > > 
> > > > > > > On 04.11.21 03:38, Irui Wang wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > > > > > Hi Dafna,
> > > > > > > > > > 
> > > > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > > > beginning
> > > > > > > > > > > > or  in
> > > > > > > > > > > > processing ?
> > > > > > > > > > > 
> > > > > > > > > > > The commands that I run is:
> > > > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-
> > > > > > > > > > > > binary-
> > > > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > > > gtest_filter=-
> > > > > > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/lo
> > > > > > > > > > > > > cal/
> > > > > > > > > > > > > bund
> > > > > > > > > > > > > les/
> > > > > > > > > > > > > cros/
> > > > > > > > > > > > 
> > > > > > > > > > > > video/data/tulip2-320x180.yuv --
> > > > > > > > > > > > disable_validator
> > > > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > > > sequentially
> > > > > > > > > > > > then at some point after few attempts I start
> > > > > > > > > > > > to
> > > > > > > > > > > > get
> > > > > > > > > > > > those
> > > > > > > > > > > > timeout errors.
> > > > > > > > > > 
> > > > > > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > > > > > sometimes,
> > > > > > > > > > did
> > > > > > > > > > you have check VENC clock info during encoding:
> > > > > > > > > > 
> > > > > > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > > > > > 
> > > > > > > > > > venc_sel   > it's H.264 clock
> > > > > > > > > > venclt_sel  > it's VP8 clock
> > > > > > > > > > 
> > > > > > > > > > the enable&prepare count is not 0 during encoding
> > > > > > > > > > process.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Best Regards
> > > > > > > > > > 
> > > > > > > > > > -----邮件原件-----
> > > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > > > > > 收件人: Irui Wang (王瑞)
> > > > > > > > > > 抄送: Linux Media Mailing List; moderated
> > > > > > > > > > list:ARM/Mediatek
> > > > > > > > > > SoC
> > > > > > > > > > support; Enric Balletbo i Serra
> > > > > > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > > > error
> > > > > > > > > > cases
> > > > > > > > > > upon
> > > > > > > > > > vpu irq handling
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > > > > > Hi Dafna,
> > > > > > > > > > > 
> > > > > > > > > > > > > I am testing the vp8 encoder on chromeos and
> > > > > > > > > > > > > at
> > > > > > > > > > > > > some
> > > > > > > > > > > > > point
> > > > > > > > > > > > > the encoder interrupts stop arriving so I try
> > > > > > > > > > > > > to
> > > > > > > > > > > > > figure
> > > > > > > > > > > > > out
> > > > > > > > > > > > > why and report any possible error.
> > > > > > > > > > > 
> > > > > > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > > > > > 
> > > > > > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > > > > > interrupt.
> > > > > > > > > > The
> > > > > > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > > beginning
> > > > > > > > > > > or  in
> > > > > > > > > > > processing ?
> > > > > > > > > > 
> > > > > > > > > > The commands that I run is:
> > > > > > > > > > 
> > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > gtest_filter=-
> > > > > > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bu
> > > > > > > > > > ndle
> > > > > > > > > > s/cr
> > > > > > > > > > os/v
> > > > > > > > > > ideo
> > > > > > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > > > > > 
> > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > sequentially
> > > > > > > > > > then at
> > > > > > > > > > some point after few attempts I start to get those
> > > > > > > > > > timeout
> > > > > > > > > > errors.
> > > > > > > > > > 
> > > > > > > > > > > 3. how about IRQ infos?
> > > > > > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > > > > > 
> > > > > > > > > > > I was told you have  met another H.264 encoding
> > > > > > > > > > > failed
> > > > > > > > > > > before,
> > > > > > > > > > > did you find reasons about that ?
> > > > > > > > > > 
> > > > > > > > > > No,
> > > > > > > > > > But since I see that the google meetup uses the vp8
> > > > > > > > > > encoder
> > > > > > > > > > I
> > > > > > > > > > decided to test the vp8 first.
> > > > > > > > > > 
> > > > > > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx-
> > > > > > > > > > > > >type=1,
> > > > > > > > > > > > cmd=1,
> > > > > > > > > > > > wait_event_interruptible_timeout time=1000ms
> > > > > > > > > > > > out 0
> > > > > > > > > > > > 0!
> > > > > > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > > > > > h264_encode_frame()
> > > > > > > > > > > > irq_status=0 failed
> > > > > > > > > > > > [   81.938470] [MTK_V4L2][ERROR]
> > > > > > > > > > > > mtk_venc_worker:1219:
> > > > > > > > > > > > venc_if_encode failed=-5
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > I test the driver on debian now, I stream several
> > > > > > > > > instances
> > > > > > > > > of
> > > > > > > > > vp8
> > > > > > > > > and h264 in parallel.
> > > > > > > > > I see that those errors always occur after an iommu
> > > > > > > > > page
> > > > > > > > > fault:
> > > > > > > > > 
> > > > > > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014]
> > > > > > > > > mtk-
> > > > > > > > > iommu
> > > > > > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
> > > > > > > > > larb=3
> > > > > > > > > port=0
> > > > > > > > > layer=1 write
> > > > > > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > > > > > [2706] ctx->type=1, cmd=1,
> > > > > > > > > wait_event_interruptible_timeout
> > > > > > > > > time=1000ms out 0 0!
> > > > > > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > > > > > vp8_enc_encode_frame()
> > > > > > > > > irq_status=0 failed
> > > > > > > > > [ 5744.225359] [MTK_V4L2][ERROR]
> > > > > > > > > mtk_venc_worker:1243:
> > > > > > > > > venc_if_encode
> > > > > > > > > failed=-5
> > > > > > > > > 
> > > > > > > > > I suspect that maybe this is because the iova of the
> > > > > > > > > working_buffers
> > > > > > > > > is handed to the vpu in the function
> > > > > > > > > vp8_enc_alloc_work_buf:
> > > > > > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > > > > > 
> > > > > > > > > Maybe the vpu keep writing to those addresses after
> > > > > > > > > they
> > > > > > > > > are
> > > > > > > > > already
> > > > > > > > > unmapped?
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Dafna
> > > > > > > > 
> > > > > > > > failed larb=3, it's for h264 encoder,  vp8 encoder is
> > > > > > > > larb5, is
> > > > > > > > there
> > > > > > > > any h264 encoding failed at that time? I have no ideas
> > > > > > > > why
> > > > > > > > these
> > > > > > > > errors
> > > > > > > > happened on your platform, but when we got the "iommu:
> > > > > > > > fault",
> > > > > > > > the
> > > > > > > > possible reason is related to power or clock.
> > > > > > > 
> > > > > > > Once the iommu fault fires, both encoders constantly fail
> > > > > > > and
> > > > > > > never
> > > > > > > recover
> > > > > > > (also not when starting new instance).
> > > > > > > 
> > > > > > > With the falut:
> > > > > > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0
> > > > > > > larb=3
> > > > > > > port=0
> > > > > > > layer=1 write
> > > > > > > 
> > > > > > > I looked at the iommu tracing log:
> > > > > > > 
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634398:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > > > > > unmapped_size=4096
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634417:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > > > > > unmapped_size=20480
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634435:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > > > > > unmapped_size=3186688
> > > > > > >       gst-launch-1.0-606     [000] .N...   714.634891:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > > > > > unmapped_size=1044480
> > > > > > >       gst-launch-1.0-606     [000] .N...   714.635481:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > > > > > unmapped_size=3186688
> > > > > > >       gst-launch-1.0-606     [000] .....   714.635934:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > > > > > unmapped_size=1044480
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636041:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > > > > > unmapped_size=65536
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636056:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > > > > > unmapped_size=65536
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636069:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > > > > > unmapped_size=4096
> > > > > > >          kworker/0:0-537     [000] d.h..   714.636191:
> > > > > > > io_page_fault:
> > > > > > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > > > > > flags=0x0001
> > > > > > > 
> > > > > > > (I changed the iommu map/unmap trace events to print the
> > > > > > > iova
> > > > > > > range)
> > > > > > > you can see the first line unmapping 00000000ebede000
> > > > > > > which
> > > > > > > is
> > > > > > > the
> > > > > > > faulting iova.
> > > > > > > So it seems that the problem is due to a device trying to
> > > > > > > access
> > > > > > > an
> > > > > > > address that is already unmapped.
> > > > > > > This might be either the encoder or the vpu.
> > > > > > > Since the wb[i].iova is not reset when freeing the
> > > > > > > working
> > > > > > > buffers I
> > > > > > > suspect it might be the vpu device, what do you think?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > 
> > > > > > vpu device won't access the address, the fault logs:
> > > > > 
> > > > > 
> > > > > Looking at the line:
> > > > > wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > 
> > > > > in both vp8 and h264 it seems that the codec drivers give the
> > > > > vpu
> > > > > access to the allocated iova address.
> > > > > If the vpu doesn't access those addresses then what is the
> > > > > purpose of
> > > > > this line?
> > > > > 
> > > > 
> > > > "wb" is a shared buffer between AP-kernel and VPU firmware, to
> > > > store
> > > > these encoder working buffers informations, the architecture
> > > > like
> > > > this:
> > > > 1. VPU firmware will set working buffers informations(size,
> > > > iova(is
> > > > 0
> > > > now));
> > > > 2. AP-kernel allocate these working buffers and get a truly
> > > > memory(iova), so VPU firmware can get these wbs' iova after
> > > > allocate
> > > > done.
> > > > 3. when encoding, these iova will set to encoder hardware in
> > > > VPU
> > > > firmware
> > > > 4. encoder hardware can get the data from these "iova" to do
> > > > encoding.
> > > 
> > > ok, thanks for the explanation, so vpu firmware only hand the
> > > iova
> > > adresses further to the encoder hw but never access them itself?
> > > 
> > > > 
> > > > I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu
> > > > driver
> > > > ?
> > > 
> > > yes,
> > > 
> > > > 
> > > > > 
> > > > > > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
> > > > > > write
> > > > > > 
> > > > > > it's h264 encoder error when writing "RCPU" data address to
> > > > > > encoder
> > > > > > hardware through iommu, but why unmap happended at this
> > > > > > time?
> > > > > > it
> > > > > > seems
> > > > > > encoding process still going on....
> > > > > 
> > > > > Why is it seems so?
> > > > 
> > > > the fault means errors happended while reading prepared encode
> > > > data, so
> > > > I think encoding is still going on.
> > > 
> > > I added more trace_printk debug, adding log before and after the
> > > working buffers are freed: see 'BEFORE/AFTER' log
> > > 
> > >     gst-launch-1.0-590     [000] .....   353.825276:
> > > h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
> > >     gst-launch-1.0-590     [000] .....   353.825282: unmap:
> > > IOMMU:
> > > iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-590     [000] .....   353.825300: unmap:
> > > IOMMU:
> > > iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
> > > unmapped_size=20480
> > >     gst-launch-1.0-590     [000] .....   353.825317: unmap:
> > > IOMMU:
> > > iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-590     [000] .....   353.825740: unmap:
> > > IOMMU:
> > > iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-590     [000] .....   353.825854: unmap:
> > > IOMMU:
> > > iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-590     [000] .....   353.826273: unmap:
> > > IOMMU:
> > > iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-590     [000] .....   353.826477: unmap:
> > > IOMMU:
> > > iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-590     [000] .....   353.826494: unmap:
> > > IOMMU:
> > > iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-590     [000] .....   353.826507: unmap:
> > > IOMMU:
> > > iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-590     [000] .....   353.826515:
> > > h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
> > >        kworker/0:3-67      [000] d.h..   353.826631:
> > > io_page_fault:
> > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003
> > > flags=0x0001
> > > 
> > > It is clear that the fault happen for the first working buffer
> > > that
> > > is unmapped, and the freeing of the working buffers happens only
> > > after streaming is done in the '.deinit' cb of the encoder.
> > 
> > no, free working buffers can also happen when streaming on after
> > streaming off, call "set_param" again.
> 
> There is actually a problem with the stream_start/stream_stop logic
> It might cause asymetricall call to runtime_pm_put/get
> I sent a patch fixing it, patch 2/3 in the series:
> 
> 
https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0
> 
> could you please review it?
> 
Can this patch solve your current issues ?


> I test my code with this patch applied,
> that means that the working buffers are freed only upon deinit which
> is only when streaming ends.
> 
> Thanks,
> Dafna
> 
> >   
> > > So it is clear that the encoder device writes to that working
> > > buffer
> > > that was just unmapped. Maybe it is a firmware bug?
> > > Or Maybe the encoder should  indeed write to those buffers and
> > > the
> > > kernel should wait a while before freeing them?
> > 
> > did you have tried patch:
> > 
> > 
https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
> 
> The patch is already in mainline, (so yes)
> 
> > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > MT8173 latest VPUD firmware:
> > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5
> > > > > > > > > > > fdd8
> > > > > > > > > > > 8b59
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I uses the latest firmware.
> > > > > > > > > > 
> > > > > > > > > > Thanks,
> > > > > > > > > > Dafna
> > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > > Best Regards
> > > > > > > > > > > 
> > > > > > > > > > > -----邮件原件-----
> > > > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org
> > > > > > > > > > > ;
> > > > > > > > > > > linux-media@vger.kernel.org;
> > > > > > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany
> > > > > > > > > > > Lin
> > > > > > > > > > > (林慧珊);
> > > > > > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广);
> > > > > > > > > > > kernel@collabora.com
> > > > > > > > > > > ;
> > > > > > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei
> > > > > > > > > > > Dong
> > > > > > > > > > > (董云飞);
> > > > > > > > > > > Yong
> > > > > > > > > > > Wu
> > > > > > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com
> > > > > > > > > > > ;
> > > > > > > > > > > Andrew-CT
> > > > > > > > > > > Chen
> > > > > > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > > > > error
> > > > > > > > > > > cases
> > > > > > > > > > > upon
> > > > > > > > > > > vpu
> > > > > > > > > > > irq handling
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna
> > > > > > > > > > > > Hirschfeld
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 1. Fail if the function
> > > > > > > > > > > > > mtk_vcodec_fw_map_dm_addr
> > > > > > > > > > > > > returns
> > > > > > > > > > > > > ERR
> > > > > > > > > > > > > pointer.
> > > > > > > > > > > > > 2. Fail if the state from the vpu msg is
> > > > > > > > > > > > > either
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >        drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > > 8
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ++++++++
> > > > > > > > > > > > >        1 file changed, 8 insertions(+)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > b/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > > > > > --- a/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > +++ b/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > > > >        vpu->vsi =
> > > > > > > > > > > > > mtk_vcodec_fw_map_dm_addr(vpu-
> > > > > > > > > > > > > > ctx-
> > > > > > > > > > > > > > dev-
> > > > > > > > > > > > > > fw_handler,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >             msg->vpu_inst_addr);
> > > > > > > > > > > > >        
> > > > > > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > > > > > >        /* Firmware version field value is
> > > > > > > > > > > > > unspecified
> > > > > > > > > > > > > on
> > > > > > > > > > > > > MT8173.
> > > > > > > > > > > > > */
> > > > > > > > > > > > >        if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > > > > > MTK_MT8173)
> > > > > > > > > > > > >        return 0;
> > > > > > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > > > >        vpu->state = msg->state;
> > > > > > > > > > > > >        vpu->bs_size = msg->bs_size;
> > > > > > > > > > > > >        vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > > > > > +if (vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > > > > > +    vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > > > > > +       vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" :
> > > > > > > > > > > > > "PART");
> > > > > > > > > > > > > +return -EINVAL;
> > > > > > > > > > > > > +}
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Dafna,
> > > > > > > > > > > > 
> > > > > > > > > > > > This state check is useless, the enc result
> > > > > > > > > > > > will
> > > > > > > > > > > > check
> > > > > > > > > > > > in
> > > > > > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > > > > > vpu_enc_ipi_handler
> > > > > > > > > > > only
> > > > > > > > > > > test the msg->status and I see that the states
> > > > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > tested
> > > > > > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > > > > > 
> > > > > > > > > > > Can't there be a scenario where msg->status is ok
> > > > > > > > > > > but
> > > > > > > > > > > the
> > > > > > > > > > > state
> > > > > > > > > > > is error?
> > > > > > > > > > > I am testing the vp8 encoder on chromeos and at
> > > > > > > > > > > some
> > > > > > > > > > > point
> > > > > > > > > > > the
> > > > > > > > > > > encoder interrupts stop arriving so I try to
> > > > > > > > > > > figure
> > > > > > > > > > > out
> > > > > > > > > > > why
> > > > > > > > > > > and
> > > > > > > > > > > report any possible error.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Dafna
> > > > > > > > > > > 
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > 
> > > > > > > > > > > > >        return 0;
> > > > > > > > > > > > >        }
> > > > > > > > > > > > >        
> > > > > > > > > > > 
> > > > > > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > > > > > ******************** The
> > > > > > > > > > > information contained in this e-mail message
> > > > > > > > > > > (including
> > > > > > > > > > > any
> > > > > > > > > > > attachments) may be confidential, proprietary,
> > > > > > > > > > > privileged, or
> > > > > > > > > > > otherwise exempt from disclosure under applicable
> > > > > > > > > > > laws.
> > > > > > > > > > > It is
> > > > > > > > > > > intended
> > > > > > > > > > > to be conveyed only to the designated
> > > > > > > > > > > recipient(s).
> > > > > > > > > > > Any
> > > > > > > > > > > use,
> > > > > > > > > > > dissemination, distribution, printing, retaining
> > > > > > > > > > > or
> > > > > > > > > > > copying
> > > > > > > > > > > of
> > > > > > > > > > > this
> > > > > > > > > > > e-mail (including its
> > > > > > > > > > > attachments) by unintended recipient(s) is
> > > > > > > > > > > strictly
> > > > > > > > > > > prohibited
> > > > > > > > > > > and may
> > > > > > > > > > > be unlawful. If you are not an intended recipient
> > > > > > > > > > > of
> > > > > > > > > > > this
> > > > > > > > > > > e-
> > > > > > > > > > > mail,
> > > > > > > > > > > or
> > > > > > > > > > > believe that you have received this e-mail in
> > > > > > > > > > > error,
> > > > > > > > > > > please
> > > > > > > > > > > notify the
> > > > > > > > > > > sender immediately (by replying to this e-mail),
> > > > > > > > > > > delete
> > > > > > > > > > > any
> > > > > > > > > > > and
> > > > > > > > > > > all
> > > > > > > > > > > copies of this e-mail (including any attachments)
> > > > > > > > > > > from
> > > > > > > > > > > your
> > > > > > > > > > > system,
> > > > > > > > > > > and do not disclose the content of this e-mail to
> > > > > > > > > > > any
> > > > > > > > > > > other
> > > > > > > > > > > person. Thank you!
> > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > Linux-mediatek mailing list
> > > > > > > > Linux-mediatek@lists.infradead.org
> > > > > > > > 
http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > > > > > 
> > > > 
> > > > _______________________________________________
> > > > Linux-mediatek mailing list
> > > > Linux-mediatek@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang]

On Fri, 2021-11-05 at 10:16 +0200, Dafna Hirschfeld wrote:
> 
> On 04.11.21 14:21, Irui Wang wrote:
> > On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
> > > 
> > > On 04.11.21 11:51, Irui Wang wrote:
> > > > On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
> > > > > 
> > > > > On 04.11.21 11:16, Irui Wang wrote:
> > > > > > On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
> > > > > > > 
> > > > > > > On 04.11.21 03:38, Irui Wang wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > On 09.08.21 12:12, Irui Wang (王瑞) wrote:
> > > > > > > > > > Hi Dafna,
> > > > > > > > > > 
> > > > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > > > beginning
> > > > > > > > > > > > or  in
> > > > > > > > > > > > processing ?
> > > > > > > > > > > 
> > > > > > > > > > > The commands that I run is:
> > > > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-
> > > > > > > > > > > > binary-
> > > > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > > > gtest_filter=-
> > > > > > > > > > > > *NV12Dmabuf*  -->>codec=vp8
> > > > > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/lo
> > > > > > > > > > > > > cal/
> > > > > > > > > > > > > bund
> > > > > > > > > > > > > les/
> > > > > > > > > > > > > cros/
> > > > > > > > > > > > 
> > > > > > > > > > > > video/data/tulip2-320x180.yuv --
> > > > > > > > > > > > disable_validator
> > > > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > > > sequentially
> > > > > > > > > > > > then at some point after few attempts I start
> > > > > > > > > > > > to
> > > > > > > > > > > > get
> > > > > > > > > > > > those
> > > > > > > > > > > > timeout errors.
> > > > > > > > > > 
> > > > > > > > > > It seems mean VP8 encoding function OK, but failed
> > > > > > > > > > sometimes,
> > > > > > > > > > did
> > > > > > > > > > you have check VENC clock info during encoding:
> > > > > > > > > > 
> > > > > > > > > > cat /sys/kernel/debug/clk/clk_summary | grep venc:
> > > > > > > > > > 
> > > > > > > > > > venc_sel   > it's H.264 clock
> > > > > > > > > > venclt_sel  > it's VP8 clock
> > > > > > > > > > 
> > > > > > > > > > the enable&prepare count is not 0 during encoding
> > > > > > > > > > process.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Best Regards
> > > > > > > > > > 
> > > > > > > > > > -----邮件原件-----
> > > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > > 发送时间: 2021年8月9日 16:27
> > > > > > > > > > 收件人: Irui Wang (王瑞)
> > > > > > > > > > 抄送: Linux Media Mailing List; moderated
> > > > > > > > > > list:ARM/Mediatek
> > > > > > > > > > SoC
> > > > > > > > > > support; Enric Balletbo i Serra
> > > > > > > > > > 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > > > error
> > > > > > > > > > cases
> > > > > > > > > > upon
> > > > > > > > > > vpu irq handling
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 09.08.21 09:37, Irui Wang (王瑞) wrote:
> > > > > > > > > > > Hi Dafna,
> > > > > > > > > > > 
> > > > > > > > > > > > > I am testing the vp8 encoder on chromeos and
> > > > > > > > > > > > > at
> > > > > > > > > > > > > some
> > > > > > > > > > > > > point
> > > > > > > > > > > > > the encoder interrupts stop arriving so I try
> > > > > > > > > > > > > to
> > > > > > > > > > > > > figure
> > > > > > > > > > > > > out
> > > > > > > > > > > > > why and report any possible error.
> > > > > > > > > > > 
> > > > > > > > > > > 1. Log shows wait IRQ timeout ?
> > > > > > > > > > 
> > > > > > > > > > Hi, yes, I get timeout when waiting to the encoder
> > > > > > > > > > interrupt.
> > > > > > > > > > The
> > > > > > > > > > timeout is on vp8_enc_wait_venc_done
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 2. Always happened  issue ?  timeout at the
> > > > > > > > > > > beginning
> > > > > > > > > > > or  in
> > > > > > > > > > > processing ?
> > > > > > > > > > 
> > > > > > > > > > The commands that I run is:
> > > > > > > > > > 
> > > > > > > > > > sudo --user=#1000 /usr/local/libexec/chrome-binary-
> > > > > > > > > > tests/video_encode_accelerator_tests --
> > > > > > > > > > gtest_filter=-
> > > > > > > > > > *NV12Dmabuf*  --codec=vp8
> > > > > > > > > > /usr/local/share/tast/data/chromiumos/tast/local/bu
> > > > > > > > > > ndle
> > > > > > > > > > s/cr
> > > > > > > > > > os/v
> > > > > > > > > > ideo
> > > > > > > > > > /data/tulip2-320x180.yuv --disable_validator
> > > > > > > > > > 
> > > > > > > > > > The command sometime succeed but when I run it
> > > > > > > > > > sequentially
> > > > > > > > > > then at
> > > > > > > > > > some point after few attempts I start to get those
> > > > > > > > > > timeout
> > > > > > > > > > errors.
> > > > > > > > > > 
> > > > > > > > > > > 3. how about IRQ infos?
> > > > > > > > > > > cat /proc/interrupts | grep vcodec
> > > > > > > > > > > 18002000.vcodec   >> it's H.264 encoder
> > > > > > > > > > > 19002000.vcodec  >> it's  VP8 encoder
> > > > > > > > > > > 
> > > > > > > > > > > I was told you have  met another H.264 encoding
> > > > > > > > > > > failed
> > > > > > > > > > > before,
> > > > > > > > > > > did you find reasons about that ?
> > > > > > > > > > 
> > > > > > > > > > No,
> > > > > > > > > > But since I see that the google meetup uses the vp8
> > > > > > > > > > encoder
> > > > > > > > > > I
> > > > > > > > > > decided to test the vp8 first.
> > > > > > > > > > 
> > > > > > > > > > > > [   81.918747] [MTK_V4L2][ERROR]
> > > > > > > > > > > > mtk_vcodec_wait_for_done_ctx:32: [3] ctx-
> > > > > > > > > > > > >type=1,
> > > > > > > > > > > > cmd=1,
> > > > > > > > > > > > wait_event_interruptible_timeout time=1000ms
> > > > > > > > > > > > out 0
> > > > > > > > > > > > 0!
> > > > > > > > > > > > [   81.931392] [MTK_VCODEC][ERROR][3]:
> > > > > > > > > > > > h264_encode_frame()
> > > > > > > > > > > > irq_status=0 failed
> > > > > > > > > > > > [   81.938470] [MTK_V4L2][ERROR]
> > > > > > > > > > > > mtk_venc_worker:1219:
> > > > > > > > > > > > venc_if_encode failed=-5
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > I test the driver on debian now, I stream several
> > > > > > > > > instances
> > > > > > > > > of
> > > > > > > > > vp8
> > > > > > > > > and h264 in parallel.
> > > > > > > > > I see that those errors always occur after an iommu
> > > > > > > > > page
> > > > > > > > > fault:
> > > > > > > > > 
> > > > > > > > > [gst-master] root@debian:~/gst-build# [ 5743.206014]
> > > > > > > > > mtk-
> > > > > > > > > iommu
> > > > > > > > > 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
> > > > > > > > > larb=3
> > > > > > > > > port=0
> > > > > > > > > layer=1 write
> > > > > > > > > [ 5744.204964] [MTK_V4L2][ERROR]
> > > > > > > > > mtk_vcodec_wait_for_done_ctx:32:
> > > > > > > > > [2706] ctx->type=1, cmd=1,
> > > > > > > > > wait_event_interruptible_timeout
> > > > > > > > > time=1000ms out 0 0!
> > > > > > > > > [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
> > > > > > > > > vp8_enc_encode_frame()
> > > > > > > > > irq_status=0 failed
> > > > > > > > > [ 5744.225359] [MTK_V4L2][ERROR]
> > > > > > > > > mtk_venc_worker:1243:
> > > > > > > > > venc_if_encode
> > > > > > > > > failed=-5
> > > > > > > > > 
> > > > > > > > > I suspect that maybe this is because the iova of the
> > > > > > > > > working_buffers
> > > > > > > > > is handed to the vpu in the function
> > > > > > > > > vp8_enc_alloc_work_buf:
> > > > > > > > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > > > > > 
> > > > > > > > > Maybe the vpu keep writing to those addresses after
> > > > > > > > > they
> > > > > > > > > are
> > > > > > > > > already
> > > > > > > > > unmapped?
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Dafna
> > > > > > > > 
> > > > > > > > failed larb=3, it's for h264 encoder,  vp8 encoder is
> > > > > > > > larb5, is
> > > > > > > > there
> > > > > > > > any h264 encoding failed at that time? I have no ideas
> > > > > > > > why
> > > > > > > > these
> > > > > > > > errors
> > > > > > > > happened on your platform, but when we got the "iommu:
> > > > > > > > fault",
> > > > > > > > the
> > > > > > > > possible reason is related to power or clock.
> > > > > > > 
> > > > > > > Once the iommu fault fires, both encoders constantly fail
> > > > > > > and
> > > > > > > never
> > > > > > > recover
> > > > > > > (also not when starting new instance).
> > > > > > > 
> > > > > > > With the falut:
> > > > > > > mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0
> > > > > > > larb=3
> > > > > > > port=0
> > > > > > > layer=1 write
> > > > > > > 
> > > > > > > I looked at the iommu tracing log:
> > > > > > > 
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634398:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
> > > > > > > unmapped_size=4096
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634417:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
> > > > > > > unmapped_size=20480
> > > > > > >       gst-launch-1.0-606     [000] .....   714.634435:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
> > > > > > > unmapped_size=3186688
> > > > > > >       gst-launch-1.0-606     [000] .N...   714.634891:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
> > > > > > > unmapped_size=1044480
> > > > > > >       gst-launch-1.0-606     [000] .N...   714.635481:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
> > > > > > > unmapped_size=3186688
> > > > > > >       gst-launch-1.0-606     [000] .....   714.635934:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
> > > > > > > unmapped_size=1044480
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636041:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
> > > > > > > unmapped_size=65536
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636056:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
> > > > > > > unmapped_size=65536
> > > > > > >       gst-launch-1.0-606     [000] .....   714.636069:
> > > > > > > unmap:
> > > > > > > IOMMU:
> > > > > > > iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
> > > > > > > unmapped_size=4096
> > > > > > >          kworker/0:0-537     [000] d.h..   714.636191:
> > > > > > > io_page_fault:
> > > > > > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
> > > > > > > flags=0x0001
> > > > > > > 
> > > > > > > (I changed the iommu map/unmap trace events to print the
> > > > > > > iova
> > > > > > > range)
> > > > > > > you can see the first line unmapping 00000000ebede000
> > > > > > > which
> > > > > > > is
> > > > > > > the
> > > > > > > faulting iova.
> > > > > > > So it seems that the problem is due to a device trying to
> > > > > > > access
> > > > > > > an
> > > > > > > address that is already unmapped.
> > > > > > > This might be either the encoder or the vpu.
> > > > > > > Since the wb[i].iova is not reset when freeing the
> > > > > > > working
> > > > > > > buffers I
> > > > > > > suspect it might be the vpu device, what do you think?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dafna
> > > > > > 
> > > > > > vpu device won't access the address, the fault logs:
> > > > > 
> > > > > 
> > > > > Looking at the line:
> > > > > wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
> > > > > 
> > > > > in both vp8 and h264 it seems that the codec drivers give the
> > > > > vpu
> > > > > access to the allocated iova address.
> > > > > If the vpu doesn't access those addresses then what is the
> > > > > purpose of
> > > > > this line?
> > > > > 
> > > > 
> > > > "wb" is a shared buffer between AP-kernel and VPU firmware, to
> > > > store
> > > > these encoder working buffers informations, the architecture
> > > > like
> > > > this:
> > > > 1. VPU firmware will set working buffers informations(size,
> > > > iova(is
> > > > 0
> > > > now));
> > > > 2. AP-kernel allocate these working buffers and get a truly
> > > > memory(iova), so VPU firmware can get these wbs' iova after
> > > > allocate
> > > > done.
> > > > 3. when encoding, these iova will set to encoder hardware in
> > > > VPU
> > > > firmware
> > > > 4. encoder hardware can get the data from these "iova" to do
> > > > encoding.
> > > 
> > > ok, thanks for the explanation, so vpu firmware only hand the
> > > iova
> > > adresses further to the encoder hw but never access them itself?
> > > 
> > > > 
> > > > I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu
> > > > driver
> > > > ?
> > > 
> > > yes,
> > > 
> > > > 
> > > > > 
> > > > > > fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
> > > > > > write
> > > > > > 
> > > > > > it's h264 encoder error when writing "RCPU" data address to
> > > > > > encoder
> > > > > > hardware through iommu, but why unmap happended at this
> > > > > > time?
> > > > > > it
> > > > > > seems
> > > > > > encoding process still going on....
> > > > > 
> > > > > Why is it seems so?
> > > > 
> > > > the fault means errors happended while reading prepared encode
> > > > data, so
> > > > I think encoding is still going on.
> > > 
> > > I added more trace_printk debug, adding log before and after the
> > > working buffers are freed: see 'BEFORE/AFTER' log
> > > 
> > >     gst-launch-1.0-590     [000] .....   353.825276:
> > > h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
> > >     gst-launch-1.0-590     [000] .....   353.825282: unmap:
> > > IOMMU:
> > > iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-590     [000] .....   353.825300: unmap:
> > > IOMMU:
> > > iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
> > > unmapped_size=20480
> > >     gst-launch-1.0-590     [000] .....   353.825317: unmap:
> > > IOMMU:
> > > iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-590     [000] .....   353.825740: unmap:
> > > IOMMU:
> > > iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-590     [000] .....   353.825854: unmap:
> > > IOMMU:
> > > iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
> > > unmapped_size=3186688
> > >     gst-launch-1.0-590     [000] .....   353.826273: unmap:
> > > IOMMU:
> > > iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
> > > unmapped_size=1044480
> > >     gst-launch-1.0-590     [000] .....   353.826477: unmap:
> > > IOMMU:
> > > iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-590     [000] .....   353.826494: unmap:
> > > IOMMU:
> > > iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
> > > unmapped_size=65536
> > >     gst-launch-1.0-590     [000] .....   353.826507: unmap:
> > > IOMMU:
> > > iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
> > > unmapped_size=4096
> > >     gst-launch-1.0-590     [000] .....   353.826515:
> > > h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
> > >        kworker/0:3-67      [000] d.h..   353.826631:
> > > io_page_fault:
> > > IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003
> > > flags=0x0001
> > > 
> > > It is clear that the fault happen for the first working buffer
> > > that
> > > is unmapped, and the freeing of the working buffers happens only
> > > after streaming is done in the '.deinit' cb of the encoder.
> > 
> > no, free working buffers can also happen when streaming on after
> > streaming off, call "set_param" again.
> 
> There is actually a problem with the stream_start/stream_stop logic
> It might cause asymetricall call to runtime_pm_put/get
> I sent a patch fixing it, patch 2/3 in the series:
> 
> 
https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0
> 
> could you please review it?
> 
Can this patch solve your current issues ?


> I test my code with this patch applied,
> that means that the working buffers are freed only upon deinit which
> is only when streaming ends.
> 
> Thanks,
> Dafna
> 
> >   
> > > So it is clear that the encoder device writes to that working
> > > buffer
> > > that was just unmapped. Maybe it is a firmware bug?
> > > Or Maybe the encoder should  indeed write to those buffers and
> > > the
> > > kernel should wait a while before freeing them?
> > 
> > did you have tried patch:
> > 
> > 
https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
> 
> The patch is already in mainline, (so yes)
> 
> > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > MT8173 latest VPUD firmware:
> > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
> > > > > > > > > > > e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5
> > > > > > > > > > > fdd8
> > > > > > > > > > > 8b59
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I uses the latest firmware.
> > > > > > > > > > 
> > > > > > > > > > Thanks,
> > > > > > > > > > Dafna
> > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > > Best Regards
> > > > > > > > > > > 
> > > > > > > > > > > -----邮件原件-----
> > > > > > > > > > > 发件人: Dafna Hirschfeld [mailto:
> > > > > > > > > > > dafna.hirschfeld@collabora.com]
> > > > > > > > > > > 发送时间: 2021年8月6日 15:49
> > > > > > > > > > > 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org
> > > > > > > > > > > ;
> > > > > > > > > > > linux-media@vger.kernel.org;
> > > > > > > > > > > linux-mediatek@lists.infradead.org
> > > > > > > > > > > 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany
> > > > > > > > > > > Lin
> > > > > > > > > > > (林慧珊);
> > > > > > > > > > > eizan@chromium.org; Maoguang Meng (孟毛广);
> > > > > > > > > > > kernel@collabora.com
> > > > > > > > > > > ;
> > > > > > > > > > > mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei
> > > > > > > > > > > Dong
> > > > > > > > > > > (董云飞);
> > > > > > > > > > > Yong
> > > > > > > > > > > Wu
> > > > > > > > > > > (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com
> > > > > > > > > > > ;
> > > > > > > > > > > Andrew-CT
> > > > > > > > > > > Chen
> > > > > > > > > > > (陳智迪); acourbot@chromium.org
> > > > > > > > > > > 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two
> > > > > > > > > > > error
> > > > > > > > > > > cases
> > > > > > > > > > > upon
> > > > > > > > > > > vpu
> > > > > > > > > > > irq handling
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 06.08.21 08:58, Irui Wang (王瑞) wrote:
> > > > > > > > > > > > On Wed, 2021-08-04 at 16:27 +0200, Dafna
> > > > > > > > > > > > Hirschfeld
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 1. Fail if the function
> > > > > > > > > > > > > mtk_vcodec_fw_map_dm_addr
> > > > > > > > > > > > > returns
> > > > > > > > > > > > > ERR
> > > > > > > > > > > > > pointer.
> > > > > > > > > > > > > 2. Fail if the state from the vpu msg is
> > > > > > > > > > > > > either
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR or
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Signed-off-by: Dafna Hirschfeld <
> > > > > > > > > > > > > dafna.hirschfeld@collabora.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >        drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > > 8
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ++++++++
> > > > > > > > > > > > >        1 file changed, 8 insertions(+)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > b/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > index 32dc844d16f9..234705ba7cd6 100644
> > > > > > > > > > > > > --- a/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > +++ b/drivers/media/platform/mtk-
> > > > > > > > > > > > > vcodec/venc_vpu_if.c
> > > > > > > > > > > > > @@ -17,6 +17,8 @@ static int
> > > > > > > > > > > > > handle_enc_init_msg(struct
> > > > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > > > >        vpu->vsi =
> > > > > > > > > > > > > mtk_vcodec_fw_map_dm_addr(vpu-
> > > > > > > > > > > > > > ctx-
> > > > > > > > > > > > > > dev-
> > > > > > > > > > > > > > fw_handler,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >             msg->vpu_inst_addr);
> > > > > > > > > > > > >        
> > > > > > > > > > > > > +if (IS_ERR(vpu->vsi))
> > > > > > > > > > > > > +return PTR_ERR(vpu->vsi);
> > > > > > > > > > > > >        /* Firmware version field value is
> > > > > > > > > > > > > unspecified
> > > > > > > > > > > > > on
> > > > > > > > > > > > > MT8173.
> > > > > > > > > > > > > */
> > > > > > > > > > > > >        if (vpu->ctx->dev->venc_pdata->chip ==
> > > > > > > > > > > > > MTK_MT8173)
> > > > > > > > > > > > >        return 0;
> > > > > > > > > > > > > @@ -42,6 +44,12 @@ static int
> > > > > > > > > > > > > handle_enc_encode_msg(struct
> > > > > > > > > > > > > venc_vpu_inst *vpu, const void *data)
> > > > > > > > > > > > >        vpu->state = msg->state;
> > > > > > > > > > > > >        vpu->bs_size = msg->bs_size;
> > > > > > > > > > > > >        vpu->is_key_frm = msg->is_key_frm;
> > > > > > > > > > > > > +if (vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ||
> > > > > > > > > > > > > +    vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_PART) {
> > > > > > > > > > > > > mtk_vcodec_err(vpu,
> > > > > > > > > > > > > +"bad ipi-enc-state: %s",
> > > > > > > > > > > > > +       vpu->state ==
> > > > > > > > > > > > > VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" :
> > > > > > > > > > > > > "PART");
> > > > > > > > > > > > > +return -EINVAL;
> > > > > > > > > > > > > +}
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Dafna,
> > > > > > > > > > > > 
> > > > > > > > > > > > This state check is useless, the enc result
> > > > > > > > > > > > will
> > > > > > > > > > > > check
> > > > > > > > > > > > in
> > > > > > > > > > > > "vpu_enc_ipi_handler".
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Hi, thanks for reviewing. I see that the
> > > > > > > > > > > vpu_enc_ipi_handler
> > > > > > > > > > > only
> > > > > > > > > > > test the msg->status and I see that the states
> > > > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > tested
> > > > > > > > > > > anywhere except of "skip" state in the h264 enc.
> > > > > > > > > > > 
> > > > > > > > > > > Can't there be a scenario where msg->status is ok
> > > > > > > > > > > but
> > > > > > > > > > > the
> > > > > > > > > > > state
> > > > > > > > > > > is error?
> > > > > > > > > > > I am testing the vp8 encoder on chromeos and at
> > > > > > > > > > > some
> > > > > > > > > > > point
> > > > > > > > > > > the
> > > > > > > > > > > encoder interrupts stop arriving so I try to
> > > > > > > > > > > figure
> > > > > > > > > > > out
> > > > > > > > > > > why
> > > > > > > > > > > and
> > > > > > > > > > > report any possible error.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Dafna
> > > > > > > > > > > 
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > 
> > > > > > > > > > > > >        return 0;
> > > > > > > > > > > > >        }
> > > > > > > > > > > > >        
> > > > > > > > > > > 
> > > > > > > > > > > ************* MEDIATEK Confidentiality Notice
> > > > > > > > > > > ******************** The
> > > > > > > > > > > information contained in this e-mail message
> > > > > > > > > > > (including
> > > > > > > > > > > any
> > > > > > > > > > > attachments) may be confidential, proprietary,
> > > > > > > > > > > privileged, or
> > > > > > > > > > > otherwise exempt from disclosure under applicable
> > > > > > > > > > > laws.
> > > > > > > > > > > It is
> > > > > > > > > > > intended
> > > > > > > > > > > to be conveyed only to the designated
> > > > > > > > > > > recipient(s).
> > > > > > > > > > > Any
> > > > > > > > > > > use,
> > > > > > > > > > > dissemination, distribution, printing, retaining
> > > > > > > > > > > or
> > > > > > > > > > > copying
> > > > > > > > > > > of
> > > > > > > > > > > this
> > > > > > > > > > > e-mail (including its
> > > > > > > > > > > attachments) by unintended recipient(s) is
> > > > > > > > > > > strictly
> > > > > > > > > > > prohibited
> > > > > > > > > > > and may
> > > > > > > > > > > be unlawful. If you are not an intended recipient
> > > > > > > > > > > of
> > > > > > > > > > > this
> > > > > > > > > > > e-
> > > > > > > > > > > mail,
> > > > > > > > > > > or
> > > > > > > > > > > believe that you have received this e-mail in
> > > > > > > > > > > error,
> > > > > > > > > > > please
> > > > > > > > > > > notify the
> > > > > > > > > > > sender immediately (by replying to this e-mail),
> > > > > > > > > > > delete
> > > > > > > > > > > any
> > > > > > > > > > > and
> > > > > > > > > > > all
> > > > > > > > > > > copies of this e-mail (including any attachments)
> > > > > > > > > > > from
> > > > > > > > > > > your
> > > > > > > > > > > system,
> > > > > > > > > > > and do not disclose the content of this e-mail to
> > > > > > > > > > > any
> > > > > > > > > > > other
> > > > > > > > > > > person. Thank you!
> > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > Linux-mediatek mailing list
> > > > > > > > Linux-mediatek@lists.infradead.org
> > > > > > > > 
http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > > > > > 
> > > > 
> > > > _______________________________________________
> > > > Linux-mediatek mailing list
> > > > Linux-mediatek@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > > > 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 06.11.21 09:02, Irui Wang wrote:
> On Fri, 2021-11-05 at 10:16 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 14:21, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 11:51, Irui Wang wrote:
>>>>> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 04.11.21 11:16, Irui Wang wrote:
>>>>>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>>>>>
>>>>>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>
>>>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>>>> beginning
>>>>>>>>>>>>> or  in
>>>>>>>>>>>>> processing ?
>>>>>>>>>>>>
>>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-
>>>>>>>>>>>>> binary-
>>>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/lo
>>>>>>>>>>>>>> cal/
>>>>>>>>>>>>>> bund
>>>>>>>>>>>>>> les/
>>>>>>>>>>>>>> cros/
>>>>>>>>>>>>>
>>>>>>>>>>>>> video/data/tulip2-320x180.yuv --
>>>>>>>>>>>>> disable_validator
>>>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>>>> sequentially
>>>>>>>>>>>>> then at some point after few attempts I start
>>>>>>>>>>>>> to
>>>>>>>>>>>>> get
>>>>>>>>>>>>> those
>>>>>>>>>>>>> timeout errors.
>>>>>>>>>>>
>>>>>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>>>>>> sometimes,
>>>>>>>>>>> did
>>>>>>>>>>> you have check VENC clock info during encoding:
>>>>>>>>>>>
>>>>>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>>>>>
>>>>>>>>>>> venc_sel   > it's H.264 clock
>>>>>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>>>>>
>>>>>>>>>>> the enable&prepare count is not 0 during encoding
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Best Regards
>>>>>>>>>>>
>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>>>>>> 抄送: Linux Media Mailing List; moderated
>>>>>>>>>>> list:ARM/Mediatek
>>>>>>>>>>> SoC
>>>>>>>>>>> support; Enric Balletbo i Serra
>>>>>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>> error
>>>>>>>>>>> cases
>>>>>>>>>>> upon
>>>>>>>>>>> vpu irq handling
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>
>>>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> point
>>>>>>>>>>>>>> the encoder interrupts stop arriving so I try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> why and report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>>>>>
>>>>>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>>>>>> interrupt.
>>>>>>>>>>> The
>>>>>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>>> beginning
>>>>>>>>>>>> or  in
>>>>>>>>>>>> processing ?
>>>>>>>>>>>
>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>
>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bu
>>>>>>>>>>> ndle
>>>>>>>>>>> s/cr
>>>>>>>>>>> os/v
>>>>>>>>>>> ideo
>>>>>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>>>
>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>> sequentially
>>>>>>>>>>> then at
>>>>>>>>>>> some point after few attempts I start to get those
>>>>>>>>>>> timeout
>>>>>>>>>>> errors.
>>>>>>>>>>>
>>>>>>>>>>>> 3. how about IRQ infos?
>>>>>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>>>>>
>>>>>>>>>>>> I was told you have  met another H.264 encoding
>>>>>>>>>>>> failed
>>>>>>>>>>>> before,
>>>>>>>>>>>> did you find reasons about that ?
>>>>>>>>>>>
>>>>>>>>>>> No,
>>>>>>>>>>> But since I see that the google meetup uses the vp8
>>>>>>>>>>> encoder
>>>>>>>>>>> I
>>>>>>>>>>> decided to test the vp8 first.
>>>>>>>>>>>
>>>>>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx-
>>>>>>>>>>>>>> type=1,
>>>>>>>>>>>>> cmd=1,
>>>>>>>>>>>>> wait_event_interruptible_timeout time=1000ms
>>>>>>>>>>>>> out 0
>>>>>>>>>>>>> 0!
>>>>>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>>>>>> h264_encode_frame()
>>>>>>>>>>>>> irq_status=0 failed
>>>>>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_venc_worker:1219:
>>>>>>>>>>>>> venc_if_encode failed=-5
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I test the driver on debian now, I stream several
>>>>>>>>>> instances
>>>>>>>>>> of
>>>>>>>>>> vp8
>>>>>>>>>> and h264 in parallel.
>>>>>>>>>> I see that those errors always occur after an iommu
>>>>>>>>>> page
>>>>>>>>>> fault:
>>>>>>>>>>
>>>>>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014]
>>>>>>>>>> mtk-
>>>>>>>>>> iommu
>>>>>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
>>>>>>>>>> larb=3
>>>>>>>>>> port=0
>>>>>>>>>> layer=1 write
>>>>>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>>>>>> [2706] ctx->type=1, cmd=1,
>>>>>>>>>> wait_event_interruptible_timeout
>>>>>>>>>> time=1000ms out 0 0!
>>>>>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>>>>>> vp8_enc_encode_frame()
>>>>>>>>>> irq_status=0 failed
>>>>>>>>>> [ 5744.225359] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_venc_worker:1243:
>>>>>>>>>> venc_if_encode
>>>>>>>>>> failed=-5
>>>>>>>>>>
>>>>>>>>>> I suspect that maybe this is because the iova of the
>>>>>>>>>> working_buffers
>>>>>>>>>> is handed to the vpu in the function
>>>>>>>>>> vp8_enc_alloc_work_buf:
>>>>>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>>>>>
>>>>>>>>>> Maybe the vpu keep writing to those addresses after
>>>>>>>>>> they
>>>>>>>>>> are
>>>>>>>>>> already
>>>>>>>>>> unmapped?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dafna
>>>>>>>>>
>>>>>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is
>>>>>>>>> larb5, is
>>>>>>>>> there
>>>>>>>>> any h264 encoding failed at that time? I have no ideas
>>>>>>>>> why
>>>>>>>>> these
>>>>>>>>> errors
>>>>>>>>> happened on your platform, but when we got the "iommu:
>>>>>>>>> fault",
>>>>>>>>> the
>>>>>>>>> possible reason is related to power or clock.
>>>>>>>>
>>>>>>>> Once the iommu fault fires, both encoders constantly fail
>>>>>>>> and
>>>>>>>> never
>>>>>>>> recover
>>>>>>>> (also not when starting new instance).
>>>>>>>>
>>>>>>>> With the falut:
>>>>>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0
>>>>>>>> larb=3
>>>>>>>> port=0
>>>>>>>> layer=1 write
>>>>>>>>
>>>>>>>> I looked at the iommu tracing log:
>>>>>>>>
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634398:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634417:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>>>>>> unmapped_size=20480
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634435:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>>        gst-launch-1.0-606     [000] .N...   714.634891:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>>        gst-launch-1.0-606     [000] .N...   714.635481:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.635934:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636041:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636056:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636069:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>>           kworker/0:0-537     [000] d.h..   714.636191:
>>>>>>>> io_page_fault:
>>>>>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>>>>>> flags=0x0001
>>>>>>>>
>>>>>>>> (I changed the iommu map/unmap trace events to print the
>>>>>>>> iova
>>>>>>>> range)
>>>>>>>> you can see the first line unmapping 00000000ebede000
>>>>>>>> which
>>>>>>>> is
>>>>>>>> the
>>>>>>>> faulting iova.
>>>>>>>> So it seems that the problem is due to a device trying to
>>>>>>>> access
>>>>>>>> an
>>>>>>>> address that is already unmapped.
>>>>>>>> This might be either the encoder or the vpu.
>>>>>>>> Since the wb[i].iova is not reset when freeing the
>>>>>>>> working
>>>>>>>> buffers I
>>>>>>>> suspect it might be the vpu device, what do you think?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>
>>>>>>> vpu device won't access the address, the fault logs:
>>>>>>
>>>>>>
>>>>>> Looking at the line:
>>>>>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>
>>>>>> in both vp8 and h264 it seems that the codec drivers give the
>>>>>> vpu
>>>>>> access to the allocated iova address.
>>>>>> If the vpu doesn't access those addresses then what is the
>>>>>> purpose of
>>>>>> this line?
>>>>>>
>>>>>
>>>>> "wb" is a shared buffer between AP-kernel and VPU firmware, to
>>>>> store
>>>>> these encoder working buffers informations, the architecture
>>>>> like
>>>>> this:
>>>>> 1. VPU firmware will set working buffers informations(size,
>>>>> iova(is
>>>>> 0
>>>>> now));
>>>>> 2. AP-kernel allocate these working buffers and get a truly
>>>>> memory(iova), so VPU firmware can get these wbs' iova after
>>>>> allocate
>>>>> done.
>>>>> 3. when encoding, these iova will set to encoder hardware in
>>>>> VPU
>>>>> firmware
>>>>> 4. encoder hardware can get the data from these "iova" to do
>>>>> encoding.
>>>>
>>>> ok, thanks for the explanation, so vpu firmware only hand the
>>>> iova
>>>> adresses further to the encoder hw but never access them itself?
>>>>
>>>>>
>>>>> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu
>>>>> driver
>>>>> ?
>>>>
>>>> yes,
>>>>
>>>>>
>>>>>>
>>>>>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
>>>>>>> write
>>>>>>>
>>>>>>> it's h264 encoder error when writing "RCPU" data address to
>>>>>>> encoder
>>>>>>> hardware through iommu, but why unmap happended at this
>>>>>>> time?
>>>>>>> it
>>>>>>> seems
>>>>>>> encoding process still going on....
>>>>>>
>>>>>> Why is it seems so?
>>>>>
>>>>> the fault means errors happended while reading prepared encode
>>>>> data, so
>>>>> I think encoding is still going on.
>>>>
>>>> I added more trace_printk debug, adding log before and after the
>>>> working buffers are freed: see 'BEFORE/AFTER' log
>>>>
>>>>      gst-launch-1.0-590     [000] .....   353.825276:
>>>> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>>>>      gst-launch-1.0-590     [000] .....   353.825282: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-590     [000] .....   353.825300: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
>>>> unmapped_size=20480
>>>>      gst-launch-1.0-590     [000] .....   353.825317: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-590     [000] .....   353.825740: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-590     [000] .....   353.825854: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-590     [000] .....   353.826273: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-590     [000] .....   353.826477: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-590     [000] .....   353.826494: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-590     [000] .....   353.826507: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-590     [000] .....   353.826515:
>>>> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>>>>         kworker/0:3-67      [000] d.h..   353.826631:
>>>> io_page_fault:
>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003
>>>> flags=0x0001
>>>>
>>>> It is clear that the fault happen for the first working buffer
>>>> that
>>>> is unmapped, and the freeing of the working buffers happens only
>>>> after streaming is done in the '.deinit' cb of the encoder.
>>>
>>> no, free working buffers can also happen when streaming on after
>>> streaming off, call "set_param" again.

Still I can't think why would we have an encoded operation executing while buffers are freed,
all operations are protected with mtk_venc_lock.
Do you have any idea?


>>
>> There is actually a problem with the stream_start/stream_stop logic
>> It might cause asymetricall call to runtime_pm_put/get
>> I sent a patch fixing it, patch 2/3 in the series:
>>
>>
> https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0
>>
>> could you please review it?
>>
> Can this patch solve your current issues ?

This patch solves a different issue in this driver. (As I already described)

Thank you,
Dafna

> 
> 
>> I test my code with this patch applied,
>> that means that the working buffers are freed only upon deinit which
>> is only when streaming ends.
>>
>> Thanks,
>> Dafna
>>
>>>    
>>>> So it is clear that the encoder device writes to that working
>>>> buffer
>>>> that was just unmapped. Maybe it is a firmware bug?
>>>> Or Maybe the encoder should  indeed write to those buffers and
>>>> the
>>>> kernel should wait a while before freeing them?
>>>
>>> did you have tried patch:
>>>
>>>
> https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
>>
>> The patch is already in mainline, (so yes)
>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5
>>>>>>>>>>>> fdd8
>>>>>>>>>>>> 8b59
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I uses the latest firmware.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dafna
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>
>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org
>>>>>>>>>>>> ;
>>>>>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany
>>>>>>>>>>>> Lin
>>>>>>>>>>>> (林慧珊);
>>>>>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>>>>>> kernel@collabora.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei
>>>>>>>>>>>> Dong
>>>>>>>>>>>> (董云飞);
>>>>>>>>>>>> Yong
>>>>>>>>>>>> Wu
>>>>>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> Andrew-CT
>>>>>>>>>>>> Chen
>>>>>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>>> error
>>>>>>>>>>>> cases
>>>>>>>>>>>> upon
>>>>>>>>>>>> vpu
>>>>>>>>>>>> irq handling
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna
>>>>>>>>>>>>> Hirschfeld
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 1. Fail if the function
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr
>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>> ERR
>>>>>>>>>>>>>> pointer.
>>>>>>>>>>>>>> 2. Fail if the state from the vpu msg is
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>         drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>>> 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ++++++++
>>>>>>>>>>>>>>         1 file changed, 8 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>>>>>> --- a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> +++ b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>>         vpu->vsi =
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr(vpu-
>>>>>>>>>>>>>>> ctx-
>>>>>>>>>>>>>>> dev-
>>>>>>>>>>>>>>> fw_handler,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              msg->vpu_inst_addr);
>>>>>>>>>>>>>>         
>>>>>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>>>>>         /* Firmware version field value is
>>>>>>>>>>>>>> unspecified
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> MT8173.
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>         if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>>>>>         return 0;
>>>>>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>>         vpu->state = msg->state;
>>>>>>>>>>>>>>         vpu->bs_size = msg->bs_size;
>>>>>>>>>>>>>>         vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>>>>>> +if (vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>>>>>> +    vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>>>>>> +       vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" :
>>>>>>>>>>>>>> "PART");
>>>>>>>>>>>>>> +return -EINVAL;
>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This state check is useless, the enc result
>>>>>>>>>>>>> will
>>>>>>>>>>>>> check
>>>>>>>>>>>>> in
>>>>>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>>>>>> vpu_enc_ipi_handler
>>>>>>>>>>>> only
>>>>>>>>>>>> test the msg->status and I see that the states
>>>>>>>>>>>> are
>>>>>>>>>>>> not
>>>>>>>>>>>> tested
>>>>>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>>>>>
>>>>>>>>>>>> Can't there be a scenario where msg->status is ok
>>>>>>>>>>>> but
>>>>>>>>>>>> the
>>>>>>>>>>>> state
>>>>>>>>>>>> is error?
>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and at
>>>>>>>>>>>> some
>>>>>>>>>>>> point
>>>>>>>>>>>> the
>>>>>>>>>>>> encoder interrupts stop arriving so I try to
>>>>>>>>>>>> figure
>>>>>>>>>>>> out
>>>>>>>>>>>> why
>>>>>>>>>>>> and
>>>>>>>>>>>> report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dafna
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>>         return 0;
>>>>>>>>>>>>>>         }
>>>>>>>>>>>>>>         
>>>>>>>>>>>>
>>>>>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>>>>>> ******************** The
>>>>>>>>>>>> information contained in this e-mail message
>>>>>>>>>>>> (including
>>>>>>>>>>>> any
>>>>>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>>>>>> privileged, or
>>>>>>>>>>>> otherwise exempt from disclosure under applicable
>>>>>>>>>>>> laws.
>>>>>>>>>>>> It is
>>>>>>>>>>>> intended
>>>>>>>>>>>> to be conveyed only to the designated
>>>>>>>>>>>> recipient(s).
>>>>>>>>>>>> Any
>>>>>>>>>>>> use,
>>>>>>>>>>>> dissemination, distribution, printing, retaining
>>>>>>>>>>>> or
>>>>>>>>>>>> copying
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-mail (including its
>>>>>>>>>>>> attachments) by unintended recipient(s) is
>>>>>>>>>>>> strictly
>>>>>>>>>>>> prohibited
>>>>>>>>>>>> and may
>>>>>>>>>>>> be unlawful. If you are not an intended recipient
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-
>>>>>>>>>>>> mail,
>>>>>>>>>>>> or
>>>>>>>>>>>> believe that you have received this e-mail in
>>>>>>>>>>>> error,
>>>>>>>>>>>> please
>>>>>>>>>>>> notify the
>>>>>>>>>>>> sender immediately (by replying to this e-mail),
>>>>>>>>>>>> delete
>>>>>>>>>>>> any
>>>>>>>>>>>> and
>>>>>>>>>>>> all
>>>>>>>>>>>> copies of this e-mail (including any attachments)
>>>>>>>>>>>> from
>>>>>>>>>>>> your
>>>>>>>>>>>> system,
>>>>>>>>>>>> and do not disclose the content of this e-mail to
>>>>>>>>>>>> any
>>>>>>>>>>>> other
>>>>>>>>>>>> person. Thank you!
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-mediatek mailing list
>>>>>>>>> Linux-mediatek@lists.infradead.org
>>>>>>>>>
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 06.11.21 09:02, Irui Wang wrote:
> On Fri, 2021-11-05 at 10:16 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 14:21, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 11:51, Irui Wang wrote:
>>>>> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 04.11.21 11:16, Irui Wang wrote:
>>>>>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>>>>>
>>>>>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>
>>>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>>>> beginning
>>>>>>>>>>>>> or  in
>>>>>>>>>>>>> processing ?
>>>>>>>>>>>>
>>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-
>>>>>>>>>>>>> binary-
>>>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>>>> *NV12Dmabuf*  -->>codec=vp8
>>>>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/lo
>>>>>>>>>>>>>> cal/
>>>>>>>>>>>>>> bund
>>>>>>>>>>>>>> les/
>>>>>>>>>>>>>> cros/
>>>>>>>>>>>>>
>>>>>>>>>>>>> video/data/tulip2-320x180.yuv --
>>>>>>>>>>>>> disable_validator
>>>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>>>> sequentially
>>>>>>>>>>>>> then at some point after few attempts I start
>>>>>>>>>>>>> to
>>>>>>>>>>>>> get
>>>>>>>>>>>>> those
>>>>>>>>>>>>> timeout errors.
>>>>>>>>>>>
>>>>>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>>>>>> sometimes,
>>>>>>>>>>> did
>>>>>>>>>>> you have check VENC clock info during encoding:
>>>>>>>>>>>
>>>>>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>>>>>
>>>>>>>>>>> venc_sel   > it's H.264 clock
>>>>>>>>>>> venclt_sel  > it's VP8 clock
>>>>>>>>>>>
>>>>>>>>>>> the enable&prepare count is not 0 during encoding
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Best Regards
>>>>>>>>>>>
>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>>>>>> 抄送: Linux Media Mailing List; moderated
>>>>>>>>>>> list:ARM/Mediatek
>>>>>>>>>>> SoC
>>>>>>>>>>> support; Enric Balletbo i Serra
>>>>>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>> error
>>>>>>>>>>> cases
>>>>>>>>>>> upon
>>>>>>>>>>> vpu irq handling
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>
>>>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> point
>>>>>>>>>>>>>> the encoder interrupts stop arriving so I try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> why and report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>>>>>
>>>>>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>>>>>> interrupt.
>>>>>>>>>>> The
>>>>>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2. Always happened  issue ?  timeout at the
>>>>>>>>>>>> beginning
>>>>>>>>>>>> or  in
>>>>>>>>>>>> processing ?
>>>>>>>>>>>
>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>
>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>> *NV12Dmabuf*  --codec=vp8
>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bu
>>>>>>>>>>> ndle
>>>>>>>>>>> s/cr
>>>>>>>>>>> os/v
>>>>>>>>>>> ideo
>>>>>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>>>
>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>> sequentially
>>>>>>>>>>> then at
>>>>>>>>>>> some point after few attempts I start to get those
>>>>>>>>>>> timeout
>>>>>>>>>>> errors.
>>>>>>>>>>>
>>>>>>>>>>>> 3. how about IRQ infos?
>>>>>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>>>>>> 18002000.vcodec   >> it's H.264 encoder
>>>>>>>>>>>> 19002000.vcodec  >> it's  VP8 encoder
>>>>>>>>>>>>
>>>>>>>>>>>> I was told you have  met another H.264 encoding
>>>>>>>>>>>> failed
>>>>>>>>>>>> before,
>>>>>>>>>>>> did you find reasons about that ?
>>>>>>>>>>>
>>>>>>>>>>> No,
>>>>>>>>>>> But since I see that the google meetup uses the vp8
>>>>>>>>>>> encoder
>>>>>>>>>>> I
>>>>>>>>>>> decided to test the vp8 first.
>>>>>>>>>>>
>>>>>>>>>>>>> [   81.918747] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx-
>>>>>>>>>>>>>> type=1,
>>>>>>>>>>>>> cmd=1,
>>>>>>>>>>>>> wait_event_interruptible_timeout time=1000ms
>>>>>>>>>>>>> out 0
>>>>>>>>>>>>> 0!
>>>>>>>>>>>>> [   81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>>>>>> h264_encode_frame()
>>>>>>>>>>>>> irq_status=0 failed
>>>>>>>>>>>>> [   81.938470] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_venc_worker:1219:
>>>>>>>>>>>>> venc_if_encode failed=-5
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I test the driver on debian now, I stream several
>>>>>>>>>> instances
>>>>>>>>>> of
>>>>>>>>>> vp8
>>>>>>>>>> and h264 in parallel.
>>>>>>>>>> I see that those errors always occur after an iommu
>>>>>>>>>> page
>>>>>>>>>> fault:
>>>>>>>>>>
>>>>>>>>>> [gst-master] root@debian:~/gst-build# [ 5743.206014]
>>>>>>>>>> mtk-
>>>>>>>>>> iommu
>>>>>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
>>>>>>>>>> larb=3
>>>>>>>>>> port=0
>>>>>>>>>> layer=1 write
>>>>>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>>>>>> [2706] ctx->type=1, cmd=1,
>>>>>>>>>> wait_event_interruptible_timeout
>>>>>>>>>> time=1000ms out 0 0!
>>>>>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>>>>>> vp8_enc_encode_frame()
>>>>>>>>>> irq_status=0 failed
>>>>>>>>>> [ 5744.225359] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_venc_worker:1243:
>>>>>>>>>> venc_if_encode
>>>>>>>>>> failed=-5
>>>>>>>>>>
>>>>>>>>>> I suspect that maybe this is because the iova of the
>>>>>>>>>> working_buffers
>>>>>>>>>> is handed to the vpu in the function
>>>>>>>>>> vp8_enc_alloc_work_buf:
>>>>>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>>>>>
>>>>>>>>>> Maybe the vpu keep writing to those addresses after
>>>>>>>>>> they
>>>>>>>>>> are
>>>>>>>>>> already
>>>>>>>>>> unmapped?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dafna
>>>>>>>>>
>>>>>>>>> failed larb=3, it's for h264 encoder,  vp8 encoder is
>>>>>>>>> larb5, is
>>>>>>>>> there
>>>>>>>>> any h264 encoding failed at that time? I have no ideas
>>>>>>>>> why
>>>>>>>>> these
>>>>>>>>> errors
>>>>>>>>> happened on your platform, but when we got the "iommu:
>>>>>>>>> fault",
>>>>>>>>> the
>>>>>>>>> possible reason is related to power or clock.
>>>>>>>>
>>>>>>>> Once the iommu fault fires, both encoders constantly fail
>>>>>>>> and
>>>>>>>> never
>>>>>>>> recover
>>>>>>>> (also not when starting new instance).
>>>>>>>>
>>>>>>>> With the falut:
>>>>>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0
>>>>>>>> larb=3
>>>>>>>> port=0
>>>>>>>> layer=1 write
>>>>>>>>
>>>>>>>> I looked at the iommu tracing log:
>>>>>>>>
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634398:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634417:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>>>>>> unmapped_size=20480
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.634435:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>>        gst-launch-1.0-606     [000] .N...   714.634891:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>>        gst-launch-1.0-606     [000] .N...   714.635481:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.635934:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636041:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636056:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>>        gst-launch-1.0-606     [000] .....   714.636069:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>>           kworker/0:0-537     [000] d.h..   714.636191:
>>>>>>>> io_page_fault:
>>>>>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>>>>>> flags=0x0001
>>>>>>>>
>>>>>>>> (I changed the iommu map/unmap trace events to print the
>>>>>>>> iova
>>>>>>>> range)
>>>>>>>> you can see the first line unmapping 00000000ebede000
>>>>>>>> which
>>>>>>>> is
>>>>>>>> the
>>>>>>>> faulting iova.
>>>>>>>> So it seems that the problem is due to a device trying to
>>>>>>>> access
>>>>>>>> an
>>>>>>>> address that is already unmapped.
>>>>>>>> This might be either the encoder or the vpu.
>>>>>>>> Since the wb[i].iova is not reset when freeing the
>>>>>>>> working
>>>>>>>> buffers I
>>>>>>>> suspect it might be the vpu device, what do you think?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>
>>>>>>> vpu device won't access the address, the fault logs:
>>>>>>
>>>>>>
>>>>>> Looking at the line:
>>>>>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>
>>>>>> in both vp8 and h264 it seems that the codec drivers give the
>>>>>> vpu
>>>>>> access to the allocated iova address.
>>>>>> If the vpu doesn't access those addresses then what is the
>>>>>> purpose of
>>>>>> this line?
>>>>>>
>>>>>
>>>>> "wb" is a shared buffer between AP-kernel and VPU firmware, to
>>>>> store
>>>>> these encoder working buffers informations, the architecture
>>>>> like
>>>>> this:
>>>>> 1. VPU firmware will set working buffers informations(size,
>>>>> iova(is
>>>>> 0
>>>>> now));
>>>>> 2. AP-kernel allocate these working buffers and get a truly
>>>>> memory(iova), so VPU firmware can get these wbs' iova after
>>>>> allocate
>>>>> done.
>>>>> 3. when encoding, these iova will set to encoder hardware in
>>>>> VPU
>>>>> firmware
>>>>> 4. encoder hardware can get the data from these "iova" to do
>>>>> encoding.
>>>>
>>>> ok, thanks for the explanation, so vpu firmware only hand the
>>>> iova
>>>> adresses further to the encoder hw but never access them itself?
>>>>
>>>>>
>>>>> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu
>>>>> driver
>>>>> ?
>>>>
>>>> yes,
>>>>
>>>>>
>>>>>>
>>>>>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
>>>>>>> write
>>>>>>>
>>>>>>> it's h264 encoder error when writing "RCPU" data address to
>>>>>>> encoder
>>>>>>> hardware through iommu, but why unmap happended at this
>>>>>>> time?
>>>>>>> it
>>>>>>> seems
>>>>>>> encoding process still going on....
>>>>>>
>>>>>> Why is it seems so?
>>>>>
>>>>> the fault means errors happended while reading prepared encode
>>>>> data, so
>>>>> I think encoding is still going on.
>>>>
>>>> I added more trace_printk debug, adding log before and after the
>>>> working buffers are freed: see 'BEFORE/AFTER' log
>>>>
>>>>      gst-launch-1.0-590     [000] .....   353.825276:
>>>> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>>>>      gst-launch-1.0-590     [000] .....   353.825282: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-590     [000] .....   353.825300: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
>>>> unmapped_size=20480
>>>>      gst-launch-1.0-590     [000] .....   353.825317: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-590     [000] .....   353.825740: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-590     [000] .....   353.825854: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
>>>> unmapped_size=3186688
>>>>      gst-launch-1.0-590     [000] .....   353.826273: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
>>>> unmapped_size=1044480
>>>>      gst-launch-1.0-590     [000] .....   353.826477: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-590     [000] .....   353.826494: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
>>>> unmapped_size=65536
>>>>      gst-launch-1.0-590     [000] .....   353.826507: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
>>>> unmapped_size=4096
>>>>      gst-launch-1.0-590     [000] .....   353.826515:
>>>> h264_enc_free_work_buf: h264 AFTER  unmapping work buffers
>>>>         kworker/0:3-67      [000] d.h..   353.826631:
>>>> io_page_fault:
>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003
>>>> flags=0x0001
>>>>
>>>> It is clear that the fault happen for the first working buffer
>>>> that
>>>> is unmapped, and the freeing of the working buffers happens only
>>>> after streaming is done in the '.deinit' cb of the encoder.
>>>
>>> no, free working buffers can also happen when streaming on after
>>> streaming off, call "set_param" again.

Still I can't think why would we have an encoded operation executing while buffers are freed,
all operations are protected with mtk_venc_lock.
Do you have any idea?


>>
>> There is actually a problem with the stream_start/stream_stop logic
>> It might cause asymetricall call to runtime_pm_put/get
>> I sent a patch fixing it, patch 2/3 in the series:
>>
>>
> https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0
>>
>> could you please review it?
>>
> Can this patch solve your current issues ?

This patch solves a different issue in this driver. (As I already described)

Thank you,
Dafna

> 
> 
>> I test my code with this patch applied,
>> that means that the working buffers are freed only upon deinit which
>> is only when streaming ends.
>>
>> Thanks,
>> Dafna
>>
>>>    
>>>> So it is clear that the encoder device writes to that working
>>>> buffer
>>>> that was just unmapped. Maybe it is a firmware bug?
>>>> Or Maybe the encoder should  indeed write to those buffers and
>>>> the
>>>> kernel should wait a while before freeing them?
>>>
>>> did you have tried patch:
>>>
>>>
> https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
>>
>> The patch is already in mainline, (so yes)
>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5
>>>>>>>>>>>> fdd8
>>>>>>>>>>>> 8b59
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I uses the latest firmware.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dafna
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>
>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>>> dafna.hirschfeld@collabora.com]
>>>>>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org
>>>>>>>>>>>> ;
>>>>>>>>>>>> linux-media@vger.kernel.org;
>>>>>>>>>>>> linux-mediatek@lists.infradead.org
>>>>>>>>>>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany
>>>>>>>>>>>> Lin
>>>>>>>>>>>> (林慧珊);
>>>>>>>>>>>> eizan@chromium.org; Maoguang Meng (孟毛广);
>>>>>>>>>>>> kernel@collabora.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei
>>>>>>>>>>>> Dong
>>>>>>>>>>>> (董云飞);
>>>>>>>>>>>> Yong
>>>>>>>>>>>> Wu
>>>>>>>>>>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> Andrew-CT
>>>>>>>>>>>> Chen
>>>>>>>>>>>> (陳智迪); acourbot@chromium.org
>>>>>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>>> error
>>>>>>>>>>>> cases
>>>>>>>>>>>> upon
>>>>>>>>>>>> vpu
>>>>>>>>>>>> irq handling
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna
>>>>>>>>>>>>> Hirschfeld
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 1. Fail if the function
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr
>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>> ERR
>>>>>>>>>>>>>> pointer.
>>>>>>>>>>>>>> 2. Fail if the state from the vpu msg is
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>>>>>> dafna.hirschfeld@collabora.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>         drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>>> 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ++++++++
>>>>>>>>>>>>>>         1 file changed, 8 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>>>>>> --- a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> +++ b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>>         vpu->vsi =
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr(vpu-
>>>>>>>>>>>>>>> ctx-
>>>>>>>>>>>>>>> dev-
>>>>>>>>>>>>>>> fw_handler,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              msg->vpu_inst_addr);
>>>>>>>>>>>>>>         
>>>>>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>>>>>         /* Firmware version field value is
>>>>>>>>>>>>>> unspecified
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> MT8173.
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>         if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>>>>>         return 0;
>>>>>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>>         vpu->state = msg->state;
>>>>>>>>>>>>>>         vpu->bs_size = msg->bs_size;
>>>>>>>>>>>>>>         vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>>>>>> +if (vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>>>>>> +    vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>>>>>> +       vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" :
>>>>>>>>>>>>>> "PART");
>>>>>>>>>>>>>> +return -EINVAL;
>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This state check is useless, the enc result
>>>>>>>>>>>>> will
>>>>>>>>>>>>> check
>>>>>>>>>>>>> in
>>>>>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>>>>>> vpu_enc_ipi_handler
>>>>>>>>>>>> only
>>>>>>>>>>>> test the msg->status and I see that the states
>>>>>>>>>>>> are
>>>>>>>>>>>> not
>>>>>>>>>>>> tested
>>>>>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>>>>>
>>>>>>>>>>>> Can't there be a scenario where msg->status is ok
>>>>>>>>>>>> but
>>>>>>>>>>>> the
>>>>>>>>>>>> state
>>>>>>>>>>>> is error?
>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and at
>>>>>>>>>>>> some
>>>>>>>>>>>> point
>>>>>>>>>>>> the
>>>>>>>>>>>> encoder interrupts stop arriving so I try to
>>>>>>>>>>>> figure
>>>>>>>>>>>> out
>>>>>>>>>>>> why
>>>>>>>>>>>> and
>>>>>>>>>>>> report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dafna
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>>         return 0;
>>>>>>>>>>>>>>         }
>>>>>>>>>>>>>>         
>>>>>>>>>>>>
>>>>>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>>>>>> ******************** The
>>>>>>>>>>>> information contained in this e-mail message
>>>>>>>>>>>> (including
>>>>>>>>>>>> any
>>>>>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>>>>>> privileged, or
>>>>>>>>>>>> otherwise exempt from disclosure under applicable
>>>>>>>>>>>> laws.
>>>>>>>>>>>> It is
>>>>>>>>>>>> intended
>>>>>>>>>>>> to be conveyed only to the designated
>>>>>>>>>>>> recipient(s).
>>>>>>>>>>>> Any
>>>>>>>>>>>> use,
>>>>>>>>>>>> dissemination, distribution, printing, retaining
>>>>>>>>>>>> or
>>>>>>>>>>>> copying
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-mail (including its
>>>>>>>>>>>> attachments) by unintended recipient(s) is
>>>>>>>>>>>> strictly
>>>>>>>>>>>> prohibited
>>>>>>>>>>>> and may
>>>>>>>>>>>> be unlawful. If you are not an intended recipient
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-
>>>>>>>>>>>> mail,
>>>>>>>>>>>> or
>>>>>>>>>>>> believe that you have received this e-mail in
>>>>>>>>>>>> error,
>>>>>>>>>>>> please
>>>>>>>>>>>> notify the
>>>>>>>>>>>> sender immediately (by replying to this e-mail),
>>>>>>>>>>>> delete
>>>>>>>>>>>> any
>>>>>>>>>>>> and
>>>>>>>>>>>> all
>>>>>>>>>>>> copies of this e-mail (including any attachments)
>>>>>>>>>>>> from
>>>>>>>>>>>> your
>>>>>>>>>>>> system,
>>>>>>>>>>>> and do not disclose the content of this e-mail to
>>>>>>>>>>>> any
>>>>>>>>>>>> other
>>>>>>>>>>>> person. Thank you!
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-mediatek mailing list
>>>>>>>>> Linux-mediatek@lists.infradead.org
>>>>>>>>>
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 11.08.21 13:43, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
> I suspect this issue happened because of power/clk  not working, Could you print some debug logs when call  pm_get_xxx/cll_prepare...

Hi, I noticed that the pm handling might be bugy. In the start_streaming cb , the pm_runtime_resume_and_get is called if both queues stream:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c#L803

Then in 'stop_streaming' "pm_runtime_put" is called if both queues are not streaming
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c#L893

that means that the 'pm_runtime_put' might be called even if "pm_runtime_resume_and_get" was not called (in case of start+stop only on one queue).
I thought that might be the bug, so I fixed it, but I still get the timeout errors.

> 
> 
> If the timeout issue also occurs with H.264 encoder,  you can confirm the H.264 timeout case, because:
> 1.  H.264 will encode Sequence header before encode Frame:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L411
> 
> it also will do " h264_enc_wait_venc_done " when encoding sps/pps,  and get timeout,  the error log has a little different with frams:. https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L371 :" expect irq status ..."
> 
> if encode frame wait IRQ timeout, the error log will be:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L471 : " irq_status=%d failed "
> 
> 2. you can check the timeout issue timing:
> header encode done, but encode frame get timeout, if so, maybe you need check the thing:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L297
> memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size)
> 
> you could save the content in the "va",  encoder hardware need load the data to encode frame, same as VP8:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c#L198
>   
> if the content is null, maybe something wrong happened about shared memory.

I tested only vp8 till now. What do you mean that the content is null? Do you mean that the shared mem buffer contains only zeros?

Thanks,
Dafna

> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月11日 18:14
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 11:12, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
>>
>>> The commands that I run is:
>>
>>>> sudo --user=#1000
>>>> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_test
>>>> s --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8
>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
>>>> /data/tulip2-320x180.yuv --disable_validator
>>
>>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
>>
>> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
>>
>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>
>> venc_sel   > it's H.264 clock
>> venclt_sel  > it's VP8 clock
>>
>> the enable&prepare count is not 0 during encoding process.
> 
> I see that the values are indeed incremented while streaming.
> When timeout occurs it is always in the beginning of the encoding. So upon the first call to vp8_enc_wait_venc_done.
> 
> Thanks,
> Dafna
> 
> 
>>
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月9日 16:27
>> 收件人: Irui Wang (王瑞)
>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support;
>> Enric Balletbo i Serra
>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>> vpu irq handling
>>
>>
>>
>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>> Hi Dafna,
>>>
>>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>> 1. Log shows wait IRQ timeout ?
>>
>> Hi, yes, I get timeout when waiting to the encoder interrupt. The
>> timeout is on vp8_enc_wait_venc_done
>>
>>
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
>>
>> The commands that I run is:
>>
>> sudo --user=#1000
>> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests
>> --gtest_filter=-*NV12Dmabuf*  --codec=vp8
>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/da
>> ta/tulip2-320x180.yuv --disable_validator
>>
>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
>>
>>> 3. how about IRQ infos?
>>> cat /proc/interrupts | grep vcodec
>>> 18002000.vcodec   >> it's H.264 encoder
>>> 19002000.vcodec  >> it's  VP8 encoder
>>>
>>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
>>
>> No,
>> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
>>
>>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5
>>
>>
>>>
>>> MT8173 latest VPUD firmware:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwa
>>> r
>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>
>>
>> I uses the latest firmware.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>> Best Regards
>>>
>>> -----邮件原件-----
>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>> 发送时间: 2021年8月6日 15:49
>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>>> (陳智迪); acourbot@chromium.org
>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>>> irq handling
>>>
>>>
>>>
>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>>> pointer.
>>>>> 2. Fail if the state from the vpu msg is either
>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>
>>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>>> ---
>>>>>     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>>     1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>>          msg->vpu_inst_addr);
>>>>>     
>>>>> +if (IS_ERR(vpu->vsi))
>>>>> +return PTR_ERR(vpu->vsi);
>>>>>     /* Firmware version field value is unspecified on MT8173. */
>>>>>     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>     return 0;
>>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>     vpu->state = msg->state;
>>>>>     vpu->bs_size = msg->bs_size;
>>>>>     vpu->is_key_frm = msg->is_key_frm;
>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>> +mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>>>>> +       vpu->state ==
>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>> +return -EINVAL;
>>>>> +}
>>>>
>>>> Hi Dafna,
>>>>
>>>> This state check is useless, the enc result will check in
>>>> "vpu_enc_ipi_handler".
>>>>
>>>
>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>>
>>> Can't there be a scenario where msg->status is ok but the state is error?
>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>>
>>> Thanks,
>>> Dafna
>>>
>>>> Thanks
>>>>
>>>>>     return 0;
>>>>>     }
>>>>>     
>>>
>>> ************* MEDIATEK Confidentiality Notice ********************
>>> The information contained in this e-mail message (including any
>>> attachments) may be confidential, proprietary, privileged, or
>>> otherwise exempt from disclosure under applicable laws. It is
>>> intended to be conveyed only to the designated recipient(s). Any use,
>>> dissemination, distribution, printing, retaining or copying of this
>>> e-mail (including its
>>> attachments) by unintended recipient(s) is strictly prohibited and
>>> may be unlawful. If you are not an intended recipient of this e-mail,
>>> or believe that you have received this e-mail in error, please notify
>>> the sender immediately (by replying to this e-mail), delete any and
>>> all copies of this e-mail (including any attachments) from your
>>> system, and do not disclose the content of this e-mail to any other person. Thank you!
>>>

Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Dafna Hirschfeld]

On 11.08.21 13:43, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
> I suspect this issue happened because of power/clk  not working, Could you print some debug logs when call  pm_get_xxx/cll_prepare...

Hi, I noticed that the pm handling might be bugy. In the start_streaming cb , the pm_runtime_resume_and_get is called if both queues stream:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c#L803

Then in 'stop_streaming' "pm_runtime_put" is called if both queues are not streaming
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c#L893

that means that the 'pm_runtime_put' might be called even if "pm_runtime_resume_and_get" was not called (in case of start+stop only on one queue).
I thought that might be the bug, so I fixed it, but I still get the timeout errors.

> 
> 
> If the timeout issue also occurs with H.264 encoder,  you can confirm the H.264 timeout case, because:
> 1.  H.264 will encode Sequence header before encode Frame:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L411
> 
> it also will do " h264_enc_wait_venc_done " when encoding sps/pps,  and get timeout,  the error log has a little different with frams:. https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L371 :" expect irq status ..."
> 
> if encode frame wait IRQ timeout, the error log will be:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L471 : " irq_status=%d failed "
> 
> 2. you can check the timeout issue timing:
> header encode done, but encode frame get timeout, if so, maybe you need check the thing:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L297
> memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size)
> 
> you could save the content in the "va",  encoder hardware need load the data to encode frame, same as VP8:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c#L198
>   
> if the content is null, maybe something wrong happened about shared memory.

I tested only vp8 till now. What do you mean that the content is null? Do you mean that the shared mem buffer contains only zeros?

Thanks,
Dafna

> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月11日 18:14
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
> 主题: Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
> 
> 
> 
> On 09.08.21 11:12, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
>>
>>> The commands that I run is:
>>
>>>> sudo --user=#1000
>>>> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_test
>>>> s --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8
>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
>>>> /data/tulip2-320x180.yuv --disable_validator
>>
>>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
>>
>> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
>>
>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>
>> venc_sel   > it's H.264 clock
>> venclt_sel  > it's VP8 clock
>>
>> the enable&prepare count is not 0 during encoding process.
> 
> I see that the values are indeed incremented while streaming.
> When timeout occurs it is always in the beginning of the encoding. So upon the first call to vp8_enc_wait_venc_done.
> 
> Thanks,
> Dafna
> 
> 
>>
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月9日 16:27
>> 收件人: Irui Wang (王瑞)
>> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support;
>> Enric Balletbo i Serra
>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon
>> vpu irq handling
>>
>>
>>
>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>> Hi Dafna,
>>>
>>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>> 1. Log shows wait IRQ timeout ?
>>
>> Hi, yes, I get timeout when waiting to the encoder interrupt. The
>> timeout is on vp8_enc_wait_venc_done
>>
>>
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
>>
>> The commands that I run is:
>>
>> sudo --user=#1000
>> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests
>> --gtest_filter=-*NV12Dmabuf*  --codec=vp8
>> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/da
>> ta/tulip2-320x180.yuv --disable_validator
>>
>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
>>
>>> 3. how about IRQ infos?
>>> cat /proc/interrupts | grep vcodec
>>> 18002000.vcodec   >> it's H.264 encoder
>>> 19002000.vcodec  >> it's  VP8 encoder
>>>
>>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
>>
>> No,
>> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
>>
>>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5
>>
>>
>>>
>>> MT8173 latest VPUD firmware:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwa
>>> r
>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>>
>>
>> I uses the latest firmware.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>> Best Regards
>>>
>>> -----邮件原件-----
>>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>>> 发送时间: 2021年8月6日 15:49
>>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org;
>>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com;
>>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>>> (陳智迪); acourbot@chromium.org
>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu
>>> irq handling
>>>
>>>
>>>
>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR
>>>>> pointer.
>>>>> 2. Fail if the state from the vpu msg is either
>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>>
>>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>>> ---
>>>>>     drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>>     1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct
>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>     vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>>          msg->vpu_inst_addr);
>>>>>     
>>>>> +if (IS_ERR(vpu->vsi))
>>>>> +return PTR_ERR(vpu->vsi);
>>>>>     /* Firmware version field value is unspecified on MT8173. */
>>>>>     if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>>     return 0;
>>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct
>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>     vpu->state = msg->state;
>>>>>     vpu->bs_size = msg->bs_size;
>>>>>     vpu->is_key_frm = msg->is_key_frm;
>>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) {
>>>>> +mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>>>>> +       vpu->state ==
>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>>> +return -EINVAL;
>>>>> +}
>>>>
>>>> Hi Dafna,
>>>>
>>>> This state check is useless, the enc result will check in
>>>> "vpu_enc_ipi_handler".
>>>>
>>>
>>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>>
>>> Can't there be a scenario where msg->status is ok but the state is error?
>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>>
>>> Thanks,
>>> Dafna
>>>
>>>> Thanks
>>>>
>>>>>     return 0;
>>>>>     }
>>>>>     
>>>
>>> ************* MEDIATEK Confidentiality Notice ********************
>>> The information contained in this e-mail message (including any
>>> attachments) may be confidential, proprietary, privileged, or
>>> otherwise exempt from disclosure under applicable laws. It is
>>> intended to be conveyed only to the designated recipient(s). Any use,
>>> dissemination, distribution, printing, retaining or copying of this
>>> e-mail (including its
>>> attachments) by unintended recipient(s) is strictly prohibited and
>>> may be unlawful. If you are not an intended recipient of this e-mail,
>>> or believe that you have received this e-mail in error, please notify
>>> the sender immediately (by replying to this e-mail), delete any and
>>> all copies of this e-mail (including any attachments) from your
>>> system, and do not disclose the content of this e-mail to any other person. Thank you!
>>>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling

[Irui Wang (王瑞)]

Hi Dafna,

I suspect this issue happened because of power/clk  not working, Could you print some debug logs when call  pm_get_xxx/cll_prepare...


If the timeout issue also occurs with H.264 encoder,  you can confirm the H.264 timeout case, because:
1.  H.264 will encode Sequence header before encode Frame:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L411

it also will do " h264_enc_wait_venc_done " when encoding sps/pps,  and get timeout,  the error log has a little different with frams:. https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L371 :" expect irq status ..."

if encode frame wait IRQ timeout, the error log will be:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L471 : " irq_status=%d failed "

2. you can check the timeout issue timing:
header encode done, but encode frame get timeout, if so, maybe you need check the thing:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c#L297
memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size)

you could save the content in the "va",  encoder hardware need load the data to encode frame, same as VP8:
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c#L198
 
if the content is null, maybe something wrong happened about shared memory.

Thanks
Best Regards

-----邮件原件-----
发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com] 
发送时间: 2021年8月11日 18:14
收件人: Irui Wang (王瑞)
抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; Enric Balletbo i Serra
主题: Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling



On 09.08.21 11:12, Irui Wang (王瑞) wrote:
> Hi Dafna,
> 
>>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
>> The commands that I run is:
> 
>>> sudo --user=#1000 
>>> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_test
>>> s --gtest_filter=-*NV12Dmabuf*  -->>codec=vp8 
>>> >/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video
>>> /data/tulip2-320x180.yuv --disable_validator
> 
>>> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
> It seems mean VP8 encoding function OK, but failed sometimes, did you have check VENC clock info during encoding:
> 
> cat /sys/kernel/debug/clk/clk_summary | grep venc:
> 
> venc_sel   > it's H.264 clock
> venclt_sel  > it's VP8 clock
> 
> the enable&prepare count is not 0 during encoding process.

I see that the values are indeed incremented while streaming.
When timeout occurs it is always in the beginning of the encoding. So upon the first call to vp8_enc_wait_venc_done.

Thanks,
Dafna


> 
> Thanks
> Best Regards
> 
> -----邮件原件-----
> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
> 发送时间: 2021年8月9日 16:27
> 收件人: Irui Wang (王瑞)
> 抄送: Linux Media Mailing List; moderated list:ARM/Mediatek SoC support; 
> Enric Balletbo i Serra
> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon 
> vpu irq handling
> 
> 
> 
> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>> Hi Dafna,
>>
>>>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>> 1. Log shows wait IRQ timeout ?
> 
> Hi, yes, I get timeout when waiting to the encoder interrupt. The 
> timeout is on vp8_enc_wait_venc_done
> 
> 
>> 2. Always happened  issue ?  timeout at the beginning or  in processing ?
> 
> The commands that I run is:
> 
> sudo --user=#1000 
> /usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests 
> --gtest_filter=-*NV12Dmabuf*  --codec=vp8 
> /usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/da
> ta/tulip2-320x180.yuv --disable_validator
> 
> The command sometime succeed but when I run it sequentially then at some point after few attempts I start to get those timeout errors.
> 
>> 3. how about IRQ infos?
>> cat /proc/interrupts | grep vcodec
>> 18002000.vcodec   >> it's H.264 encoder
>> 19002000.vcodec  >> it's  VP8 encoder
>>
>> I was told you have  met another H.264 encoding failed before, did you find reasons about that ?
> 
> No,
> But since I see that the google meetup uses the vp8 encoder I decided to test the vp8 first.
> 
>>> [   81.918747] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [3] ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
>>> [   81.931392] [MTK_VCODEC][ERROR][3]: h264_encode_frame() irq_status=0 failed
>>> [   81.938470] [MTK_V4L2][ERROR] mtk_venc_worker:1219: venc_if_encode failed=-5
> 
> 
>>
>> MT8173 latest VPUD firmware:
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwa
>> r
>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5fdd88b59
>>
> 
> I uses the latest firmware.
> 
> Thanks,
> Dafna
> 
>> Thanks
>> Best Regards
>>
>> -----邮件原件-----
>> 发件人: Dafna Hirschfeld [mailto:dafna.hirschfeld@collabora.com]
>> 发送时间: 2021年8月6日 15:49
>> 收件人: Irui Wang (王瑞); linux-kernel@vger.kernel.org; 
>> linux-media@vger.kernel.org; linux-mediatek@lists.infradead.org
>> 抄送: dafna3@gmail.com; tfiga@chromium.org; Tiffany Lin (林慧珊);
>> eizan@chromium.org; Maoguang Meng (孟毛广); kernel@collabora.com; 
>> mchehab@kernel.org; hverkuil@xs4all.nl; Yunfei Dong (董云飞); Yong Wu
>> (吴勇); hsinyi@chromium.org; matthias.bgg@gmail.com; Andrew-CT Chen
>> (陳智迪); acourbot@chromium.org
>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu 
>> irq handling
>>
>>
>>
>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna Hirschfeld wrote:
>>>> 1. Fail if the function mtk_vcodec_fw_map_dm_addr returns ERR 
>>>> pointer.
>>>> 2. Fail if the state from the vpu msg is either 
>>>> VEN_IPI_MSG_ENC_STATE_ERROR or VEN_IPI_MSG_ENC_STATE_PART
>>>>
>>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
>>>> ---
>>>>    drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>> --- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> +++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
>>>> @@ -17,6 +17,8 @@ static int handle_enc_init_msg(struct 
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
>>>>         msg->vpu_inst_addr);
>>>>    
>>>> +if (IS_ERR(vpu->vsi))
>>>> +return PTR_ERR(vpu->vsi);
>>>>    /* Firmware version field value is unspecified on MT8173. */
>>>>    if (vpu->ctx->dev->venc_pdata->chip == MTK_MT8173)
>>>>    return 0;
>>>> @@ -42,6 +44,12 @@ static int handle_enc_encode_msg(struct 
>>>> venc_vpu_inst *vpu, const void *data)
>>>>    vpu->state = msg->state;
>>>>    vpu->bs_size = msg->bs_size;
>>>>    vpu->is_key_frm = msg->is_key_frm;
>>>> +if (vpu->state == VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>> +    vpu->state == VEN_IPI_MSG_ENC_STATE_PART) { 
>>>> +mtk_vcodec_err(vpu, "bad ipi-enc-state: %s",
>>>> +       vpu->state ==
>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" : "PART");
>>>> +return -EINVAL;
>>>> +}
>>>
>>> Hi Dafna,
>>>
>>> This state check is useless, the enc result will check in 
>>> "vpu_enc_ipi_handler".
>>>
>>
>> Hi, thanks for reviewing. I see that the vpu_enc_ipi_handler only test the msg->status and I see that the states are not tested anywhere except of "skip" state in the h264 enc.
>>
>> Can't there be a scenario where msg->status is ok but the state is error?
>> I am testing the vp8 encoder on chromeos and at some point the encoder interrupts stop arriving so I try to figure out why and report any possible error.
>>
>> Thanks,
>> Dafna
>>
>>> Thanks
>>>
>>>>    return 0;
>>>>    }
>>>>    
>>
>> ************* MEDIATEK Confidentiality Notice ******************** 
>> The information contained in this e-mail message (including any
>> attachments) may be confidential, proprietary, privileged, or 
>> otherwise exempt from disclosure under applicable laws. It is 
>> intended to be conveyed only to the designated recipient(s). Any use, 
>> dissemination, distribution, printing, retaining or copying of this 
>> e-mail (including its
>> attachments) by unintended recipient(s) is strictly prohibited and 
>> may be unlawful. If you are not an intended recipient of this e-mail, 
>> or believe that you have received this e-mail in error, please notify 
>> the sender immediately (by replying to this e-mail), delete any and 
>> all copies of this e-mail (including any attachments) from your 
>> system, and do not disclose the content of this e-mail to any other person. Thank you!
>>