[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f55f6c64-f720-437b-ac88-80b6930a9c2c@kwiboo.se>
Date: Sun, 17 Aug 2025 18:33:24 +0200
From: Jonas Karlman <jonas@...boo.se>
To: Nicolas Dufresne <nicolas.dufresne@...labora.com>
Cc: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
Detlev Casanova <detlev.casanova@...labora.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Alex Bee <knaerzche@...il.com>,
linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/7] media: rkvdec: Add HEVC backend
Hi Nicolas,
On 8/12/2025 8:26 PM, Nicolas Dufresne wrote:
> Hi Jonas,
>
> Le mardi 12 août 2025 à 19:31 +0200, Jonas Karlman a écrit :
>> On 8/12/2025 2:44 PM, Nicolas Dufresne wrote:
>>> I forgot,
>>>
>>> Le mardi 12 août 2025 à 08:38 -0400, Nicolas Dufresne a écrit :
>>>>> JCT-VC-HEVC_V1 on GStreamer-H.265-V4L2SL-Gst1.0:
>>>>>
>>>>> - DBLK_D_VIXS_2 (fail)
>>>>> - DSLICE_A_HHI_5 (fail)
>>>>> - EXT_A_ericsson_4 (fail)
>>>>> - PICSIZE_A_Bossen_1 (error)
>>>>> - PICSIZE_B_Bossen_1 (error)
>>>>> - PICSIZE_C_Bossen_1 (error)
>>>>> - PICSIZE_D_Bossen_1 (error)
>>>>> - SAODBLK_A_MainConcept_4 (fail)
>>>>> - SAODBLK_B_MainConcept_4 (fail)
>>>>> - TSUNEQBD_A_MAIN10_Technicolor_2 (error)
>>>
>>> I'me getting the same result if I force a single job in fluster. The test I
>>> posted was with 2 jobs. Detlev found that the iommu reset is required in
>>> more
>>> cases on RK3588/3576, perhaps the HEVC decoder in older hardware needs the
>>> same,
>>> I will try and report.
>>
>> Vendor kernel [1] check following bits from RKVDEC_REG_INTERRUPT reg to
>> decide if a full HW reset should be done.
>>
>> err_mask = RKVDEC_BUF_EMPTY_STA
>> | RKVDEC_BUS_STA
>> | RKVDEC_COLMV_REF_ERR_STA
>> | RKVDEC_ERR_STA
>> | RKVDEC_TIMEOUT_STA;
>>
>> Adding proper reset support can be rather involved and main reason why
>> this series does not handle it, better suited for a separate future
>> series.
>>
>> Proper HW reset will require e.g. dt-bindings, DT updates, pmu idle
>> request integration and for rk3328 vendor even moved VPU reset to TF-A.
>>
>> Doing the iommu detach/attach dance not only on RKVDEC_SOFTRESET_RDY
>> could possible improve some cases, until full reset can be implemented.
>
> Rockchip is following VSI design of "self reset" on error. But since the iommu
> is part of the device, it also gets reset, which imply having to reprogram it.
> This showed to be very reliable logic, despite RK doing a hard reset.
>
> Since self reset is documented for RKVDEC_BUS_STA, RKVDEC_ERR_STA,
> RKVDEC_TIMEOUT_STA, it would seem that RKVDEC_BUF_EMPTY_STA is redundant, unless
> its asynchronous operation that need to be polled. Possibly something to
> investigate. RKVDEC_BUF_EMPTY_STA and RKVDEC_COLMV_REF_ERR_STA are not
> documented a such, so its not quite logical to reprogram the iommu.
>
> I don't immediately trust reference software for these type of things, we should
> find what works best and have a rationale for. The hard reset is every
> expensive, and hard to upstream.
I fully agree, and I tried a few things like issue iommu reset for more
errors, skip use of iommu completely, disable use of performance cache,
write 0 all regs before writing correct values and nothing seem to
resolve this issue.
So more investigation will be needed to fully understand what we need to
do to get a more reliable result.
Will do a visual inspection of the decoded frames on the tests that is
flaky to see if that can give any clue on the extend of the issue.
Regards,
Jonas
>
> Nicolas
>
>>
>> [1]
>> https://github.com/Kwiboo/linux-rockchip/blob/linux-6.1-stan-rkr6.1/drivers/video/rockchip/mpp/mpp_rkvdec.c#L924-L931
>>
>> Regards,
>> Jonas
>>
>>>
>>> Nicolas
Powered by blists - more mailing lists