From: Yunfei Dong <yunfei.dong@mediatek.com>
To: "Chen-Yu Tsai" <wenst@chromium.org>,
"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>,
"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
"Nathan Hebert" <nhebert@chromium.org>
Cc: Yunfei Dong <yunfei.dong@mediatek.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Fritz Koenig <frkoenig@chromium.org>,
Daniel Vetter <daniel@ffwll.ch>,
Steve Cho <stevecho@chromium.org>, <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 v4,2/4] media: mediatek: vcodec: using decoder status instead of core work count
Date: Thu, 25 May 2023 09:40:07 +0800 [thread overview]
Message-ID: <20230525014009.23345-3-yunfei.dong@mediatek.com> (raw)
In-Reply-To: <20230525014009.23345-1-yunfei.dong@mediatek.com>
Adding the definition of decoder status to separate different decoder
period for core hardware.
core_work_cnt is the number of core work queued to work queue, the control
is very complex, leading to some unreasonable test result.
Using parameter status to indicate whether queue core work to work queue.
Fixes: 2e0ef56d81cb ("media: mediatek: vcodec: making sure queue_work successfully")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../platform/mediatek/vcodec/vdec_msg_queue.c | 33 ++++++++-----------
.../platform/mediatek/vcodec/vdec_msg_queue.h | 16 +++++++--
2 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.c b/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.c
index f3073d1e7f42..03f8d7cd8edd 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.c
+++ b/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.c
@@ -71,7 +71,6 @@ static void vdec_msg_queue_dec(struct vdec_msg_queue *msg_queue, int hardware_in
int vdec_msg_queue_qbuf(struct vdec_msg_queue_ctx *msg_ctx, struct vdec_lat_buf *buf)
{
struct list_head *head;
- int status;
head = vdec_get_buf_list(msg_ctx->hardware_index, buf);
if (!head) {
@@ -87,12 +86,9 @@ int vdec_msg_queue_qbuf(struct vdec_msg_queue_ctx *msg_ctx, struct vdec_lat_buf
if (msg_ctx->hardware_index != MTK_VDEC_CORE) {
wake_up_all(&msg_ctx->ready_to_use);
} else {
- if (buf->ctx->msg_queue.core_work_cnt <
- atomic_read(&buf->ctx->msg_queue.core_list_cnt)) {
- status = queue_work(buf->ctx->dev->core_workqueue,
- &buf->ctx->msg_queue.core_work);
- if (status)
- buf->ctx->msg_queue.core_work_cnt++;
+ if (!(buf->ctx->msg_queue.status & CONTEXT_LIST_QUEUED)) {
+ queue_work(buf->ctx->dev->core_workqueue, &buf->ctx->msg_queue.core_work);
+ buf->ctx->msg_queue.status |= CONTEXT_LIST_QUEUED;
}
}
@@ -261,7 +257,10 @@ static void vdec_msg_queue_core_work(struct work_struct *work)
container_of(msg_queue, struct mtk_vcodec_ctx, msg_queue);
struct mtk_vcodec_dev *dev = ctx->dev;
struct vdec_lat_buf *lat_buf;
- int status;
+
+ spin_lock(&ctx->dev->msg_queue_core_ctx.ready_lock);
+ ctx->msg_queue.status &= ~CONTEXT_LIST_QUEUED;
+ spin_unlock(&ctx->dev->msg_queue_core_ctx.ready_lock);
lat_buf = vdec_msg_queue_dqbuf(&dev->msg_queue_core_ctx);
if (!lat_buf)
@@ -278,17 +277,13 @@ static void vdec_msg_queue_core_work(struct work_struct *work)
vdec_msg_queue_qbuf(&ctx->msg_queue.lat_ctx, lat_buf);
wake_up_all(&ctx->msg_queue.core_dec_done);
- spin_lock(&dev->msg_queue_core_ctx.ready_lock);
- lat_buf->ctx->msg_queue.core_work_cnt--;
-
- if (lat_buf->ctx->msg_queue.core_work_cnt <
- atomic_read(&lat_buf->ctx->msg_queue.core_list_cnt)) {
- status = queue_work(lat_buf->ctx->dev->core_workqueue,
- &lat_buf->ctx->msg_queue.core_work);
- if (status)
- lat_buf->ctx->msg_queue.core_work_cnt++;
+ if (!(ctx->msg_queue.status & CONTEXT_LIST_QUEUED) &&
+ atomic_read(&msg_queue->core_list_cnt)) {
+ spin_lock(&ctx->dev->msg_queue_core_ctx.ready_lock);
+ ctx->msg_queue.status |= CONTEXT_LIST_QUEUED;
+ spin_unlock(&ctx->dev->msg_queue_core_ctx.ready_lock);
+ queue_work(ctx->dev->core_workqueue, &msg_queue->core_work);
}
- spin_unlock(&dev->msg_queue_core_ctx.ready_lock);
}
int vdec_msg_queue_init(struct vdec_msg_queue *msg_queue,
@@ -303,13 +298,13 @@ int vdec_msg_queue_init(struct vdec_msg_queue *msg_queue,
return 0;
msg_queue->ctx = ctx;
- msg_queue->core_work_cnt = 0;
vdec_msg_queue_init_ctx(&msg_queue->lat_ctx, MTK_VDEC_LAT0);
INIT_WORK(&msg_queue->core_work, vdec_msg_queue_core_work);
atomic_set(&msg_queue->lat_list_cnt, 0);
atomic_set(&msg_queue->core_list_cnt, 0);
init_waitqueue_head(&msg_queue->core_dec_done);
+ msg_queue->status = CONTEXT_LIST_EMPTY;
msg_queue->wdma_addr.size =
vde_msg_queue_get_trans_size(ctx->picinfo.buf_w,
diff --git a/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.h b/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.h
index a5d44bc97c16..8f82d1484772 100644
--- a/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.h
+++ b/drivers/media/platform/mediatek/vcodec/vdec_msg_queue.h
@@ -21,6 +21,18 @@ struct mtk_vcodec_ctx;
struct mtk_vcodec_dev;
typedef int (*core_decode_cb_t)(struct vdec_lat_buf *lat_buf);
+/**
+ * enum core_ctx_status - Context decode status for core hardwre.
+ * @CONTEXT_LIST_EMPTY: No buffer queued on core hardware(must always be 0)
+ * @CONTEXT_LIST_QUEUED: Buffer queued to core work list
+ * @CONTEXT_LIST_DEC_DONE: context decode done
+ */
+enum core_ctx_status {
+ CONTEXT_LIST_EMPTY = 0,
+ CONTEXT_LIST_QUEUED,
+ CONTEXT_LIST_DEC_DONE,
+};
+
/**
* struct vdec_msg_queue_ctx - represents a queue for buffers ready to be processed
* @ready_to_use: ready used queue used to signalize when get a job queue
@@ -77,7 +89,7 @@ struct vdec_lat_buf {
* @lat_list_cnt: used to record each instance lat list count
* @core_list_cnt: used to record each instance core list count
* @core_dec_done: core work queue decode done event
- * @core_work_cnt: the number of core work in work queue
+ * @status: current context decode status for core hardware
*/
struct vdec_msg_queue {
struct vdec_lat_buf lat_buf[NUM_BUFFER_COUNT];
@@ -93,7 +105,7 @@ struct vdec_msg_queue {
atomic_t lat_list_cnt;
atomic_t core_list_cnt;
wait_queue_head_t core_dec_done;
- int core_work_cnt;
+ int status;
};
/**
--
2.18.0
next prev parent reply other threads:[~2023-05-25 1:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 1:40 [PATCH v4,0/4] media: mediatek: vcodec: Fix decoder under flow and plt test fails randomly Yunfei Dong
2023-05-25 1:40 ` [PATCH v4,1/4] media: mediatek: vcodec: Avoid unneeded error logging Yunfei Dong
2023-05-25 8:11 ` AngeloGioacchino Del Regno
2023-06-07 4:16 ` Fei Shao
2023-05-25 1:40 ` Yunfei Dong [this message]
2023-05-25 8:12 ` [PATCH v4,2/4] media: mediatek: vcodec: using decoder status instead of core work count AngeloGioacchino Del Regno
2023-05-25 1:40 ` [PATCH v4,3/4] media: mediatek: vcodec: move core context from device to each instance Yunfei Dong
2023-05-25 8:12 ` AngeloGioacchino Del Regno
2023-06-09 19:50 ` Nícolas F. R. A. Prado
2023-05-25 1:40 ` [PATCH v4,4/4] media: mediatek: vcodec: using empty lat buffer as the last one Yunfei Dong
2023-05-25 8:12 ` AngeloGioacchino Del Regno
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=20230525014009.23345-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=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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).