This series add a HEVC backend to the Rockchip Video Decoder driver.

With the dependent H.264 High 10 and 4:2:2 profile support series
finally merged there is finally time to send a v2 with minor changes and
a suggested code style fix of this series. v1 of this series has been
fully functional up until recent unstaging of the rkvdec driver.

A version of this HEVC backend has been in use by the LibreELEC distro
for the past 5+ years [1]. It was initially created based on a copy of
the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
matrix functions shamelessly copied 1:1 from the Rockchip mpp library.

It has since then been extended to use the stable HEVC uAPI controls and
improved opon e.g. to include support for rk3288 and fix decoding issues
by Alex Bee and Nicolas Dufresne.

The version submitted in this series is based on the code currently used
by the LibreELEC distro, excluding hard/soft reset, and with cabac table
and scaling matrix functions picked from Sebastian Fricke prior series
to add a HEVC backend [2].

Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
this series possible!

Patch 1 add the new HEVC backend.
Patch 2-3 add variants support to the driver.
Patch 4 add support for a rk3288 variant.
Patch 5 add a rk3328 variant to work around hw quirks.
Patch 6-7 add device tree node for rk3288.

This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):

  v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
  ...
  Total for rkvdec device /dev/video1: 49, Succeeded: 49, Failed: 0, Warnings: 0

  Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
  ...
  Ran 137/147 tests successfully

  Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
  ...
  Ran 9/9 tests successfully

And on a TinkerBoard (RK3288):

  v4l2-compliance 1.30.1, 32 bits, 32-bit time_t
  ...
  Total for rkvdec device /dev/video3: 49, Succeeded: 49, Failed: 0, Warnings: 0

  Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
  ...
  Ran 137/147 tests successfully

  Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
  ...
  Ran 9/9 tests successfully

The WPP_x_ericsson tests from test suite JCT-VC-HEVC_V1 has been showing
a mix of both Success and/or Fail result for FFmpeg-H.265-v4l2request.

Full summary of fluster run can be found at [3].

Please note that there is a known issue with concurrent decoding,
decoding errors in one decode session may affect a separate session.
The only known mitigation to this is to pause decoding for some time
and/or do a full HW reset, something to handle in future series.

Changes in v2:
- Rabase after h264 high10/422 merge and unstaging of rkvdec driver
- Use new_value in transpose_and_flatten_matrices()
- Add NULL check for ctrl->new_elems in rkvdec_hevc_run_preamble()
- Set RKVDEC_WR_DDR_ALIGN_EN for RK3328
- Adjust code style in rkvdec_enum_coded_fmt_desc()
- Collect a-b tag
- Drop merged vdec node reg size patches
Link to v1: https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-2000-v4l2-wip-rkvdec-hevc.patch
[2] https://lore.kernel.org/linux-media/20230101-patch-series-v2-6-2-rc1-v2-0-fa1897efac14@collabora.com/
[3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d

Alex Bee (4):
  media: rkvdec: Add variants support
  media: rkvdec: Add RK3288 variant
  media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
  ARM: dts: rockchip: Add vdec node for RK3288

Jonas Karlman (3):
  media: rkvdec: Add HEVC backend
  media: rkvdec: Implement capability filtering
  media: dt-bindings: rockchip,vdec: Add RK3288 compatible

 .../bindings/media/rockchip,vdec.yaml         |    1 +
 arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
 .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
 .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
 .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
 .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
 .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
 .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
 .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
 9 files changed, 2886 insertions(+), 21 deletions(-)
 create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
 create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

-- 
2.50.1

Hi Jonas,

On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
> This series add a HEVC backend to the Rockchip Video Decoder driver.
>
> With the dependent H.264 High 10 and 4:2:2 profile support series
> finally merged there is finally time to send a v2 with minor changes and
> a suggested code style fix of this series. v1 of this series has been
> fully functional up until recent unstaging of the rkvdec driver.
>
> A version of this HEVC backend has been in use by the LibreELEC distro
> for the past 5+ years [1]. It was initially created based on a copy of
> the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
> matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
>
> It has since then been extended to use the stable HEVC uAPI controls and
> improved opon e.g. to include support for rk3288 and fix decoding issues
> by Alex Bee and Nicolas Dufresne.
>
> The version submitted in this series is based on the code currently used
> by the LibreELEC distro, excluding hard/soft reset, and with cabac table
> and scaling matrix functions picked from Sebastian Fricke prior series
> to add a HEVC backend [2].
>
> Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
> this series possible!
>
> Patch 1 add the new HEVC backend.
> Patch 2-3 add variants support to the driver.
> Patch 4 add support for a rk3288 variant.
> Patch 5 add a rk3328 variant to work around hw quirks.
> Patch 6-7 add device tree node for rk3288.

It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
locally and that also had this commit:
- media: rkvdec: Keep decoder clocks gated

Is that one no longer needed/useful/etc ?

And 'chewitt' also had a commit to fix 8/10-bit selection:
https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
"WIP: media: rkvdec: fix 8-bit/10-bit format selection"

I haven't tried that one (yet), but did  try an other variant with
changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
in my tests. (Can ofc be PEBKAC)

Would that be useful? I do/did have consistent problems with playing
10-bit encoded video files.

> This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
> <snip>
>
> Please note that there is a known issue with concurrent decoding,
> decoding errors in one decode session may affect a separate session.
> The only known mitigation to this is to pause decoding for some time
> and/or do a full HW reset, something to handle in future series.

Or would that be (potential) material for a future series as well?

Cheers,
  Diederik
>
> <snip>
>
> Alex Bee (4):
>   media: rkvdec: Add variants support
>   media: rkvdec: Add RK3288 variant
>   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
>   ARM: dts: rockchip: Add vdec node for RK3288
>
> Jonas Karlman (3):
>   media: rkvdec: Add HEVC backend
>   media: rkvdec: Implement capability filtering
>   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
>
>  .../bindings/media/rockchip,vdec.yaml         |    1 +
>  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
>  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
>  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
>  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
>  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
>  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
>  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
>  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
>  9 files changed, 2886 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

Hi Diederik,

On 8/12/2025 2:11 PM, Diederik de Haas wrote:
> Hi Jonas,
> 
> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>
>> With the dependent H.264 High 10 and 4:2:2 profile support series
>> finally merged there is finally time to send a v2 with minor changes and
>> a suggested code style fix of this series. v1 of this series has been
>> fully functional up until recent unstaging of the rkvdec driver.
>>
>> A version of this HEVC backend has been in use by the LibreELEC distro
>> for the past 5+ years [1]. It was initially created based on a copy of
>> the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
>> matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
>>
>> It has since then been extended to use the stable HEVC uAPI controls and
>> improved opon e.g. to include support for rk3288 and fix decoding issues
>> by Alex Bee and Nicolas Dufresne.
>>
>> The version submitted in this series is based on the code currently used
>> by the LibreELEC distro, excluding hard/soft reset, and with cabac table
>> and scaling matrix functions picked from Sebastian Fricke prior series
>> to add a HEVC backend [2].
>>
>> Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
>> this series possible!
>>
>> Patch 1 add the new HEVC backend.
>> Patch 2-3 add variants support to the driver.
>> Patch 4 add support for a rk3288 variant.
>> Patch 5 add a rk3328 variant to work around hw quirks.
>> Patch 6-7 add device tree node for rk3288.
> 
> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
> locally and that also had this commit:
> - media: rkvdec: Keep decoder clocks gated
> 
> Is that one no longer needed/useful/etc ?

I do not think it is, could possible be to keep power consumption at
minimum while decoding. Some parts enable auto gating and then we
disable it when decoding is complete. With auto-suspend the entire block
is disabled anyway so this probably did not make any noticeable
difference and could instead introduce new possible issues.

> 
> And 'chewitt' also had a commit to fix 8/10-bit selection:
> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
> 
> I haven't tried that one (yet), but did  try an other variant with
> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
> in my tests. (Can ofc be PEBKAC)

The format selection in kernel for this series should be correct,
however to ensure 10-bit works you need following for ffmpeg-v4l2request
to select and use 10-bit pixel formats:

libdrm 2.4.104+ (NV15) / 2.4.118+ (NV20)
- 10-bit drm formats, ffmpeg v4l2request test with a #ifdef

linux headers v6.16-rc1+ (NV15/NV20)
- 10-bit v4l2 pix fmt, ffmpeg v4l2request test with a #ifdef

FFmpeg v4l2request will not negotiate use of 10-bit formats without
DRM_FORMAT_NV15/NV20 and V4L2_PIX_FMT_NV15/NV20 defined when ffmpeg was
compiled.

That would be the most likely issue if only 8-bit formats is working.

> 
> Would that be useful? I do/did have consistent problems with playing
> 10-bit encoded video files.

Looking quickly at the 'fix 8/10-bit selection' commit the issue is that
rkvdec_hevc_get_image_fmt() was incomplete to begin with. The
rkvdec_hevc_get_image_fmt() in this series has been correct since v1.

> 
>> This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
>> <snip>
>>
>> Please note that there is a known issue with concurrent decoding,
>> decoding errors in one decode session may affect a separate session.
>> The only known mitigation to this is to pause decoding for some time
>> and/or do a full HW reset, something to handle in future series.
> 
> Or would that be (potential) material for a future series as well?

Yes, adding proper HW reset support is something for a future series.

Regards,
Jonas

> 
> Cheers,
>   Diederik
>>
>> <snip>
>>
>> Alex Bee (4):
>>   media: rkvdec: Add variants support
>>   media: rkvdec: Add RK3288 variant
>>   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
>>   ARM: dts: rockchip: Add vdec node for RK3288
>>
>> Jonas Karlman (3):
>>   media: rkvdec: Add HEVC backend
>>   media: rkvdec: Implement capability filtering
>>   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
>>
>>  .../bindings/media/rockchip,vdec.yaml         |    1 +
>>  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
>>  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
>>  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
>>  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
>>  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
>>  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
>>  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
>>  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
>>  9 files changed, 2886 insertions(+), 21 deletions(-)
>>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
>>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c
>

Hi Jonas,

On Tue Aug 12, 2025 at 7:11 PM CEST, Jonas Karlman wrote:
> On 8/12/2025 2:11 PM, Diederik de Haas wrote:
>> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>>
>>> With the dependent H.264 High 10 and 4:2:2 profile support series
>>> finally merged there is finally time to send a v2 with minor changes and
>>> a suggested code style fix of this series. v1 of this series has been
>>> fully functional up until recent unstaging of the rkvdec driver.
>>>
>>> Patch 1 add the new HEVC backend.
>>> Patch 2-3 add variants support to the driver.
>>> Patch 4 add support for a rk3288 variant.
>>> Patch 5 add a rk3328 variant to work around hw quirks.
>>> Patch 6-7 add device tree node for rk3288.
>> 
>> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
>> locally and that also had this commit:
>> - media: rkvdec: Keep decoder clocks gated
>> 
>> Is that one no longer needed/useful/etc ?
>
> I do not think it is, could possible be to keep power consumption at
> minimum while decoding. Some parts enable auto gating and then we
> disable it when decoding is complete. With auto-suspend the entire block
> is disabled anyway so this probably did not make any noticeable
> difference and could instead introduce new possible issues.

Makes sense, thanks.
 
>> And 'chewitt' also had a commit to fix 8/10-bit selection:
>> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
>> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>> 
>> I haven't tried that one (yet), but did  try an other variant with
>> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
>> in my tests. (Can ofc be PEBKAC)
>
> The format selection in kernel for this series should be correct,
> however to ensure 10-bit works you need following for ffmpeg-v4l2request
> to select and use 10-bit pixel formats:
>
> libdrm 2.4.104+ (NV15) / 2.4.118+ (NV20)
> - 10-bit drm formats, ffmpeg v4l2request test with a #ifdef
>
> linux headers v6.16-rc1+ (NV15/NV20)
> - 10-bit v4l2 pix fmt, ffmpeg v4l2request test with a #ifdef
>
> FFmpeg v4l2request will not negotiate use of 10-bit formats without
> DRM_FORMAT_NV15/NV20 and V4L2_PIX_FMT_NV15/NV20 defined when ffmpeg was
> compiled.
>
> That would be the most likely issue if only 8-bit formats is working.

Thanks so much for the detailed explanation with which I can check where
my stack wasn't doing what I hoped it would :-)

>> Would that be useful? I do/did have consistent problems with playing
>> 10-bit encoded video files.
>
> Looking quickly at the 'fix 8/10-bit selection' commit the issue is that
> rkvdec_hevc_get_image_fmt() was incomplete to begin with. The
> rkvdec_hevc_get_image_fmt() in this series has been correct since v1.

Thanks :)

Cheers,
  Diederik

Hi again,

On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:
> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>
>> Patch 1 add the new HEVC backend.
>> Patch 2-3 add variants support to the driver.
>> Patch 4 add support for a rk3288 variant.
>> Patch 5 add a rk3328 variant to work around hw quirks.
>> Patch 6-7 add device tree node for rk3288.
>
> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
> locally and that also had this commit:
> - media: rkvdec: Keep decoder clocks gated
>
> Is that one no longer needed/useful/etc ?
>
> And 'chewitt' also had a commit to fix 8/10-bit selection:
> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>
> I haven't tried that one (yet), but did  try an other variant with
> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
> in my tests. (Can ofc be PEBKAC)
>
> Would that be useful? I do/did have consistent problems with playing
> 10-bit encoded video files.

nvm about the 10-bit problem. It exists, but it's not restricted to HEVC
as it also exists with with H.264 files.

Cheers,
  Diederik

Le mardi 12 août 2025 à 14:55 +0200, Diederik de Haas a écrit :
> Hi again,
> 
> On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:
> > On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
> > > This series add a HEVC backend to the Rockchip Video Decoder driver.
> > > 
> > > Patch 1 add the new HEVC backend.
> > > Patch 2-3 add variants support to the driver.
> > > Patch 4 add support for a rk3288 variant.
> > > Patch 5 add a rk3328 variant to work around hw quirks.
> > > Patch 6-7 add device tree node for rk3288.
> > 
> > It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
> > locally and that also had this commit:
> > - media: rkvdec: Keep decoder clocks gated
> > 
> > Is that one no longer needed/useful/etc ?
> > 
> > And 'chewitt' also had a commit to fix 8/10-bit selection:
> > https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
> > "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
> > 
> > I haven't tried that one (yet), but did  try an other variant with
> > changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
> > in my tests. (Can ofc be PEBKAC)
> > 
> > Would that be useful? I do/did have consistent problems with playing
> > 10-bit encoded video files.
> 
> nvm about the 10-bit problem. It exists, but it's not restricted to HEVC
> as it also exists with with H.264 files.

The referred patch is against some out-dated kernel. In mainline linux with
have:

	if (sps->bit_depth_luma_minus8 == 0) {
		if (sps->chroma_format_idc == 2)
			return RKVDEC_IMG_FMT_422_8BIT;
		else
			return RKVDEC_IMG_FMT_420_8BIT;
	} else if (sps->bit_depth_luma_minus8 == 2) {
		if (sps->chroma_format_idc == 2)
			return RKVDEC_IMG_FMT_422_10BIT;
		else
			return RKVDEC_IMG_FMT_420_10BIT;
	}

Which covers all cases supporte by the hardware. Chewitt seem to add a
previously missing 10bit case, and forcing downconversion from 422 to 420. A
downconversion is something to be chosen and applied by userspace, the kernel
should pick a non-destructive format by default.

Nicolas

> 
> Cheers,
>   Diederik

Am 12.08.25 um 15:27 schrieb Nicolas Dufresne:
> Le mardi 12 août 2025 à 14:55 +0200, Diederik de Haas a écrit :
>> Hi again,
>>
>> On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:
>>> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>>>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>>>
>>>> Patch 1 add the new HEVC backend.
>>>> Patch 2-3 add variants support to the driver.
>>>> Patch 4 add support for a rk3288 variant.
>>>> Patch 5 add a rk3328 variant to work around hw quirks.
>>>> Patch 6-7 add device tree node for rk3288.
>>>
>>> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
>>> locally and that also had this commit:
>>> - media: rkvdec: Keep decoder clocks gated
>>>
>>> Is that one no longer needed/useful/etc ?
>>>
>>> And 'chewitt' also had a commit to fix 8/10-bit selection:
>>> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
>>> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>>>
>>> I haven't tried that one (yet), but did  try an other variant with
>>> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
>>> in my tests. (Can ofc be PEBKAC)
>>>
>>> Would that be useful? I do/did have consistent problems with playing
>>> 10-bit encoded video files.
>>
>> nvm about the 10-bit problem. It exists, but it's not restricted to HEVC
>> as it also exists with with H.264 files.
> 
> The referred patch is against some out-dated kernel. In mainline linux with
> have:
> 
> 	if (sps->bit_depth_luma_minus8 == 0) {
> 		if (sps->chroma_format_idc == 2)
> 			return RKVDEC_IMG_FMT_422_8BIT;
> 		else
> 			return RKVDEC_IMG_FMT_420_8BIT;
> 	} else if (sps->bit_depth_luma_minus8 == 2) {
> 		if (sps->chroma_format_idc == 2)
> 			return RKVDEC_IMG_FMT_422_10BIT;
> 		else
> 			return RKVDEC_IMG_FMT_420_10BIT;
> 	}
> 
> Which covers all cases supporte by the hardware. Chewitt seem to add a
> previously missing 10bit case, and forcing downconversion from 422 to 420. A
> downconversion is something to be chosen and applied by userspace, the kernel
> should pick a non-destructive format by default.

Please note that this patch is completely unrelated to this series, as it
is for Detlev's WIP rkvdec2 driver [0] and for H.265 codec only - rkvdec2
similar to rkvdec(1) only supports NV12 and NV15 for H.265 codec and
perfectly matches what is defined at [1].

[0] 
https://gitlab.collabora.com/detlev/linux/-/tree/add-vdpu381-and-383-to-rkvdec-v2
[1] 
https://gitlab.collabora.com/detlev/linux/-/blob/15352e295a0d38bd0450f608e7bbcbf16dfefd6b/drivers/media/platform/rockchip/rkvdec/rkvdec.c#L333

> Nicolas
> 
>>
>> Cheers,
>>    Diederik
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip

On Tue Aug 12, 2025 at 3:27 PM CEST, Nicolas Dufresne wrote:
> Le mardi 12 août 2025 à 14:55 +0200, Diederik de Haas a écrit :
>> On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:
>> > On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>> > > This series add a HEVC backend to the Rockchip Video Decoder driver.
>> > > 
>> > > Patch 1 add the new HEVC backend.
>> > > Patch 2-3 add variants support to the driver.
>> > > Patch 4 add support for a rk3288 variant.
>> > > Patch 5 add a rk3328 variant to work around hw quirks.
>> > > Patch 6-7 add device tree node for rk3288.
>> > 
>> > It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
>> > locally and that also had this commit:
>> > - media: rkvdec: Keep decoder clocks gated
>> > 
>> > Is that one no longer needed/useful/etc ?
>> > 
>> > And 'chewitt' also had a commit to fix 8/10-bit selection:
>> > https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
>> > "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>> > 
>> > I haven't tried that one (yet), but did  try an other variant with
>> > changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
>> > in my tests. (Can ofc be PEBKAC)
>> > 
>> > Would that be useful? I do/did have consistent problems with playing
>> > 10-bit encoded video files.
>> 
>> nvm about the 10-bit problem. It exists, but it's not restricted to HEVC
>> as it also exists with with H.264 files.
>
> The referred patch is against some out-dated kernel. In mainline linux with
> have:
>
> 	if (sps->bit_depth_luma_minus8 == 0) {
> 		if (sps->chroma_format_idc == 2)
> 			return RKVDEC_IMG_FMT_422_8BIT;
> 		else
> 			return RKVDEC_IMG_FMT_420_8BIT;
> 	} else if (sps->bit_depth_luma_minus8 == 2) {
> 		if (sps->chroma_format_idc == 2)
> 			return RKVDEC_IMG_FMT_422_10BIT;
> 		else
> 			return RKVDEC_IMG_FMT_420_10BIT;
> 	}

That's indeed the code for H.264.

> Which covers all cases supporte by the hardware. Chewitt seem to add a
> previously missing 10bit case, and forcing downconversion from 422 to 420. A
> downconversion is something to be chosen and applied by userspace, the kernel
> should pick a non-destructive format by default.

It's based on the 6.16 mainline kernel, but that patch is a 'fix' on a
not (yet) accepted patch he added on top of that for HEVC. So it not
working for me on H.264 must be from somewhere else in the/my stack.

Sorry for the noise.

Le dimanche 10 août 2025 à 21:24 +0000, Jonas Karlman a écrit :
> This series add a HEVC backend to the Rockchip Video Decoder driver.
> 
> With the dependent H.264 High 10 and 4:2:2 profile support series
> finally merged there is finally time to send a v2 with minor changes and
> a suggested code style fix of this series. v1 of this series has been
> fully functional up until recent unstaging of the rkvdec driver.
> 
> A version of this HEVC backend has been in use by the LibreELEC distro
> for the past 5+ years [1]. It was initially created based on a copy of
> the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
> matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
> 
> It has since then been extended to use the stable HEVC uAPI controls and
> improved opon e.g. to include support for rk3288 and fix decoding issues
> by Alex Bee and Nicolas Dufresne.
> 
> The version submitted in this series is based on the code currently used
> by the LibreELEC distro, excluding hard/soft reset, and with cabac table
> and scaling matrix functions picked from Sebastian Fricke prior series
> to add a HEVC backend [2].
> 
> Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
> this series possible!
> 
> Patch 1 add the new HEVC backend.
> Patch 2-3 add variants support to the driver.
> Patch 4 add support for a rk3288 variant.
> Patch 5 add a rk3328 variant to work around hw quirks.
> Patch 6-7 add device tree node for rk3288.
> 
> This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
> 
>   v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
>   ...
>   Total for rkvdec device /dev/video1: 49, Succeeded: 49, Failed: 0, Warnings:
> 0
> 
>   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
>   ...
>   Ran 137/147 tests successfully

I've also tested RK3399 using Renegade Elite from Libre Computer, though with
GStreamer. My results for this suite is 134/147, with failing tests being:

- DBLK_D_VIXS_2
- DSLICE_A_HHI_5
- DELTAQP_A_BRCM_4
- EXT_A_ericsson_4
- PICSIZE_A_Bossen_1 (expected)
- PICSIZE_B_Bossen_1 (expected)
- PICSIZE_C_Bossen_1 (expected)
- PICSIZE_D_Bossen_1 (expected)
- SAODBLK_A_MainConcept_4
- SAODBLK_B_MainConcept_4
- TSUNEQBD_A_MAIN10_Technicolor_2 (expected)
- WPP_D_ericsson_MAIN10_2
- WPP_D_ericsson_MAIN_2

Please share your list, this seems big enough difference to be worth making sure
we did not diverge somewhere between both interpretation of the V4L2 spec.
GStreamer has been mostly tested with MTK driver so far. Can you also share a
link to the latest ffmpeg tree you are using (since its not upstream FFMPEG) ?

Detlev reports 146/147 on newer hardware using GStreamer, failing
TSUNEQBD_A_MAIN10_Technicolor_2 (9bit chroma) only. On Detlev side, it will we
important to check why 8K videos (PICSIZE*) passes with a single core, perhaps
we accidently use both cores ?

Note, also expected, we failt JCT-VC-SCC, JCT-VC-MV-HEVC, and JCT-VC-RExt passes
2/49. This last suite is pretty new in fluster.

regards,
Nicolas

> 
>   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
>   ...
>   Ran 9/9 tests successfully
> 
> And on a TinkerBoard (RK3288):
> 
>   v4l2-compliance 1.30.1, 32 bits, 32-bit time_t
>   ...
>   Total for rkvdec device /dev/video3: 49, Succeeded: 49, Failed: 0, Warnings:
> 0
> 
>   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
>   ...
>   Ran 137/147 tests successfully
> 
>   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
>   ...
>   Ran 9/9 tests successfully
> 
> The WPP_x_ericsson tests from test suite JCT-VC-HEVC_V1 has been showing
> a mix of both Success and/or Fail result for FFmpeg-H.265-v4l2request.
> 
> Full summary of fluster run can be found at [3].
> 
> Please note that there is a known issue with concurrent decoding,
> decoding errors in one decode session may affect a separate session.
> The only known mitigation to this is to pause decoding for some time
> and/or do a full HW reset, something to handle in future series.
> 
> Changes in v2:
> - Rabase after h264 high10/422 merge and unstaging of rkvdec driver
> - Use new_value in transpose_and_flatten_matrices()
> - Add NULL check for ctrl->new_elems in rkvdec_hevc_run_preamble()
> - Set RKVDEC_WR_DDR_ALIGN_EN for RK3328
> - Adjust code style in rkvdec_enum_coded_fmt_desc()
> - Collect a-b tag
> - Drop merged vdec node reg size patches
> Link to v1:
> https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se
> 
> [1]
> https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-2000-v4l2-wip-rkvdec-hevc.patch
> [2]
> https://lore.kernel.org/linux-media/20230101-patch-series-v2-6-2-rc1-v2-0-fa1897efac14@collabora.com/
> [3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d
> 
> Alex Bee (4):
>   media: rkvdec: Add variants support
>   media: rkvdec: Add RK3288 variant
>   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
>   ARM: dts: rockchip: Add vdec node for RK3288
> 
> Jonas Karlman (3):
>   media: rkvdec: Add HEVC backend
>   media: rkvdec: Implement capability filtering
>   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
> 
>  .../bindings/media/rockchip,vdec.yaml         |    1 +
>  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
>  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
>  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
>  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
>  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
>  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
>  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
>  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
>  9 files changed, 2886 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

On Monday, 11 August 2025 17:52:42 EDT Nicolas Dufresne wrote:
> Le dimanche 10 août 2025 à 21:24 +0000, Jonas Karlman a écrit :
> > This series add a HEVC backend to the Rockchip Video Decoder driver.
> > 
> > With the dependent H.264 High 10 and 4:2:2 profile support series
> > finally merged there is finally time to send a v2 with minor changes and
> > a suggested code style fix of this series. v1 of this series has been
> > fully functional up until recent unstaging of the rkvdec driver.
> > 
> > A version of this HEVC backend has been in use by the LibreELEC distro
> > for the past 5+ years [1]. It was initially created based on a copy of
> > the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
> > matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
> > 
> > It has since then been extended to use the stable HEVC uAPI controls and
> > improved opon e.g. to include support for rk3288 and fix decoding issues
> > by Alex Bee and Nicolas Dufresne.
> > 
> > The version submitted in this series is based on the code currently used
> > by the LibreELEC distro, excluding hard/soft reset, and with cabac table
> > and scaling matrix functions picked from Sebastian Fricke prior series
> > to add a HEVC backend [2].
> > 
> > Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
> > this series possible!
> > 
> > Patch 1 add the new HEVC backend.
> > Patch 2-3 add variants support to the driver.
> > Patch 4 add support for a rk3288 variant.
> > Patch 5 add a rk3328 variant to work around hw quirks.
> > Patch 6-7 add device tree node for rk3288.
> > 
> > This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
> > 
> >   v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
> >   ...
> >   Total for rkvdec device /dev/video1: 49, Succeeded: 49, Failed: 0,
> > Warnings: 0
> > 
> >   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
> >   ...
> >   Ran 137/147 tests successfully
> 
> I've also tested RK3399 using Renegade Elite from Libre Computer, though
> with GStreamer. My results for this suite is 134/147, with failing tests
> being:
> 
> - DBLK_D_VIXS_2
> - DSLICE_A_HHI_5
> - DELTAQP_A_BRCM_4
> - EXT_A_ericsson_4
> - PICSIZE_A_Bossen_1 (expected)
> - PICSIZE_B_Bossen_1 (expected)
> - PICSIZE_C_Bossen_1 (expected)
> - PICSIZE_D_Bossen_1 (expected)
> - SAODBLK_A_MainConcept_4
> - SAODBLK_B_MainConcept_4
> - TSUNEQBD_A_MAIN10_Technicolor_2 (expected)
> - WPP_D_ericsson_MAIN10_2
> - WPP_D_ericsson_MAIN_2
> 
> Please share your list, this seems big enough difference to be worth making
> sure we did not diverge somewhere between both interpretation of the V4L2
> spec. GStreamer has been mostly tested with MTK driver so far. Can you also
> share a link to the latest ffmpeg tree you are using (since its not
> upstream FFMPEG) ?
> 
> Detlev reports 146/147 on newer hardware using GStreamer, failing
> TSUNEQBD_A_MAIN10_Technicolor_2 (9bit chroma) only. On Detlev side, it will
> we important to check why 8K videos (PICSIZE*) passes with a single core,
> perhaps we accidently use both cores ?

1 core can do 8K. In theory, it can do up to close to 65535x65535... It is 
only a speed issue, so you can do 8K but you won't be able to get to 8K@60 
with only one core on rk3588.

> Note, also expected, we failt JCT-VC-SCC, JCT-VC-MV-HEVC, and JCT-VC-RExt
> passes 2/49. This last suite is pretty new in fluster.
> 
> regards,
> Nicolas
> 
> >   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
> >   ...
> >   Ran 9/9 tests successfully
> > 
> > And on a TinkerBoard (RK3288):
> > 
> >   v4l2-compliance 1.30.1, 32 bits, 32-bit time_t
> >   ...
> >   Total for rkvdec device /dev/video3: 49, Succeeded: 49, Failed: 0,
> > Warnings: 0
> > 
> >   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
> >   ...
> >   Ran 137/147 tests successfully
> > 
> >   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
> >   ...
> >   Ran 9/9 tests successfully
> > 
> > The WPP_x_ericsson tests from test suite JCT-VC-HEVC_V1 has been showing
> > a mix of both Success and/or Fail result for FFmpeg-H.265-v4l2request.
> > 
> > Full summary of fluster run can be found at [3].
> > 
> > Please note that there is a known issue with concurrent decoding,
> > decoding errors in one decode session may affect a separate session.
> > The only known mitigation to this is to pause decoding for some time
> > and/or do a full HW reset, something to handle in future series.
> > 
> > Changes in v2:
> > - Rabase after h264 high10/422 merge and unstaging of rkvdec driver
> > - Use new_value in transpose_and_flatten_matrices()
> > - Add NULL check for ctrl->new_elems in rkvdec_hevc_run_preamble()
> > - Set RKVDEC_WR_DDR_ALIGN_EN for RK3328
> > - Adjust code style in rkvdec_enum_coded_fmt_desc()
> > - Collect a-b tag
> > - Drop merged vdec node reg size patches
> > Link to v1:
> > https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.
> > se
> > 
> > [1]
> > https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/pa
> > tches/linux/default/linux-2000-v4l2-wip-rkvdec-hevc.patch [2]
> > https://lore.kernel.org/linux-media/20230101-patch-series-v2-6-2-rc1-v2-0-> > fa1897efac14@collabora.com/ [3]
> > https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d
> > 
> > Alex Bee (4):
> >   media: rkvdec: Add variants support
> >   media: rkvdec: Add RK3288 variant
> >   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
> >   ARM: dts: rockchip: Add vdec node for RK3288
> > 
> > Jonas Karlman (3):
> >   media: rkvdec: Add HEVC backend
> >   media: rkvdec: Implement capability filtering
> >   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
> > 
> >  .../bindings/media/rockchip,vdec.yaml         |    1 +
> >  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
> >  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
> >  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
> >  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
> >  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
> >  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
> >  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
> >  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
> >  9 files changed, 2886 insertions(+), 21 deletions(-)
> >  create mode 100644
> > drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c create mode
> > 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

Hi,

Le mardi 12 août 2025 à 15:57 -0400, Detlev Casanova a écrit :
> > Detlev reports 146/147 on newer hardware using GStreamer, failing
> > TSUNEQBD_A_MAIN10_Technicolor_2 (9bit chroma) only. On Detlev side, it will
> > we important to check why 8K videos (PICSIZE*) passes with a single core,
> > perhaps we accidently use both cores ?
> 
> 1 core can do 8K. In theory, it can do up to close to 65535x65535... It is 
> only a speed issue, so you can do 8K but you won't be able to get to 8K@60 
> with only one core on rk3588.

now that makes me wonder if that means we can reach speed such as 240Hz 4K by
slaving the cores, of if that only works for 8K. If this is the case, perhaps
the decoder will need to be target performance aware to make the best
scheduling.

Nicolas

Hi Nicolas,

On 8/11/2025 11:52 PM, Nicolas Dufresne wrote:
> Le dimanche 10 août 2025 à 21:24 +0000, Jonas Karlman a écrit :
>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>
>> With the dependent H.264 High 10 and 4:2:2 profile support series
>> finally merged there is finally time to send a v2 with minor changes and
>> a suggested code style fix of this series. v1 of this series has been
>> fully functional up until recent unstaging of the rkvdec driver.
>>
>> A version of this HEVC backend has been in use by the LibreELEC distro
>> for the past 5+ years [1]. It was initially created based on a copy of
>> the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
>> matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
>>
>> It has since then been extended to use the stable HEVC uAPI controls and
>> improved opon e.g. to include support for rk3288 and fix decoding issues
>> by Alex Bee and Nicolas Dufresne.
>>
>> The version submitted in this series is based on the code currently used
>> by the LibreELEC distro, excluding hard/soft reset, and with cabac table
>> and scaling matrix functions picked from Sebastian Fricke prior series
>> to add a HEVC backend [2].
>>
>> Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
>> this series possible!
>>
>> Patch 1 add the new HEVC backend.
>> Patch 2-3 add variants support to the driver.
>> Patch 4 add support for a rk3288 variant.
>> Patch 5 add a rk3328 variant to work around hw quirks.
>> Patch 6-7 add device tree node for rk3288.
>>
>> This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
>>
>>   v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
>>   ...
>>   Total for rkvdec device /dev/video1: 49, Succeeded: 49, Failed: 0, Warnings:
>> 0
>>
>>   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
>>   ...
>>   Ran 137/147 tests successfully
> 
> I've also tested RK3399 using Renegade Elite from Libre Computer, though with
> GStreamer. My results for this suite is 134/147, with failing tests being:
> 
> - DBLK_D_VIXS_2
> - DSLICE_A_HHI_5
> - DELTAQP_A_BRCM_4
> - EXT_A_ericsson_4
> - PICSIZE_A_Bossen_1 (expected)
> - PICSIZE_B_Bossen_1 (expected)
> - PICSIZE_C_Bossen_1 (expected)
> - PICSIZE_D_Bossen_1 (expected)
> - SAODBLK_A_MainConcept_4
> - SAODBLK_B_MainConcept_4
> - TSUNEQBD_A_MAIN10_Technicolor_2 (expected)
> - WPP_D_ericsson_MAIN10_2
> - WPP_D_ericsson_MAIN_2
> 
> Please share your list, this seems big enough difference to be worth making sure
> we did not diverge somewhere between both interpretation of the V4L2 spec.
> GStreamer has been mostly tested with MTK driver so far. Can you also share a
> link to the latest ffmpeg tree you are using (since its not upstream FFMPEG) ?

As mentioned in this cover letter the full fluster report can be found
at [3], and has links to the trees used to produce the raw report data,
have now also added some more details of versions used.

The tests from the report was running on a RK3399 Rock Pi 4B v1.5.

- Linux: 6.17-rc1 + patches
- fluster: 0.4.1 + patch
- FFmpeg: 7.1.1 + patches
- GStreamer: 1.27.1

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)

JCT-VC-HEVC_V1 on FFmpeg-H.265-v4l2request:

- CONFWIN_A_Sony_1 (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)
- VPSSPSPPS_A_MainConcept_1 (error)

The WPP_*_ericsson_MAIN* samples get a mixed Fail/Success when running
the full test suite for FFmpeg-H.265-v4l2request, however retrying them
individually they will eventually report Success. Not sure this is an
issue with FFmpeg or the driver, since they pass with GStreamer.

Interesting that DBLK_D_VIXS_2, DSLICE_A_HHI_5 and CONFWIN_A_Sony_1
consistently differs between GStreamer and FFmpeg.

[3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d

> 
> Detlev reports 146/147 on newer hardware using GStreamer, failing
> TSUNEQBD_A_MAIN10_Technicolor_2 (9bit chroma) only. On Detlev side, it will we
> important to check why 8K videos (PICSIZE*) passes with a single core, perhaps
> we accidently use both cores ?
> 
> Note, also expected, we failt JCT-VC-SCC, JCT-VC-MV-HEVC, and JCT-VC-RExt passes
> 2/49. This last suite is pretty new in fluster.

Following is the FFmpeg-H.265-v4l2request result with this:

- JCT-VC-MV-HEVC 9/9
- JCT-VC-RExt 2/49
- JCT-VC-SCC 0/15
- JCT-VC-3D-HEVC 27/27
- JCT-VC-SHVC 1/69

Regards,
Jonas

> 
> regards,
> Nicolas
> 
>>
>>   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
>>   ...
>>   Ran 9/9 tests successfully
>>
>> And on a TinkerBoard (RK3288):
>>
>>   v4l2-compliance 1.30.1, 32 bits, 32-bit time_t
>>   ...
>>   Total for rkvdec device /dev/video3: 49, Succeeded: 49, Failed: 0, Warnings:
>> 0
>>
>>   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
>>   ...
>>   Ran 137/147 tests successfully
>>
>>   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
>>   ...
>>   Ran 9/9 tests successfully
>>
>> The WPP_x_ericsson tests from test suite JCT-VC-HEVC_V1 has been showing
>> a mix of both Success and/or Fail result for FFmpeg-H.265-v4l2request.
>>
>> Full summary of fluster run can be found at [3].
>>
>> Please note that there is a known issue with concurrent decoding,
>> decoding errors in one decode session may affect a separate session.
>> The only known mitigation to this is to pause decoding for some time
>> and/or do a full HW reset, something to handle in future series.
>>
>> Changes in v2:
>> - Rabase after h264 high10/422 merge and unstaging of rkvdec driver
>> - Use new_value in transpose_and_flatten_matrices()
>> - Add NULL check for ctrl->new_elems in rkvdec_hevc_run_preamble()
>> - Set RKVDEC_WR_DDR_ALIGN_EN for RK3328
>> - Adjust code style in rkvdec_enum_coded_fmt_desc()
>> - Collect a-b tag
>> - Drop merged vdec node reg size patches
>> Link to v1:
>> https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se
>>
>> [1]
>> https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-2000-v4l2-wip-rkvdec-hevc.patch
>> [2]
>> https://lore.kernel.org/linux-media/20230101-patch-series-v2-6-2-rc1-v2-0-fa1897efac14@collabora.com/
>> [3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d
>>
>> Alex Bee (4):
>>   media: rkvdec: Add variants support
>>   media: rkvdec: Add RK3288 variant
>>   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
>>   ARM: dts: rockchip: Add vdec node for RK3288
>>
>> Jonas Karlman (3):
>>   media: rkvdec: Add HEVC backend
>>   media: rkvdec: Implement capability filtering
>>   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
>>
>>  .../bindings/media/rockchip,vdec.yaml         |    1 +
>>  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
>>  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
>>  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
>>  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
>>  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
>>  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
>>  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
>>  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
>>  9 files changed, 2886 insertions(+), 21 deletions(-)
>>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
>>  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

Le mardi 12 août 2025 à 02:00 +0200, Jonas Karlman a écrit :
> Hi Nicolas,
> 
> On 8/11/2025 11:52 PM, Nicolas Dufresne wrote:
> > Le dimanche 10 août 2025 à 21:24 +0000, Jonas Karlman a écrit :
> > > This series add a HEVC backend to the Rockchip Video Decoder driver.
> > > 
> > > With the dependent H.264 High 10 and 4:2:2 profile support series
> > > finally merged there is finally time to send a v2 with minor changes and
> > > a suggested code style fix of this series. v1 of this series has been
> > > fully functional up until recent unstaging of the rkvdec driver.
> > > 
> > > A version of this HEVC backend has been in use by the LibreELEC distro
> > > for the past 5+ years [1]. It was initially created based on a copy of
> > > the H264 backend, unstable HEVC uAPI controls and a cabac table + scaling
> > > matrix functions shamelessly copied 1:1 from the Rockchip mpp library.
> > > 
> > > It has since then been extended to use the stable HEVC uAPI controls and
> > > improved opon e.g. to include support for rk3288 and fix decoding issues
> > > by Alex Bee and Nicolas Dufresne.
> > > 
> > > The version submitted in this series is based on the code currently used
> > > by the LibreELEC distro, excluding hard/soft reset, and with cabac table
> > > and scaling matrix functions picked from Sebastian Fricke prior series
> > > to add a HEVC backend [2].
> > > 
> > > Big thanks to Alex Bee, Nicolas Dufresne and Sebastian Fricke for making
> > > this series possible!
> > > 
> > > Patch 1 add the new HEVC backend.
> > > Patch 2-3 add variants support to the driver.
> > > Patch 4 add support for a rk3288 variant.
> > > Patch 5 add a rk3328 variant to work around hw quirks.
> > > Patch 6-7 add device tree node for rk3288.
> > > 
> > > This was tested on a ROCK Pi 4 (RK3399) and Rock64 (RK3328):
> > > 
> > >   v4l2-compliance 1.30.1, 64 bits, 64-bit time_t
> > >   ...
> > >   Total for rkvdec device /dev/video1: 49, Succeeded: 49, Failed: 0, Warnings:
> > > 0
> > > 
> > >   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
> > >   ...
> > >   Ran 137/147 tests successfully
> > 
> > I've also tested RK3399 using Renegade Elite from Libre Computer, though with
> > GStreamer. My results for this suite is 134/147, with failing tests being:
> > 
> > - DBLK_D_VIXS_2
> > - DSLICE_A_HHI_5
> > - DELTAQP_A_BRCM_4
> > - EXT_A_ericsson_4
> > - PICSIZE_A_Bossen_1 (expected)
> > - PICSIZE_B_Bossen_1 (expected)
> > - PICSIZE_C_Bossen_1 (expected)
> > - PICSIZE_D_Bossen_1 (expected)
> > - SAODBLK_A_MainConcept_4
> > - SAODBLK_B_MainConcept_4
> > - TSUNEQBD_A_MAIN10_Technicolor_2 (expected)
> > - WPP_D_ericsson_MAIN10_2
> > - WPP_D_ericsson_MAIN_2
> > 
> > Please share your list, this seems big enough difference to be worth making sure
> > we did not diverge somewhere between both interpretation of the V4L2 spec.
> > GStreamer has been mostly tested with MTK driver so far. Can you also share a
> > link to the latest ffmpeg tree you are using (since its not upstream FFMPEG) ?
> 
> As mentioned in this cover letter the full fluster report can be found
> at [3], and has links to the trees used to produce the raw report data,
> have now also added some more details of versions used.

Missed that, sorry.

> 
> The tests from the report was running on a RK3399 Rock Pi 4B v1.5.
> 
> - Linux: 6.17-rc1 + patches
> - fluster: 0.4.1 + patch
> - FFmpeg: 7.1.1 + patches
> - GStreamer: 1.27.1
> 
> 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)
> 
> JCT-VC-HEVC_V1 on FFmpeg-H.265-v4l2request:
> 
> - CONFWIN_A_Sony_1 (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)
> - VPSSPSPPS_A_MainConcept_1 (error)
> 
> The WPP_*_ericsson_MAIN* samples get a mixed Fail/Success when running
> the full test suite for FFmpeg-H.265-v4l2request, however retrying them
> individually they will eventually report Success. Not sure this is an
> issue with FFmpeg or the driver, since they pass with GStreamer.
> 
> Interesting that DBLK_D_VIXS_2, DSLICE_A_HHI_5 and CONFWIN_A_Sony_1
> consistently differs between GStreamer and FFmpeg.

Indeed, let's identify the differences in parameters. For CONFWIN though,
Benjamin implemented pretty much a hack in GStreamer to support it. This video
utilize the x,y coordinate of the conformance window, while maintaining the same
resolution during playback. This x/y coordinate is rarely used in real world, so
this shouldn't be a priority.

I think for both GStreamer and FFMPEG, the right way would be to signal the crop
over the padded area and leave it to some render filter handle it. For flake,
that's something to check, but also not really a blocker.

> 
> [3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d
> 
> > 
> > Detlev reports 146/147 on newer hardware using GStreamer, failing
> > TSUNEQBD_A_MAIN10_Technicolor_2 (9bit chroma) only. On Detlev side, it will we
> > important to check why 8K videos (PICSIZE*) passes with a single core, perhaps
> > we accidently use both cores ?
> > 
> > Note, also expected, we failt JCT-VC-SCC, JCT-VC-MV-HEVC, and JCT-VC-RExt passes
> > 2/49. This last suite is pretty new in fluster.
> 
> Following is the FFmpeg-H.265-v4l2request result with this:
> 
> - JCT-VC-MV-HEVC 9/9
> - JCT-VC-RExt 2/49
> - JCT-VC-SCC 0/15
> - JCT-VC-3D-HEVC 27/27

Nice we have the same for RExt, and glad we can do MVC and 3D without additional
control. These last two are simply not implemented in GStreamer. For SCC, we are
missing some information, and the hardware probably does not handle it.

cheers,
Nicolas

> - JCT-VC-SHVC 1/69
> 
> Regards,
> Jonas
> 
> > 
> > regards,
> > Nicolas
> > 
> > > 
> > >   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
> > >   ...
> > >   Ran 9/9 tests successfully
> > > 
> > > And on a TinkerBoard (RK3288):
> > > 
> > >   v4l2-compliance 1.30.1, 32 bits, 32-bit time_t
> > >   ...
> > >   Total for rkvdec device /dev/video3: 49, Succeeded: 49, Failed: 0, Warnings:
> > > 0
> > > 
> > >   Running test suite JCT-VC-HEVC_V1 with decoder FFmpeg-H.265-v4l2request
> > >   ...
> > >   Ran 137/147 tests successfully
> > > 
> > >   Running test suite JCT-VC-MV-HEVC with decoder FFmpeg-H.265-v4l2request
> > >   ...
> > >   Ran 9/9 tests successfully
> > > 
> > > The WPP_x_ericsson tests from test suite JCT-VC-HEVC_V1 has been showing
> > > a mix of both Success and/or Fail result for FFmpeg-H.265-v4l2request.
> > > 
> > > Full summary of fluster run can be found at [3].
> > > 
> > > Please note that there is a known issue with concurrent decoding,
> > > decoding errors in one decode session may affect a separate session.
> > > The only known mitigation to this is to pause decoding for some time
> > > and/or do a full HW reset, something to handle in future series.
> > > 
> > > Changes in v2:
> > > - Rabase after h264 high10/422 merge and unstaging of rkvdec driver
> > > - Use new_value in transpose_and_flatten_matrices()
> > > - Add NULL check for ctrl->new_elems in rkvdec_hevc_run_preamble()
> > > - Set RKVDEC_WR_DDR_ALIGN_EN for RK3328
> > > - Adjust code style in rkvdec_enum_coded_fmt_desc()
> > > - Collect a-b tag
> > > - Drop merged vdec node reg size patches
> > > Link to v1:
> > > https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se
> > > 
> > > [1]
> > > https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-2000-v4l2-wip-rkvdec-hevc.patch
> > > [2]
> > > https://lore.kernel.org/linux-media/20230101-patch-series-v2-6-2-rc1-v2-0-fa1897efac14@collabora.com/
> > > [3] https://gist.github.com/Kwiboo/bedf1f447b50921ffbe26cb99579582d
> > > 
> > > Alex Bee (4):
> > >   media: rkvdec: Add variants support
> > >   media: rkvdec: Add RK3288 variant
> > >   media: rkvdec: Disable QoS for HEVC and VP9 on RK3328
> > >   ARM: dts: rockchip: Add vdec node for RK3288
> > > 
> > > Jonas Karlman (3):
> > >   media: rkvdec: Add HEVC backend
> > >   media: rkvdec: Implement capability filtering
> > >   media: dt-bindings: rockchip,vdec: Add RK3288 compatible
> > > 
> > >  .../bindings/media/rockchip,vdec.yaml         |    1 +
> > >  arch/arm/boot/dts/rockchip/rk3288.dtsi        |   17 +-
> > >  .../media/platform/rockchip/rkvdec/Makefile   |    2 +-
> > >  .../rockchip/rkvdec/rkvdec-hevc-data.c        | 1848 +++++++++++++++++
> > >  .../platform/rockchip/rkvdec/rkvdec-hevc.c    |  826 ++++++++
> > >  .../platform/rockchip/rkvdec/rkvdec-regs.h    |    4 +
> > >  .../platform/rockchip/rkvdec/rkvdec-vp9.c     |   10 +
> > >  .../media/platform/rockchip/rkvdec/rkvdec.c   |  184 +-
> > >  .../media/platform/rockchip/rkvdec/rkvdec.h   |   15 +
> > >  9 files changed, 2886 insertions(+), 21 deletions(-)
> > >  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-data.c
> > >  create mode 100644 drivers/media/platform/rockchip/rkvdec/rkvdec-hevc.c

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.

Nicolas

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.

[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

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.

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

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

Le mardi 12 août 2025 à 14:26 -0400, Nicolas Dufresne a écrit :
> 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 did the test, and its not that. There is no error in fact, just corrupted
image. The more parallelism, the more failure. Another important key point, no
mmu faults, so its not that. You also reported flakyness, and rerunning making
it work.

The problem is likely due to some register left to its previous value,
forgotten. If you let it sit, it will PM suspend, and a proper reset happens.
The stream then decodes fine. If you run it concurrently with another, it
decodes from dirt and fails. I think that theory fits a lot better, and is a
very common issue. Adding a hard reset would not fix this one.

Porting to in-ram register is the easiest way to fix that. It really reminds me
of:

  7fcb42b3835e9 media: verisilicon: HEVC: Initialize start_bit field

Which tool quite some time to find.

Nicolas

> 
> 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