From: "Yunfei Dong (董云飞)" <Yunfei.Dong@mediatek.com>
To: "sebastian.fricke@collabora.com" <sebastian.fricke@collabora.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"frkoenig@chromium.org" <frkoenig@chromium.org>,
"stevecho@chromium.org" <stevecho@chromium.org>,
"nhebert@chromium.org" <nhebert@chromium.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"nicolas.dufresne@collabora.com" <nicolas.dufresne@collabora.com>,
"daniel.almeida@collabora.com" <daniel.almeida@collabora.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"benjamin.gaignard@collabora.com"
<benjamin.gaignard@collabora.com>,
"hverkuil-cisco@xs4all.nl" <hverkuil-cisco@xs4all.nl>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"hsinyi@chromium.org" <hsinyi@chromium.org>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>,
"nfraprado@collabora.com" <nfraprado@collabora.com>
Subject: Re: [PATCH v4 4/7] media: mediatek: vcodec: using input information to get vb2 buffer
Date: Tue, 27 Aug 2024 02:47:01 +0000 [thread overview]
Message-ID: <42c93832976240bc1fad68b5e606152a16b1de9f.camel@mediatek.com> (raw)
In-Reply-To: <20240823124023.uhypfcixfsget26q@basti-XPS-13-9310>
Hi Sebastian,
Thanks for your suggestion.
On Fri, 2024-08-23 at 14:40 +0200, Sebastian Fricke wrote:
> Hey Yunfei,
>
> I would rename the title to something like this:
>
> media: mediatek: vcodec: Get SRC buffer from bitstream instead of M2M
>
> On 07.08.2024 16:24, Yunfei Dong wrote:
> > vb2 buffer may be removed from ready list when lat try to get next
> > src buffer, leading to vb2 buffer not the current one. Need to get
> > vb2 buffer according to current input memory information.
>
> And I would rewrite the commit log like this:
>
> Getting the SRC buffer from the M2M buffer-queue risks picking a
> different SRC buffer than the one used for the current decode
> operation.
> Get the SRC buffer therefore from the bitstream data, which was set
> up
> earlier during the decode.
>
> Did I get that right?
>
> Also could you explain why this change is required in this series?
>
Must make sure the src buffer is removed from ready list, in case of
the buffer is removed when core work try to set the buffer done.
Best Regards,
Yunfei Dong
> Regards,
> Sebastian Fricke
>
> >
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> > .../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 13 +++++++-----
> > -
> > .../vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 15 +++++++-----
> > ---
> > 2 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_
> > lat_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_
> > lat_if.c
> > index 90217cc8e242..a744740ba5f1 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_
> > lat_if.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_
> > lat_if.c
> > @@ -1062,19 +1062,20 @@ static inline void
> > vdec_av1_slice_vsi_to_remote(struct vdec_av1_slice_vsi *vsi,
> >
> > static int vdec_av1_slice_setup_lat_from_src_buf(struct
> > vdec_av1_slice_instance *instance,
> > struct
> > vdec_av1_slice_vsi *vsi,
> > + struct mtk_vcodec_mem
> > *bs,
> > struct vdec_lat_buf
> > *lat_buf)
> > {
> > - struct vb2_v4l2_buffer *src;
> > + struct mtk_video_dec_buf *src_buf_info;
> > struct vb2_v4l2_buffer *dst;
> >
> > - src = v4l2_m2m_next_src_buf(instance->ctx->m2m_ctx);
> > - if (!src)
> > + src_buf_info = container_of(bs, struct mtk_video_dec_buf,
> > bs_buffer);
> > + if (!src_buf_info)
> > return -EINVAL;
> >
> > - lat_buf->vb2_v4l2_src = src;
> > + lat_buf->vb2_v4l2_src = &src_buf_info->m2m_buf.vb;
> >
> > dst = &lat_buf->ts_info;
> > - v4l2_m2m_buf_copy_metadata(src, dst, true);
> > + v4l2_m2m_buf_copy_metadata(lat_buf->vb2_v4l2_src, dst, true);
> > vsi->frame.cur_ts = dst->vb2_buf.timestamp;
> >
> > return 0;
> > @@ -1724,7 +1725,7 @@ static int vdec_av1_slice_setup_lat(struct
> > vdec_av1_slice_instance *instance,
> > struct vdec_av1_slice_vsi *vsi = &pfc->vsi;
> > int ret;
> >
> > - ret = vdec_av1_slice_setup_lat_from_src_buf(instance, vsi,
> > lat_buf);
> > + ret = vdec_av1_slice_setup_lat_from_src_buf(instance, vsi, bs,
> > lat_buf);
> > if (ret)
> > return ret;
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_
> > lat_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_
> > lat_if.c
> > index 3dceb668ba1c..c50a454ab4f7 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_
> > lat_if.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_
> > lat_if.c
> > @@ -712,19 +712,18 @@ int
> > vdec_vp9_slice_setup_single_from_src_to_dst(struct
> > vdec_vp9_slice_instance *
> > }
> >
> > static int vdec_vp9_slice_setup_lat_from_src_buf(struct
> > vdec_vp9_slice_instance *instance,
> > + struct mtk_vcodec_mem
> > *bs,
> > struct vdec_lat_buf
> > *lat_buf)
> > {
> > - struct vb2_v4l2_buffer *src;
> > - struct vb2_v4l2_buffer *dst;
> > + struct mtk_video_dec_buf *src_buf_info;
> >
> > - src = v4l2_m2m_next_src_buf(instance->ctx->m2m_ctx);
> > - if (!src)
> > + src_buf_info = container_of(bs, struct mtk_video_dec_buf,
> > bs_buffer);
> > + if (!src_buf_info)
> > return -EINVAL;
> >
> > - lat_buf->vb2_v4l2_src = src;
> > + lat_buf->vb2_v4l2_src = &src_buf_info->m2m_buf.vb;
> >
> > - dst = &lat_buf->ts_info;
> > - v4l2_m2m_buf_copy_metadata(src, dst, true);
> > + v4l2_m2m_buf_copy_metadata(lat_buf->vb2_v4l2_src, &lat_buf-
> > >ts_info, true);
> > return 0;
> > }
> >
> > @@ -1154,7 +1153,7 @@ static int vdec_vp9_slice_setup_lat(struct
> > vdec_vp9_slice_instance *instance,
> > struct vdec_vp9_slice_vsi *vsi = &pfc->vsi;
> > int ret;
> >
> > - ret = vdec_vp9_slice_setup_lat_from_src_buf(instance, lat_buf);
> > + ret = vdec_vp9_slice_setup_lat_from_src_buf(instance, bs,
> > lat_buf);
> > if (ret)
> > goto err;
> >
> > --
> > 2.46.0
> >
> >
>
>
next prev parent reply other threads:[~2024-08-27 2:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 8:24 [PATCH v4 0/7] media: mediatek: vcodec: fix v4l2_ctrl_request_complete fail Yunfei Dong
2024-08-07 8:24 ` [PATCH v4 1/7] media: mediatek: vcodec: setting request complete before buffer done Yunfei Dong
2024-08-07 8:24 ` [PATCH v4 2/7] media: mediatek: vcodec: change flush decode order when stream off Yunfei Dong
2024-08-22 15:32 ` Sebastian Fricke
2024-08-07 8:24 ` [PATCH v4 3/7] media: mediatek: vcodec: flush decoder before " Yunfei Dong
2024-08-22 16:11 ` Sebastian Fricke
2024-08-27 2:42 ` Yunfei Dong (董云飞)
2024-08-07 8:24 ` [PATCH v4 4/7] media: mediatek: vcodec: using input information to get vb2 buffer Yunfei Dong
2024-08-23 12:40 ` Sebastian Fricke
2024-08-27 2:47 ` Yunfei Dong (董云飞) [this message]
2024-08-07 8:24 ` [PATCH v4 5/7] media: mediatek: vcodec: store source " Yunfei Dong
2024-08-23 14:14 ` Sebastian Fricke
2024-08-27 2:50 ` Yunfei Dong (董云飞)
2024-08-07 8:24 ` [PATCH v4 6/7] media: mediatek: vcodec: replace v4l2_m2m_next_src_buf with v4l2_m2m_src_buf_remove Yunfei Dong
2024-08-23 15:23 ` Sebastian Fricke
2024-08-27 2:56 ` Yunfei Dong (董云飞)
2024-08-07 8:24 ` [PATCH v4 7/7] media: mediatek: vcodec: remove media request checking Yunfei Dong
2024-08-07 13:08 ` [PATCH v4 0/7] media: mediatek: vcodec: fix v4l2_ctrl_request_complete fail Nicolas Dufresne
2024-08-15 12:58 ` Yunfei Dong (董云飞)
2024-08-23 15:45 ` Sebastian Fricke
2024-08-27 2:58 ` Yunfei Dong (董云飞)
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=42c93832976240bc1fad68b5e606152a16b1de9f.camel@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.almeida@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 \
/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®