From: Yunfei Dong <yunfei.dong@mediatek.com>
To: "Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
"Sebastian Fricke" <sebastian.fricke@collabora.com>,
"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
"Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Nathan Hebert" <nhebert@chromium.org>
Cc: Hsin-Yi Wang <hsinyi@chromium.org>,
Chen-Yu Tsai <wenst@chromium.org>,
Fritz Koenig <frkoenig@chromium.org>,
Daniel Vetter <daniel@ffwll.ch>,
Steve Cho <stevecho@chromium.org>,
Yunfei Dong <yunfei.dong@mediatek.com>,
<linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: [PATCH v6 2/5] media: mediatek: vcodec: change flush decode order when stream off
Date: Fri, 8 Nov 2024 11:32:11 +0800 [thread overview]
Message-ID: <20241108033219.19804-3-yunfei.dong@mediatek.com> (raw)
In-Reply-To: <20241108033219.19804-1-yunfei.dong@mediatek.com>
The driver status is set to flush when flush_decoder is called.
The order of STREAMOFF ioctl for OUTPUT and CAPTURE are randomly.
If flush_decoder is called in STREAMOFF for capture queue always,
leading to get NULL dst buffer when calling STREAMOFF for output
queue before capture queue.
Need to flush decoder when stream off no matter output or capture
queue is called firstly.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 44 +++++++++----------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index 2b787e60a1f9..fc4ee1fb7cd1 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -882,27 +882,11 @@ void vb2ops_vdec_stop_streaming(struct vb2_queue *q)
mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) state=(%x) ctx->decoded_frame_cnt=%d",
ctx->id, q->type, ctx->state, ctx->decoded_frame_cnt);
- if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
- while ((src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx))) {
- if (src_buf != &ctx->empty_flush_buf.vb) {
- struct media_request *req =
- src_buf->vb2_buf.req_obj.req;
-
- if (req)
- v4l2_ctrl_request_complete(req, &ctx->ctrl_hdl);
- v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
- }
- }
- return;
- }
-
- if (ctx->state >= MTK_STATE_HEADER) {
-
- /* Until STREAMOFF is called on the CAPTURE queue
- * (acknowledging the event), the driver operates
- * as if the resolution hasn't changed yet, i.e.
- * VIDIOC_G_FMT< etc. return previous resolution.
- * So we update picinfo here
+ if (ctx->state >= MTK_STATE_HEADER && ctx->state != MTK_STATE_FLUSH) {
+ /*
+ * The resolution hasn't been changed when STREAMOFF is called.
+ * Update the picinfo here with previous resolution if VIDIOC_G_FMT
+ * is called.
*/
ctx->picinfo = ctx->last_decoded_picinfo;
@@ -917,8 +901,24 @@ void vb2ops_vdec_stop_streaming(struct vb2_queue *q)
ret = ctx->dev->vdec_pdata->flush_decoder(ctx);
if (ret)
mtk_v4l2_vdec_err(ctx, "DecodeFinal failed, ret=%d", ret);
+
+ ctx->state = MTK_STATE_FLUSH;
+ }
+
+ if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ while ((src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx))) {
+ if (src_buf != &ctx->empty_flush_buf.vb) {
+ struct media_request *req =
+ src_buf->vb2_buf.req_obj.req;
+
+ if (req)
+ v4l2_ctrl_request_complete(req, &ctx->ctrl_hdl);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ }
+ }
+
+ return;
}
- ctx->state = MTK_STATE_FLUSH;
while ((dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx))) {
vb2_set_plane_payload(&dst_buf->vb2_buf, 0, 0);
--
2.46.0
next prev parent reply other threads:[~2024-11-08 3:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 3:32 [PATCH v6 0/5] media: mediatek: vcodec: fix v4l2_ctrl_request_complete fail Yunfei Dong
2024-11-08 3:32 ` [PATCH v6 1/5] media: mediatek: vcodec: setting request complete before buffer done Yunfei Dong
2024-11-08 7:49 ` Chen-Yu Tsai
2024-11-08 8:18 ` Sebastian Fricke
2024-11-08 8:50 ` Chen-Yu Tsai
2024-11-08 13:42 ` Nicolas Dufresne
2024-11-11 7:40 ` Chen-Yu Tsai
2024-11-13 16:37 ` Nicolas Dufresne
2024-11-08 3:32 ` Yunfei Dong [this message]
2024-11-08 3:32 ` [PATCH v6 3/5] media: mediatek: vcodec: Get SRC buffer from bitstream instead of M2M Yunfei Dong
2024-11-08 4:20 ` Chen-Yu Tsai
2024-11-08 3:32 ` [PATCH v6 4/5] media: mediatek: vcodec: store current vb2 buffer to decode again Yunfei Dong
2024-11-08 8:16 ` Chen-Yu Tsai
2024-11-08 3:32 ` [PATCH v6 5/5] media: mediatek: vcodec: remove media request checking Yunfei Dong
2024-11-08 6:02 ` Chen-Yu Tsai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241108033219.19804-3-yunfei.dong@mediatek.com \
--to=yunfei.dong@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=frkoenig@chromium.org \
--cc=hsinyi@chromium.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=nfraprado@collabora.com \
--cc=nhebert@chromium.org \
--cc=nicolas.dufresne@collabora.com \
--cc=sebastian.fricke@collabora.com \
--cc=stevecho@chromium.org \
--cc=wenst@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®