From: Michał Krawczyk <[email protected]>
The decoder driver should clear the last_buffer_dequeued flag of the
capture queue upon receiving V4L2_DEC_CMD_START.
The last_buffer_dequeued flag is set upon receiving EOS (which always
happens upon receiving V4L2_DEC_CMD_STOP).
Without this patch, after issuing the V4L2_DEC_CMD_STOP and
V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
the buffers are completed by the hardware.
Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API")
Signed-off-by: Michał Krawczyk <[email protected]>
---
drivers/media/platform/qcom/venus/vdec.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
index 4ceaba37e2e5..175488ea08ff 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -526,6 +526,7 @@ static int
vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
{
struct venus_inst *inst = to_inst(file);
+ struct vb2_queue *dst_vq;
struct hfi_frame_data fdata = {0};
int ret;
@@ -556,6 +557,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
inst->codec_state = VENUS_DEC_STATE_DRAIN;
inst->drain_active = true;
}
+ } else if (cmd->cmd == V4L2_DEC_CMD_START &&
+ inst->codec_state == VENUS_DEC_STATE_STOPPED) {
+ dst_vq = v4l2_m2m_get_vq(inst->fh.m2m_ctx,
+ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
+ vb2_clear_last_buffer_dequeued(&inst->fh.m2m_ctx->cap_q_ctx.q);
+
+ inst->codec_state = VENUS_DEC_STATE_DECODING;
}
unlock:
--
2.39.1.456.gfc5497dd1b-goog
Hi Michał,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on linus/master v6.2-rc6 next-20230130]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Micha-Krawczyk/media-venus-dec-Fix-handling-of-the-start-cmd/20230130-185626
base: git://linuxtv.org/media_tree.git master
patch link: https://lore.kernel.org/r/20230130105423.1338554-1-mk%40semmihalf.com
patch subject: [PATCH] media: venus: dec: Fix handling of the start cmd
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20230130/[email protected]/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/3aa2620bc66440999bc7906165d2a5adb129402f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Micha-Krawczyk/media-venus-dec-Fix-handling-of-the-start-cmd/20230130-185626
git checkout 3aa2620bc66440999bc7906165d2a5adb129402f
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash drivers/media/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
All warnings (new ones prefixed by >>):
drivers/media/platform/qcom/venus/vdec.c: In function 'vdec_decoder_cmd':
>> drivers/media/platform/qcom/venus/vdec.c:529:27: warning: variable 'dst_vq' set but not used [-Wunused-but-set-variable]
529 | struct vb2_queue *dst_vq;
| ^~~~~~
vim +/dst_vq +529 drivers/media/platform/qcom/venus/vdec.c
524
525 static int
526 vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
527 {
528 struct venus_inst *inst = to_inst(file);
> 529 struct vb2_queue *dst_vq;
530 struct hfi_frame_data fdata = {0};
531 int ret;
532
533 ret = v4l2_m2m_ioctl_try_decoder_cmd(file, fh, cmd);
534 if (ret)
535 return ret;
536
537 mutex_lock(&inst->lock);
538
539 if (cmd->cmd == V4L2_DEC_CMD_STOP) {
540 /*
541 * Implement V4L2_DEC_CMD_STOP by enqueue an empty buffer on
542 * decoder input to signal EOS.
543 */
544 if (!(inst->streamon_out && inst->streamon_cap))
545 goto unlock;
546
547 fdata.buffer_type = HFI_BUFFER_INPUT;
548 fdata.flags |= HFI_BUFFERFLAG_EOS;
549 if (IS_V6(inst->core))
550 fdata.device_addr = 0;
551 else
552 fdata.device_addr = 0xdeadb000;
553
554 ret = hfi_session_process_buf(inst, &fdata);
555
556 if (!ret && inst->codec_state == VENUS_DEC_STATE_DECODING) {
557 inst->codec_state = VENUS_DEC_STATE_DRAIN;
558 inst->drain_active = true;
559 }
560 } else if (cmd->cmd == V4L2_DEC_CMD_START &&
561 inst->codec_state == VENUS_DEC_STATE_STOPPED) {
562 dst_vq = v4l2_m2m_get_vq(inst->fh.m2m_ctx,
563 V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
564 vb2_clear_last_buffer_dequeued(&inst->fh.m2m_ctx->cap_q_ctx.q);
565
566 inst->codec_state = VENUS_DEC_STATE_DECODING;
567 }
568
569 unlock:
570 mutex_unlock(&inst->lock);
571 return ret;
572 }
573
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
From: Michał Krawczyk <[email protected]>
The decoder driver should clear the last_buffer_dequeued flag of the
capture queue upon receiving V4L2_DEC_CMD_START.
The last_buffer_dequeued flag is set upon receiving EOS (which always
happens upon receiving V4L2_DEC_CMD_STOP).
Without this patch, after issuing the V4L2_DEC_CMD_STOP and
V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
the buffers are completed by the hardware.
Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API")
Signed-off-by: Michał Krawczyk <[email protected]>
---
V1 -> V2: Fix warning regarding unused variable
drivers/media/platform/qcom/venus/vdec.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
index 4ceaba37e2e5..9d26587716bf 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -526,6 +526,7 @@ static int
vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
{
struct venus_inst *inst = to_inst(file);
+ struct vb2_queue *dst_vq;
struct hfi_frame_data fdata = {0};
int ret;
@@ -556,6 +557,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
inst->codec_state = VENUS_DEC_STATE_DRAIN;
inst->drain_active = true;
}
+ } else if (cmd->cmd == V4L2_DEC_CMD_START &&
+ inst->codec_state == VENUS_DEC_STATE_STOPPED) {
+ dst_vq = v4l2_m2m_get_vq(inst->fh.m2m_ctx,
+ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
+ vb2_clear_last_buffer_dequeued(dst_vq);
+
+ inst->codec_state = VENUS_DEC_STATE_DECODING;
}
unlock:
--
2.39.1.456.gfc5497dd1b-goog
pon., 30 sty 2023 o 14:55 Michał Krawczyk <[email protected]> napisał(a):
>
> From: Michał Krawczyk <[email protected]>
>
> The decoder driver should clear the last_buffer_dequeued flag of the
> capture queue upon receiving V4L2_DEC_CMD_START.
>
> The last_buffer_dequeued flag is set upon receiving EOS (which always
> happens upon receiving V4L2_DEC_CMD_STOP).
>
> Without this patch, after issuing the V4L2_DEC_CMD_STOP and
> V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
> the buffers are completed by the hardware.
>
> Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API")
>
> Signed-off-by: Michał Krawczyk <[email protected]>
Hello,
Did anyone have a chance to take a look at this patch? It's fairly
simple, but lack of this fix can have a big impact on the V4L2
applications which implement the flush mechanism using the stop/start
commands, especially in the middle of the video.
Thank you,
Michał
Hello Michal,
Thank you for raising a fix in video driver.
> -----Original Message-----
> From: Michał Krawczyk <[email protected]>
> Sent: Tuesday, February 7, 2023 2:48 PM
> To: Stanimir Varbanov <[email protected]>; Vikash Garodia
> (QUIC) <[email protected]>
> Cc: Andy Gross <[email protected]>; Bjorn Andersson
> <[email protected]>; Konrad Dybcio <[email protected]>; Mauro
> Carvalho Chehab <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH v2] media: venus: dec: Fix handling of the start cmd
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> pon., 30 sty 2023 o 14:55 Michał Krawczyk <[email protected]> napisał(a):
> >
> > From: Michał Krawczyk <[email protected]>
> >
> > The decoder driver should clear the last_buffer_dequeued flag of the
> > capture queue upon receiving V4L2_DEC_CMD_START.
> >
> > The last_buffer_dequeued flag is set upon receiving EOS (which always
> > happens upon receiving V4L2_DEC_CMD_STOP).
> >
> > Without this patch, after issuing the V4L2_DEC_CMD_STOP and
> > V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
> > the buffers are completed by the hardware.
> >
> > Fixes: beac82904a87 ("media: venus: make decoder compliant with
> > stateful codec API")
> >
> > Signed-off-by: Michał Krawczyk <[email protected]>
>
> Hello,
>
> Did anyone have a chance to take a look at this patch? It's fairly simple, but lack
> of this fix can have a big impact on the V4L2 applications which implement the
> flush mechanism using the stop/start commands, especially in the middle of the
> video.
I have reviewed the patch, and the drain sequence handling looks good to me.
Could you share some details on the test client which you are using to catch this issue ?
> Thank you,
> Michał
Thanks,
Vikash
wt., 7 lut 2023 o 10:54 Vikash Garodia <[email protected]> napisał(a):
> I have reviewed the patch, and the drain sequence handling looks good to me.
> Could you share some details on the test client which you are using to catch this issue ?
Hi Vikash,
Thank you for looking at the code!
I've been testing it using the Chromium implementation of the V4L2
codec [1]. Meanwhile, we were running a test suite which changes the
encryption method in the middle of the video decoding. This triggers
the flush behavior and the Chromium sends the stop/start cmd to the
V4L2 kernel component, and the test expects the video to continue the
playback normally. Unfortunately, it was causing a stall of the video
at the same time.
[1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
>
> > Thank you,
> > Michał
>
> Thanks,
> Vikash
Hi,
I'm wondering if there are any more comments for this patch? I would
be happy to clarify anything that's unclear or improve the code if
needed.
I know it's pretty late, but it would be really great if this fix
could land before v6.2 is released, so I'd appreciate your help and
review.
Thank you,
Michał
wt., 7 lut 2023 o 12:15 Michał Krawczyk <[email protected]> napisał(a):
>
> wt., 7 lut 2023 o 10:54 Vikash Garodia <[email protected]> napisał(a):
> > I have reviewed the patch, and the drain sequence handling looks good to me.
> > Could you share some details on the test client which you are using to catch this issue ?
>
> Hi Vikash,
>
> Thank you for looking at the code!
>
> I've been testing it using the Chromium implementation of the V4L2
> codec [1]. Meanwhile, we were running a test suite which changes the
> encryption method in the middle of the video decoding. This triggers
> the flush behavior and the Chromium sends the stop/start cmd to the
> V4L2 kernel component, and the test expects the video to continue the
> playback normally. Unfortunately, it was causing a stall of the video
> at the same time.
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
>
> >
> > > Thank you,
> > > Michał
> >
> > Thanks,
> > Vikash
Hi,
Any update on this patch? It would be great if we could make some
progress there (and, hopefully, finally merge it :))
Thanks,
Michał
pt., 10 lut 2023 o 16:18 Michał Krawczyk <[email protected]> napisał(a):
>
> Hi,
>
> I'm wondering if there are any more comments for this patch? I would
> be happy to clarify anything that's unclear or improve the code if
> needed.
>
> I know it's pretty late, but it would be really great if this fix
> could land before v6.2 is released, so I'd appreciate your help and
> review.
>
> Thank you,
> Michał
>
> wt., 7 lut 2023 o 12:15 Michał Krawczyk <[email protected]> napisał(a):
> >
> > wt., 7 lut 2023 o 10:54 Vikash Garodia <[email protected]> napisał(a):
> > > I have reviewed the patch, and the drain sequence handling looks good to me.
> > > Could you share some details on the test client which you are using to catch this issue ?
> >
> > Hi Vikash,
> >
> > Thank you for looking at the code!
> >
> > I've been testing it using the Chromium implementation of the V4L2
> > codec [1]. Meanwhile, we were running a test suite which changes the
> > encryption method in the middle of the video decoding. This triggers
> > the flush behavior and the Chromium sends the stop/start cmd to the
> > V4L2 kernel component, and the test expects the video to continue the
> > playback normally. Unfortunately, it was causing a stall of the video
> > at the same time.
> >
> > [1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
> >
> > >
> > > > Thank you,
> > > > Michał
> > >
> > > Thanks,
> > > Vikash
Hi,
just a kindly reminder about the patch.
Thanks,
Michał
pt., 10 mar 2023 o 16:05 Michał Krawczyk <[email protected]> napisał(a):
>
> Hi,
>
> Any update on this patch? It would be great if we could make some
> progress there (and, hopefully, finally merge it :))
>
> Thanks,
> Michał
>
> pt., 10 lut 2023 o 16:18 Michał Krawczyk <[email protected]> napisał(a):
> >
> > Hi,
> >
> > I'm wondering if there are any more comments for this patch? I would
> > be happy to clarify anything that's unclear or improve the code if
> > needed.
> >
> > I know it's pretty late, but it would be really great if this fix
> > could land before v6.2 is released, so I'd appreciate your help and
> > review.
> >
> > Thank you,
> > Michał
> >
> > wt., 7 lut 2023 o 12:15 Michał Krawczyk <[email protected]> napisał(a):
> > >
> > > wt., 7 lut 2023 o 10:54 Vikash Garodia <[email protected]> napisał(a):
> > > > I have reviewed the patch, and the drain sequence handling looks good to me.
> > > > Could you share some details on the test client which you are using to catch this issue ?
> > >
> > > Hi Vikash,
> > >
> > > Thank you for looking at the code!
> > >
> > > I've been testing it using the Chromium implementation of the V4L2
> > > codec [1]. Meanwhile, we were running a test suite which changes the
> > > encryption method in the middle of the video decoding. This triggers
> > > the flush behavior and the Chromium sends the stop/start cmd to the
> > > V4L2 kernel component, and the test expects the video to continue the
> > > playback normally. Unfortunately, it was causing a stall of the video
> > > at the same time.
> > >
> > > [1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
> > >
> > > >
> > > > > Thank you,
> > > > > Michał
> > > >
> > > > Thanks,
> > > > Vikash
On 4/5/2023 2:59 PM, Michał Krawczyk wrote:
> Hi,
>
> just a kindly reminder about the patch.
>
> Thanks,
> Michał
Hi Michal,
this patch is part of latest PR
https://patchwork.linuxtv.org/project/linux-media/patch/[email protected]/
Thanks,
Dikshita
> pt., 10 mar 2023 o 16:05 Michał Krawczyk <[email protected]> napisał(a):
>> Hi,
>>
>> Any update on this patch? It would be great if we could make some
>> progress there (and, hopefully, finally merge it :))
>>
>> Thanks,
>> Michał
>>
>> pt., 10 lut 2023 o 16:18 Michał Krawczyk <[email protected]> napisał(a):
>>> Hi,
>>>
>>> I'm wondering if there are any more comments for this patch? I would
>>> be happy to clarify anything that's unclear or improve the code if
>>> needed.
>>>
>>> I know it's pretty late, but it would be really great if this fix
>>> could land before v6.2 is released, so I'd appreciate your help and
>>> review.
>>>
>>> Thank you,
>>> Michał
>>>
>>> wt., 7 lut 2023 o 12:15 Michał Krawczyk <[email protected]> napisał(a):
>>>> wt., 7 lut 2023 o 10:54 Vikash Garodia <[email protected]> napisał(a):
>>>>> I have reviewed the patch, and the drain sequence handling looks good to me.
>>>>> Could you share some details on the test client which you are using to catch this issue ?
>>>> Hi Vikash,
>>>>
>>>> Thank you for looking at the code!
>>>>
>>>> I've been testing it using the Chromium implementation of the V4L2
>>>> codec [1]. Meanwhile, we were running a test suite which changes the
>>>> encryption method in the middle of the video decoding. This triggers
>>>> the flush behavior and the Chromium sends the stop/start cmd to the
>>>> V4L2 kernel component, and the test expects the video to continue the
>>>> playback normally. Unfortunately, it was causing a stall of the video
>>>> at the same time.
>>>>
>>>> [1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
>>>>
>>>>>> Thank you,
>>>>>> Michał
>>>>> Thanks,
>>>>> Vikash