Re: 答复: 答复: [PATCH 4/5] media: mtk-vcodec: Add two error cases upon vpu irq handling
Dafna Hirschfeld
dafna.hirschfeld at collabora.com
Tue Nov 9 05:12:50 PST 2021
On 06.11.21 09:02, Irui Wang wrote:
> On Fri, 2021-11-05 at 10:16 +0200, Dafna Hirschfeld wrote:
>>
>> On 04.11.21 14:21, Irui Wang wrote:
>>> On Thu, 2021-11-04 at 12:26 +0200, Dafna Hirschfeld wrote:
>>>>
>>>> On 04.11.21 11:51, Irui Wang wrote:
>>>>> On Thu, 2021-11-04 at 11:23 +0200, Dafna Hirschfeld wrote:
>>>>>>
>>>>>> On 04.11.21 11:16, Irui Wang wrote:
>>>>>>> On Thu, 2021-11-04 at 08:50 +0200, Dafna Hirschfeld wrote:
>>>>>>>>
>>>>>>>> On 04.11.21 03:38, Irui Wang wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, 2021-11-03 at 22:50 +0200, Dafna Hirschfeld
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 09.08.21 12:12, Irui Wang (王瑞) wrote:
>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>
>>>>>>>>>>>>> 2. Always happened issue ? timeout at the
>>>>>>>>>>>>> beginning
>>>>>>>>>>>>> or in
>>>>>>>>>>>>> processing ?
>>>>>>>>>>>>
>>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-
>>>>>>>>>>>>> binary-
>>>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>>>> *NV12Dmabuf* -->>codec=vp8
>>>>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/lo
>>>>>>>>>>>>>> cal/
>>>>>>>>>>>>>> bund
>>>>>>>>>>>>>> les/
>>>>>>>>>>>>>> cros/
>>>>>>>>>>>>>
>>>>>>>>>>>>> video/data/tulip2-320x180.yuv --
>>>>>>>>>>>>> disable_validator
>>>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>>>> sequentially
>>>>>>>>>>>>> then at some point after few attempts I start
>>>>>>>>>>>>> to
>>>>>>>>>>>>> get
>>>>>>>>>>>>> those
>>>>>>>>>>>>> timeout errors.
>>>>>>>>>>>
>>>>>>>>>>> It seems mean VP8 encoding function OK, but failed
>>>>>>>>>>> sometimes,
>>>>>>>>>>> did
>>>>>>>>>>> you have check VENC clock info during encoding:
>>>>>>>>>>>
>>>>>>>>>>> cat /sys/kernel/debug/clk/clk_summary | grep venc:
>>>>>>>>>>>
>>>>>>>>>>> venc_sel > it's H.264 clock
>>>>>>>>>>> venclt_sel > it's VP8 clock
>>>>>>>>>>>
>>>>>>>>>>> the enable&prepare count is not 0 during encoding
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Best Regards
>>>>>>>>>>>
>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>> dafna.hirschfeld at collabora.com]
>>>>>>>>>>> 发送时间: 2021年8月9日 16:27
>>>>>>>>>>> 收件人: Irui Wang (王瑞)
>>>>>>>>>>> 抄送: Linux Media Mailing List; moderated
>>>>>>>>>>> list:ARM/Mediatek
>>>>>>>>>>> SoC
>>>>>>>>>>> support; Enric Balletbo i Serra
>>>>>>>>>>> 主题: Re: 答复: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>> error
>>>>>>>>>>> cases
>>>>>>>>>>> upon
>>>>>>>>>>> vpu irq handling
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09.08.21 09:37, Irui Wang (王瑞) wrote:
>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>
>>>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>> point
>>>>>>>>>>>>>> the encoder interrupts stop arriving so I try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> why and report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Log shows wait IRQ timeout ?
>>>>>>>>>>>
>>>>>>>>>>> Hi, yes, I get timeout when waiting to the encoder
>>>>>>>>>>> interrupt.
>>>>>>>>>>> The
>>>>>>>>>>> timeout is on vp8_enc_wait_venc_done
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2. Always happened issue ? timeout at the
>>>>>>>>>>>> beginning
>>>>>>>>>>>> or in
>>>>>>>>>>>> processing ?
>>>>>>>>>>>
>>>>>>>>>>> The commands that I run is:
>>>>>>>>>>>
>>>>>>>>>>> sudo --user=#1000 /usr/local/libexec/chrome-binary-
>>>>>>>>>>> tests/video_encode_accelerator_tests --
>>>>>>>>>>> gtest_filter=-
>>>>>>>>>>> *NV12Dmabuf* --codec=vp8
>>>>>>>>>>> /usr/local/share/tast/data/chromiumos/tast/local/bu
>>>>>>>>>>> ndle
>>>>>>>>>>> s/cr
>>>>>>>>>>> os/v
>>>>>>>>>>> ideo
>>>>>>>>>>> /data/tulip2-320x180.yuv --disable_validator
>>>>>>>>>>>
>>>>>>>>>>> The command sometime succeed but when I run it
>>>>>>>>>>> sequentially
>>>>>>>>>>> then at
>>>>>>>>>>> some point after few attempts I start to get those
>>>>>>>>>>> timeout
>>>>>>>>>>> errors.
>>>>>>>>>>>
>>>>>>>>>>>> 3. how about IRQ infos?
>>>>>>>>>>>> cat /proc/interrupts | grep vcodec
>>>>>>>>>>>> 18002000.vcodec >> it's H.264 encoder
>>>>>>>>>>>> 19002000.vcodec >> it's VP8 encoder
>>>>>>>>>>>>
>>>>>>>>>>>> I was told you have met another H.264 encoding
>>>>>>>>>>>> failed
>>>>>>>>>>>> before,
>>>>>>>>>>>> did you find reasons about that ?
>>>>>>>>>>>
>>>>>>>>>>> No,
>>>>>>>>>>> But since I see that the google meetup uses the vp8
>>>>>>>>>>> encoder
>>>>>>>>>>> I
>>>>>>>>>>> decided to test the vp8 first.
>>>>>>>>>>>
>>>>>>>>>>>>> [ 81.918747] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32: [3] ctx-
>>>>>>>>>>>>>> type=1,
>>>>>>>>>>>>> cmd=1,
>>>>>>>>>>>>> wait_event_interruptible_timeout time=1000ms
>>>>>>>>>>>>> out 0
>>>>>>>>>>>>> 0!
>>>>>>>>>>>>> [ 81.931392] [MTK_VCODEC][ERROR][3]:
>>>>>>>>>>>>> h264_encode_frame()
>>>>>>>>>>>>> irq_status=0 failed
>>>>>>>>>>>>> [ 81.938470] [MTK_V4L2][ERROR]
>>>>>>>>>>>>> mtk_venc_worker:1219:
>>>>>>>>>>>>> venc_if_encode failed=-5
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I test the driver on debian now, I stream several
>>>>>>>>>> instances
>>>>>>>>>> of
>>>>>>>>>> vp8
>>>>>>>>>> and h264 in parallel.
>>>>>>>>>> I see that those errors always occur after an iommu
>>>>>>>>>> page
>>>>>>>>>> fault:
>>>>>>>>>>
>>>>>>>>>> [gst-master] root at debian:~/gst-build# [ 5743.206014]
>>>>>>>>>> mtk-
>>>>>>>>>> iommu
>>>>>>>>>> 10205000.iommu: fault type=0x5 iova=0xac2ff003 pa=0x0
>>>>>>>>>> larb=3
>>>>>>>>>> port=0
>>>>>>>>>> layer=1 write
>>>>>>>>>> [ 5744.204964] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_vcodec_wait_for_done_ctx:32:
>>>>>>>>>> [2706] ctx->type=1, cmd=1,
>>>>>>>>>> wait_event_interruptible_timeout
>>>>>>>>>> time=1000ms out 0 0!
>>>>>>>>>> [ 5744.217849] [MTK_VCODEC][ERROR][2706]:
>>>>>>>>>> vp8_enc_encode_frame()
>>>>>>>>>> irq_status=0 failed
>>>>>>>>>> [ 5744.225359] [MTK_V4L2][ERROR]
>>>>>>>>>> mtk_venc_worker:1243:
>>>>>>>>>> venc_if_encode
>>>>>>>>>> failed=-5
>>>>>>>>>>
>>>>>>>>>> I suspect that maybe this is because the iova of the
>>>>>>>>>> working_buffers
>>>>>>>>>> is handed to the vpu in the function
>>>>>>>>>> vp8_enc_alloc_work_buf:
>>>>>>>>>> wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>>>>>
>>>>>>>>>> Maybe the vpu keep writing to those addresses after
>>>>>>>>>> they
>>>>>>>>>> are
>>>>>>>>>> already
>>>>>>>>>> unmapped?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dafna
>>>>>>>>>
>>>>>>>>> failed larb=3, it's for h264 encoder, vp8 encoder is
>>>>>>>>> larb5, is
>>>>>>>>> there
>>>>>>>>> any h264 encoding failed at that time? I have no ideas
>>>>>>>>> why
>>>>>>>>> these
>>>>>>>>> errors
>>>>>>>>> happened on your platform, but when we got the "iommu:
>>>>>>>>> fault",
>>>>>>>>> the
>>>>>>>>> possible reason is related to power or clock.
>>>>>>>>
>>>>>>>> Once the iommu fault fires, both encoders constantly fail
>>>>>>>> and
>>>>>>>> never
>>>>>>>> recover
>>>>>>>> (also not when starting new instance).
>>>>>>>>
>>>>>>>> With the falut:
>>>>>>>> mtk_iommu_isr: fault type=0x5 iova=0xebede003 pa=0x0
>>>>>>>> larb=3
>>>>>>>> port=0
>>>>>>>> layer=1 write
>>>>>>>>
>>>>>>>> I looked at the iommu tracing log:
>>>>>>>>
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.634398:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebede000 - 0x00000000ebedf000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.634417:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000ebed0000 - 0x00000000ebed5000 size=20480
>>>>>>>> unmapped_size=20480
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.634435:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb800000 - 0x00000000ebb0a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>> gst-launch-1.0-606 [000] .N... 714.634891:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb700000 - 0x00000000eb7ff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>> gst-launch-1.0-606 [000] .N... 714.635481:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eb000000 - 0x00000000eb30a000 size=3186688
>>>>>>>> unmapped_size=3186688
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.635934:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaf00000 - 0x00000000eafff000 size=1044480
>>>>>>>> unmapped_size=1044480
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.636041:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaef0000 - 0x00000000eaf00000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.636056:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaee0000 - 0x00000000eaef0000 size=65536
>>>>>>>> unmapped_size=65536
>>>>>>>> gst-launch-1.0-606 [000] ..... 714.636069:
>>>>>>>> unmap:
>>>>>>>> IOMMU:
>>>>>>>> iova=0x00000000eaedf000 - 0x00000000eaee0000 size=4096
>>>>>>>> unmapped_size=4096
>>>>>>>> kworker/0:0-537 [000] d.h.. 714.636191:
>>>>>>>> io_page_fault:
>>>>>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000ebede003
>>>>>>>> flags=0x0001
>>>>>>>>
>>>>>>>> (I changed the iommu map/unmap trace events to print the
>>>>>>>> iova
>>>>>>>> range)
>>>>>>>> you can see the first line unmapping 00000000ebede000
>>>>>>>> which
>>>>>>>> is
>>>>>>>> the
>>>>>>>> faulting iova.
>>>>>>>> So it seems that the problem is due to a device trying to
>>>>>>>> access
>>>>>>>> an
>>>>>>>> address that is already unmapped.
>>>>>>>> This might be either the encoder or the vpu.
>>>>>>>> Since the wb[i].iova is not reset when freeing the
>>>>>>>> working
>>>>>>>> buffers I
>>>>>>>> suspect it might be the vpu device, what do you think?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dafna
>>>>>>>
>>>>>>> vpu device won't access the address, the fault logs:
>>>>>>
>>>>>>
>>>>>> Looking at the line:
>>>>>> wb[i].iova = wb[i].iova = inst->work_bufs[i].dma_addr;
>>>>>>
>>>>>> in both vp8 and h264 it seems that the codec drivers give the
>>>>>> vpu
>>>>>> access to the allocated iova address.
>>>>>> If the vpu doesn't access those addresses then what is the
>>>>>> purpose of
>>>>>> this line?
>>>>>>
>>>>>
>>>>> "wb" is a shared buffer between AP-kernel and VPU firmware, to
>>>>> store
>>>>> these encoder working buffers informations, the architecture
>>>>> like
>>>>> this:
>>>>> 1. VPU firmware will set working buffers informations(size,
>>>>> iova(is
>>>>> 0
>>>>> now));
>>>>> 2. AP-kernel allocate these working buffers and get a truly
>>>>> memory(iova), so VPU firmware can get these wbs' iova after
>>>>> allocate
>>>>> done.
>>>>> 3. when encoding, these iova will set to encoder hardware in
>>>>> VPU
>>>>> firmware
>>>>> 4. encoder hardware can get the data from these "iova" to do
>>>>> encoding.
>>>>
>>>> ok, thanks for the explanation, so vpu firmware only hand the
>>>> iova
>>>> adresses further to the encoder hw but never access them itself?
>>>>
>>>>>
>>>>> I suppose you mean that "vpu" is "vpu firmware"? not mtk-vpu
>>>>> driver
>>>>> ?
>>>>
>>>> yes,
>>>>
>>>>>
>>>>>>
>>>>>>> fault type=0x5 iova=0xebede003 pa=0x0 larb=3 port=0 layer=1
>>>>>>> write
>>>>>>>
>>>>>>> it's h264 encoder error when writing "RCPU" data address to
>>>>>>> encoder
>>>>>>> hardware through iommu, but why unmap happended at this
>>>>>>> time?
>>>>>>> it
>>>>>>> seems
>>>>>>> encoding process still going on....
>>>>>>
>>>>>> Why is it seems so?
>>>>>
>>>>> the fault means errors happended while reading prepared encode
>>>>> data, so
>>>>> I think encoding is still going on.
>>>>
>>>> I added more trace_printk debug, adding log before and after the
>>>> working buffers are freed: see 'BEFORE/AFTER' log
>>>>
>>>> gst-launch-1.0-590 [000] ..... 353.825276:
>>>> h264_enc_free_work_buf: h264 BEFORE unmapping work buffers
>>>> gst-launch-1.0-590 [000] ..... 353.825282: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5dff000 - 0x00000000e5e00000 size=4096
>>>> unmapped_size=4096
>>>> gst-launch-1.0-590 [000] ..... 353.825300: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5df0000 - 0x00000000e5df5000 size=20480
>>>> unmapped_size=20480
>>>> gst-launch-1.0-590 [000] ..... 353.825317: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5800000 - 0x00000000e5b0a000 size=3186688
>>>> unmapped_size=3186688
>>>> gst-launch-1.0-590 [000] ..... 353.825740: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e5500000 - 0x00000000e55ff000 size=1044480
>>>> unmapped_size=1044480
>>>> gst-launch-1.0-590 [000] ..... 353.825854: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e1000000 - 0x00000000e130a000 size=3186688
>>>> unmapped_size=3186688
>>>> gst-launch-1.0-590 [000] ..... 353.826273: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0f00000 - 0x00000000e0fff000 size=1044480
>>>> unmapped_size=1044480
>>>> gst-launch-1.0-590 [000] ..... 353.826477: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ef0000 - 0x00000000e0f00000 size=65536
>>>> unmapped_size=65536
>>>> gst-launch-1.0-590 [000] ..... 353.826494: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0ee0000 - 0x00000000e0ef0000 size=65536
>>>> unmapped_size=65536
>>>> gst-launch-1.0-590 [000] ..... 353.826507: unmap:
>>>> IOMMU:
>>>> iova=0x00000000e0edf000 - 0x00000000e0ee0000 size=4096
>>>> unmapped_size=4096
>>>> gst-launch-1.0-590 [000] ..... 353.826515:
>>>> h264_enc_free_work_buf: h264 AFTER unmapping work buffers
>>>> kworker/0:3-67 [000] d.h.. 353.826631:
>>>> io_page_fault:
>>>> IOMMU:mtk-iommu 10205000.iommu iova=0x00000000e5dff003
>>>> flags=0x0001
>>>>
>>>> It is clear that the fault happen for the first working buffer
>>>> that
>>>> is unmapped, and the freeing of the working buffers happens only
>>>> after streaming is done in the '.deinit' cb of the encoder.
>>>
>>> no, free working buffers can also happen when streaming on after
>>> streaming off, call "set_param" again.
Still I can't think why would we have an encoded operation executing while buffers are freed,
all operations are protected with mtk_venc_lock.
Do you have any idea?
>>
>> There is actually a problem with the stream_start/stream_stop logic
>> It might cause asymetricall call to runtime_pm_put/get
>> I sent a patch fixing it, patch 2/3 in the series:
>>
>>
> https://lore.kernel.org/linux-media/34a3f0e40c5248472d072d2a06cc4370e08ea9ff.camel@ndufresne.ca/T/#m01253249fb7d3b0925db9e2cabfcd638c55c28d0
>>
>> could you please review it?
>>
> Can this patch solve your current issues ?
This patch solves a different issue in this driver. (As I already described)
Thank you,
Dafna
>
>
>> I test my code with this patch applied,
>> that means that the working buffers are freed only upon deinit which
>> is only when streaming ends.
>>
>> Thanks,
>> Dafna
>>
>>>
>>>> So it is clear that the encoder device writes to that working
>>>> buffer
>>>> that was just unmapped. Maybe it is a firmware bug?
>>>> Or Maybe the encoder should indeed write to those buffers and
>>>> the
>>>> kernel should wait a while before freeing them?
>>>
>>> did you have tried patch:
>>>
>>>
> https://git.linuxtv.org/media_stage.git/patch/?id=b375e01b796a3bdb2de93ebb15b645edb7972abd
>>
>> The patch is already in mainline, (so yes)
>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> MT8173 latest VPUD firmware:
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmwar
>>>>>>>>>>>> e.git/commit/?id=aaed4a8bf9a77ec68376e8d92fb218d5
>>>>>>>>>>>> fdd8
>>>>>>>>>>>> 8b59
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I uses the latest firmware.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dafna
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>
>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>> 发件人: Dafna Hirschfeld [mailto:
>>>>>>>>>>>> dafna.hirschfeld at collabora.com]
>>>>>>>>>>>> 发送时间: 2021年8月6日 15:49
>>>>>>>>>>>> 收件人: Irui Wang (王瑞); linux-kernel at vger.kernel.org
>>>>>>>>>>>> ;
>>>>>>>>>>>> linux-media at vger.kernel.org;
>>>>>>>>>>>> linux-mediatek at lists.infradead.org
>>>>>>>>>>>> 抄送: dafna3 at gmail.com; tfiga at chromium.org; Tiffany
>>>>>>>>>>>> Lin
>>>>>>>>>>>> (林慧珊);
>>>>>>>>>>>> eizan at chromium.org; Maoguang Meng (孟毛广);
>>>>>>>>>>>> kernel at collabora.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> mchehab at kernel.org; hverkuil at xs4all.nl; Yunfei
>>>>>>>>>>>> Dong
>>>>>>>>>>>> (董云飞);
>>>>>>>>>>>> Yong
>>>>>>>>>>>> Wu
>>>>>>>>>>>> (吴勇); hsinyi at chromium.org; matthias.bgg at gmail.com
>>>>>>>>>>>> ;
>>>>>>>>>>>> Andrew-CT
>>>>>>>>>>>> Chen
>>>>>>>>>>>> (陳智迪); acourbot at chromium.org
>>>>>>>>>>>> 主题: Re: [PATCH 4/5] media: mtk-vcodec: Add two
>>>>>>>>>>>> error
>>>>>>>>>>>> cases
>>>>>>>>>>>> upon
>>>>>>>>>>>> vpu
>>>>>>>>>>>> irq handling
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06.08.21 08:58, Irui Wang (王瑞) wrote:
>>>>>>>>>>>>> On Wed, 2021-08-04 at 16:27 +0200, Dafna
>>>>>>>>>>>>> Hirschfeld
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 1. Fail if the function
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr
>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>> ERR
>>>>>>>>>>>>>> pointer.
>>>>>>>>>>>>>> 2. Fail if the state from the vpu msg is
>>>>>>>>>>>>>> either
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR or
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Dafna Hirschfeld <
>>>>>>>>>>>>>> dafna.hirschfeld at collabora.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>>> 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ++++++++
>>>>>>>>>>>>>> 1 file changed, 8 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> index 32dc844d16f9..234705ba7cd6 100644
>>>>>>>>>>>>>> --- a/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> +++ b/drivers/media/platform/mtk-
>>>>>>>>>>>>>> vcodec/venc_vpu_if.c
>>>>>>>>>>>>>> @@ -17,6 +17,8 @@ static int
>>>>>>>>>>>>>> handle_enc_init_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>> vpu->vsi =
>>>>>>>>>>>>>> mtk_vcodec_fw_map_dm_addr(vpu-
>>>>>>>>>>>>>>> ctx-
>>>>>>>>>>>>>>> dev-
>>>>>>>>>>>>>>> fw_handler,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> msg->vpu_inst_addr);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +if (IS_ERR(vpu->vsi))
>>>>>>>>>>>>>> +return PTR_ERR(vpu->vsi);
>>>>>>>>>>>>>> /* Firmware version field value is
>>>>>>>>>>>>>> unspecified
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> MT8173.
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> if (vpu->ctx->dev->venc_pdata->chip ==
>>>>>>>>>>>>>> MTK_MT8173)
>>>>>>>>>>>>>> return 0;
>>>>>>>>>>>>>> @@ -42,6 +44,12 @@ static int
>>>>>>>>>>>>>> handle_enc_encode_msg(struct
>>>>>>>>>>>>>> venc_vpu_inst *vpu, const void *data)
>>>>>>>>>>>>>> vpu->state = msg->state;
>>>>>>>>>>>>>> vpu->bs_size = msg->bs_size;
>>>>>>>>>>>>>> vpu->is_key_frm = msg->is_key_frm;
>>>>>>>>>>>>>> +if (vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ||
>>>>>>>>>>>>>> + vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_PART) {
>>>>>>>>>>>>>> mtk_vcodec_err(vpu,
>>>>>>>>>>>>>> +"bad ipi-enc-state: %s",
>>>>>>>>>>>>>> + vpu->state ==
>>>>>>>>>>>>>> VEN_IPI_MSG_ENC_STATE_ERROR ? "ERR" :
>>>>>>>>>>>>>> "PART");
>>>>>>>>>>>>>> +return -EINVAL;
>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Dafna,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This state check is useless, the enc result
>>>>>>>>>>>>> will
>>>>>>>>>>>>> check
>>>>>>>>>>>>> in
>>>>>>>>>>>>> "vpu_enc_ipi_handler".
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi, thanks for reviewing. I see that the
>>>>>>>>>>>> vpu_enc_ipi_handler
>>>>>>>>>>>> only
>>>>>>>>>>>> test the msg->status and I see that the states
>>>>>>>>>>>> are
>>>>>>>>>>>> not
>>>>>>>>>>>> tested
>>>>>>>>>>>> anywhere except of "skip" state in the h264 enc.
>>>>>>>>>>>>
>>>>>>>>>>>> Can't there be a scenario where msg->status is ok
>>>>>>>>>>>> but
>>>>>>>>>>>> the
>>>>>>>>>>>> state
>>>>>>>>>>>> is error?
>>>>>>>>>>>> I am testing the vp8 encoder on chromeos and at
>>>>>>>>>>>> some
>>>>>>>>>>>> point
>>>>>>>>>>>> the
>>>>>>>>>>>> encoder interrupts stop arriving so I try to
>>>>>>>>>>>> figure
>>>>>>>>>>>> out
>>>>>>>>>>>> why
>>>>>>>>>>>> and
>>>>>>>>>>>> report any possible error.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dafna
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>> return 0;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ************* MEDIATEK Confidentiality Notice
>>>>>>>>>>>> ******************** The
>>>>>>>>>>>> information contained in this e-mail message
>>>>>>>>>>>> (including
>>>>>>>>>>>> any
>>>>>>>>>>>> attachments) may be confidential, proprietary,
>>>>>>>>>>>> privileged, or
>>>>>>>>>>>> otherwise exempt from disclosure under applicable
>>>>>>>>>>>> laws.
>>>>>>>>>>>> It is
>>>>>>>>>>>> intended
>>>>>>>>>>>> to be conveyed only to the designated
>>>>>>>>>>>> recipient(s).
>>>>>>>>>>>> Any
>>>>>>>>>>>> use,
>>>>>>>>>>>> dissemination, distribution, printing, retaining
>>>>>>>>>>>> or
>>>>>>>>>>>> copying
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-mail (including its
>>>>>>>>>>>> attachments) by unintended recipient(s) is
>>>>>>>>>>>> strictly
>>>>>>>>>>>> prohibited
>>>>>>>>>>>> and may
>>>>>>>>>>>> be unlawful. If you are not an intended recipient
>>>>>>>>>>>> of
>>>>>>>>>>>> this
>>>>>>>>>>>> e-
>>>>>>>>>>>> mail,
>>>>>>>>>>>> or
>>>>>>>>>>>> believe that you have received this e-mail in
>>>>>>>>>>>> error,
>>>>>>>>>>>> please
>>>>>>>>>>>> notify the
>>>>>>>>>>>> sender immediately (by replying to this e-mail),
>>>>>>>>>>>> delete
>>>>>>>>>>>> any
>>>>>>>>>>>> and
>>>>>>>>>>>> all
>>>>>>>>>>>> copies of this e-mail (including any attachments)
>>>>>>>>>>>> from
>>>>>>>>>>>> your
>>>>>>>>>>>> system,
>>>>>>>>>>>> and do not disclose the content of this e-mail to
>>>>>>>>>>>> any
>>>>>>>>>>>> other
>>>>>>>>>>>> person. Thank you!
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-mediatek mailing list
>>>>>>>>> Linux-mediatek at lists.infradead.org
>>>>>>>>>
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>>>>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
More information about the Linux-mediatek
mailing list