[1/6] media: mediatek: vcodec: can`t regard getting lat buffer fail as error

Message ID 20230417054816.17097-2-yunfei.dong@mediatek.com
State New
Headers
Series media: mediatek: vcodec: Fix decoder under flow and plt test fails randomly |

Commit Message

Yunfei Dong (董云飞) April 17, 2023, 5:48 a.m. UTC
  The speed of lat decoder is much faster than core, need to get trans
buffer again when lat fail to get trans buffer.

Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
 .../media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c   | 2 +-
 .../platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c      | 2 +-
 .../media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
  

Comments

AngeloGioacchino Del Regno April 17, 2023, 9:18 a.m. UTC | #1
Il 17/04/23 07:48, Yunfei Dong ha scritto:
> The speed of lat decoder is much faster than core, need to get trans
> buffer again when lat fail to get trans buffer.
> 

The commit description is misleading, looks like you're doing functional
changes, but you're just changing loglevels... and the title is also a
little confusing, so.. I would propose:

media: mediatek: vcodec: Avoid unneeded error logging

Since the LAT decoder works faster than its CORE, getting the trans buffer may
be done only after CORE finishes processing: avoid printing an error if the
decode function returns -EAGAIN, as this means that the buffer from CORE is not
yet available, but will be at a later time.

Also change the log level for calls to vdec_msg_queue_dqbuf() in H264 and VP9
LAT decoder drivers to avoid excessive logging.

Cheers,
Angelo
  
Yunfei Dong (董云飞) April 17, 2023, 12:09 p.m. UTC | #2
Hi AngeloGioacchino,

Thanks for your suggestion.
On Mon, 2023-04-17 at 11:18 +0200, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Il 17/04/23 07:48, Yunfei Dong ha scritto:
> > The speed of lat decoder is much faster than core, need to get
> > trans
> > buffer again when lat fail to get trans buffer.
> > 
> 
> The commit description is misleading, looks like you're doing
> functional
> changes, but you're just changing loglevels... and the title is also
> a
> little confusing, so.. I would propose:
> 
> media: mediatek: vcodec: Avoid unneeded error logging
> 
> Since the LAT decoder works faster than its CORE, getting the trans
> buffer may
> be done only after CORE finishes processing: avoid printing an error
> if the
> decode function returns -EAGAIN, as this means that the buffer from
> CORE is not
> yet available, but will be at a later time.
> 
> Also change the log level for calls to vdec_msg_queue_dqbuf() in H264
> and VP9
> LAT decoder drivers to avoid excessive logging.
> 

Fixed in patch v2.

> Cheers,
> Angelo
> 
Best Regards,
Yunfei Dong
> 
>
  

Patch

diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
index 3000db975e5f..0c2ef1686397 100644
--- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
@@ -240,7 +240,7 @@  static void mtk_vdec_worker(struct work_struct *work)
 		mtk_v4l2_err("vb2 buffer media request is NULL");
 
 	ret = vdec_if_decode(ctx, bs_src, NULL, &res_chg);
-	if (ret) {
+	if (ret && ret != -EAGAIN) {
 		mtk_v4l2_err(" <===[%d], src_buf[%d] sz=0x%zx pts=%llu vdec_if_decode() ret=%d res_chg=%d===>",
 			     ctx->id, vb2_src->index, bs_src->size,
 			     vb2_src->timestamp, ret, res_chg);
diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
index 999ce7ee5fdc..181cc52e0847 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
@@ -596,7 +596,7 @@  static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 
 	lat_buf = vdec_msg_queue_dqbuf(&inst->ctx->msg_queue.lat_ctx);
 	if (!lat_buf) {
-		mtk_vcodec_err(inst, "failed to get lat buffer");
+		mtk_vcodec_debug(inst, "failed to get lat buffer");
 		return -EAGAIN;
 	}
 	share_info = lat_buf->private_data;
diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
index cf16cf2807f0..6d981d7341d2 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -2069,7 +2069,7 @@  static int vdec_vp9_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 
 	lat_buf = vdec_msg_queue_dqbuf(&instance->ctx->msg_queue.lat_ctx);
 	if (!lat_buf) {
-		mtk_vcodec_err(instance, "Failed to get VP9 lat buf\n");
+		mtk_vcodec_debug(instance, "Failed to get VP9 lat buf\n");
 		return -EAGAIN;
 	}
 	pfc = (struct vdec_vp9_slice_pfc *)lat_buf->private_data;