[PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant

[PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant

[Christian Hewitt]

This series depends upon Detlev Casanova's current v8 series for VDPU381 and
VDPU383 support [0]. It adds support for the VDPU346 IP block used for H264,
HEVC and (in active work) VP9 on the RK356X boards. VDPU346 appears to be a
close relation to VDPU381 used with RK3588, except with a single core, output
limited to 4K, and minor feature differences, e.g. HEVC level 5.1 on VDPU346
vs 6.1 on VDPU381. To handle differences we declare a new compatible.

The device-tree changes are derived from prior-art in Detlev's patches for
RK3576 and RK3588, the vendor kernel [1], and some earlier patch attempts
from Piotr Oniszczuk and Diederik de Haas.

The register differences between VDPU346 and VDPU381 appear to be minimal so
we currently and intentionally reuse the VDPU381 h264, hevc, and regs files
to avoid duplicating code. There is some evidence of buffer size changes in
testing which still need to be explored. If further register analysis needs
separate files for VDPU346 the refactoring will be beyond my current n00b
coding skills and I will either need some coaching or would be happy to pass
the series over to a more experienced developer.

NB: Testing with the v1 series showed lower mbps bitrate performance. This
appears to be resolved though it's unclear to me whether this results from
kernel changes or the ongoing reworking of ffmpeg v4l2_request support [2].
However with my current Linux 6.19-rc4 test branch [3] I'm now able to play
Jellyfish H264 and HEVC test media over 100mbps.

Changes since v2:
- Use correct .max_width/.max_height from TRM (Diederik De Haas)
- Add Tested-by from Dang Huynh

Changes since v1:
- Drop DO-NOT-MERGE patch as changes included in Detvlev v7 series
- Adapt to variant/capability changes in Detlev's v7 series
- Add bindings ack from Rob
- Add rkvdec ack from Nicolas
- Rebase against Linux 6.19-rc2

[0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=1040540
[1] https://github.com/rockchip-linux/kernel/blob/develop-6.6/arch/arm64/boot/dts/rockchip/rk356x.dtsi#L1539
[2] https://code.ffmpeg.org/Kwiboo/FFmpeg/commits/branch/v4l2request-v3
[3] https://github.com/chewitt/linux/commits/rockchip-6.19.y

Christian Hewitt (3):
  media: dt-bindings: rockchip: Add RK3568 Video Decoder bindings
  media: rkvdec: Add support for the VDPU346 variant
  arm64: dts: rockchip: Add the vdpu346 Video Decoders on RK356X

 .../bindings/media/rockchip,vdec.yaml         |   2 +
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi |  49 +++++++++
 .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
 3 files changed, 154 insertions(+)

-- 
2.43.0

[PATCH v3 1/3] media: dt-bindings: rockchip: Add RK3568 Video Decoder bindings

[Christian Hewitt]

The video decoder in RK356X (vdpu346) is described in the same way as
the one in RK3588 (vdpu381). A new compatible is added as the decoder
capabilities are a subset of the vdpu381 capabilities.

Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
 Documentation/devicetree/bindings/media/rockchip,vdec.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
index 809fda45b3bd..656ceb1f116e 100644
--- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
@@ -18,6 +18,7 @@ properties:
     oneOf:
       - const: rockchip,rk3288-vdec
       - const: rockchip,rk3399-vdec
+      - const: rockchip,rk3568-vdec
       - const: rockchip,rk3576-vdec
       - const: rockchip,rk3588-vdec
       - items:
@@ -107,6 +108,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - rockchip,rk3568-vdec
               - rockchip,rk3576-vdec
               - rockchip,rk3588-vdec
     then:
-- 
2.43.0

[PATCH v3 2/3] media: rkvdec: Add support for the VDPU346 variant

[Christian Hewitt]

VDPU346 is similar to VDPU381 but with a single core and limited
to 4K60 media. It is also limited to H264 L5.1 and omits AV1 and
AVS2 capabilities. VDPU346 is used with RK3566 and RK3568.

Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Dang Huynh <dang.huynh@mainlining.org> # Pinetab2
---
 .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index a5cf6f3240f8..6e49b129d11f 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -236,6 +236,62 @@ static const struct rkvdec_ctrls rkvdec_hevc_ctrls = {
 	.num_ctrls = ARRAY_SIZE(rkvdec_hevc_ctrl_descs),
 };
 
+static const struct rkvdec_ctrl_desc vdpu346_hevc_ctrl_descs[] = {
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_SPS,
+		.cfg.ops = &rkvdec_ctrl_ops,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_PPS,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_MODE,
+		.cfg.min = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+		.cfg.max = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+		.cfg.def = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_START_CODE,
+		.cfg.min = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+		.cfg.def = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+		.cfg.max = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
+	},
+	{
+		.cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
+		.cfg.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+		.cfg.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
+		.cfg.menu_skip_mask =
+			BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
+		.cfg.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+	},
+	{
+		.cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
+		.cfg.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
+		.cfg.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS,
+		.cfg.ops = &rkvdec_ctrl_ops,
+		.cfg.dims = { 65 },
+	},
+	{
+		.cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS,
+		.cfg.ops = &rkvdec_ctrl_ops,
+		.cfg.dims = { 65 },
+	},
+};
+
+static const struct rkvdec_ctrls vdpu346_hevc_ctrls = {
+	.ctrls = vdpu346_hevc_ctrl_descs,
+	.num_ctrls = ARRAY_SIZE(vdpu346_hevc_ctrl_descs),
+};
+
 static const struct rkvdec_ctrl_desc vdpu38x_hevc_ctrl_descs[] = {
 	{
 		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
@@ -463,6 +519,41 @@ static const struct rkvdec_coded_fmt_desc rk3288_coded_fmts[] = {
 	}
 };
 
+static const struct rkvdec_coded_fmt_desc vdpu346_coded_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
+		.frmsize = {
+			.min_width = 64,
+			.max_width = 4096,
+			.step_width = 64,
+			.min_height = 64,
+			.max_height = 2304,
+			.step_height = 16,
+		},
+		.ctrls = &vdpu346_hevc_ctrls,
+		.ops = &rkvdec_vdpu381_hevc_fmt_ops,
+		.num_decoded_fmts = ARRAY_SIZE(rkvdec_hevc_decoded_fmts),
+		.decoded_fmts = rkvdec_hevc_decoded_fmts,
+		.subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.frmsize = {
+			.min_width = 64,
+			.max_width =  4096,
+			.step_width = 64,
+			.min_height = 64,
+			.max_height =  2304,
+			.step_height = 16,
+		},
+		.ctrls = &rkvdec_h264_ctrls,
+		.ops = &rkvdec_vdpu381_h264_fmt_ops,
+		.num_decoded_fmts = ARRAY_SIZE(rkvdec_h264_decoded_fmts),
+		.decoded_fmts = rkvdec_h264_decoded_fmts,
+		.subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
+	},
+};
+
 static const struct rkvdec_coded_fmt_desc vdpu381_coded_fmts[] = {
 	{
 		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
@@ -1657,6 +1748,14 @@ static const struct rkvdec_variant_ops vdpu381_variant_ops = {
 	.flatten_matrices = transpose_and_flatten_matrices,
 };
 
+static const struct rkvdec_variant vdpu346_variant = {
+	.coded_fmts = vdpu346_coded_fmts,
+	.num_coded_fmts = ARRAY_SIZE(vdpu346_coded_fmts),
+	.rcb_sizes = vdpu381_rcb_sizes,
+	.num_rcb_sizes = ARRAY_SIZE(vdpu381_rcb_sizes),
+	.ops = &vdpu381_variant_ops,
+};
+
 static const struct rkvdec_variant vdpu381_variant = {
 	.coded_fmts = vdpu381_coded_fmts,
 	.num_coded_fmts = ARRAY_SIZE(vdpu381_coded_fmts),
@@ -1705,6 +1804,10 @@ static const struct of_device_id of_rkvdec_match[] = {
 		.compatible = "rockchip,rk3399-vdec",
 		.data = &rk3399_rkvdec_variant,
 	},
+	{
+		.compatible = "rockchip,rk3568-vdec",
+		.data = &vdpu346_variant,
+	},
 	{
 		.compatible = "rockchip,rk3588-vdec",
 		.data = &vdpu381_variant,
-- 
2.43.0

Re: [PATCH v3 2/3] media: rkvdec: Add support for the VDPU346 variant

[Diederik de Haas]

Hi Christian,

On Sat Jan 10, 2026 at 6:37 AM CET, Christian Hewitt wrote:
> VDPU346 is similar to VDPU381 but with a single core and limited
> to 4K60 media. It is also limited to H264 L5.1 and omits AV1 and
> AVS2 capabilities. VDPU346 is used with RK3566 and RK3568.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Tested-by: Dang Huynh <dang.huynh@mainlining.org> # Pinetab2
> ---
>  .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
>  1 file changed, 103 insertions(+)
>
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> index a5cf6f3240f8..6e49b129d11f 100644
> --- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> @@ -236,6 +236,62 @@ static const struct rkvdec_ctrls rkvdec_hevc_ctrls = {
>  	.num_ctrls = ARRAY_SIZE(rkvdec_hevc_ctrl_descs),
>  };
>  
> +static const struct rkvdec_ctrl_desc vdpu346_hevc_ctrl_descs[] = {
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_SPS,
> +		.cfg.ops = &rkvdec_ctrl_ops,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_PPS,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_MODE,
> +		.cfg.min = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
> +		.cfg.max = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
> +		.cfg.def = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_START_CODE,
> +		.cfg.min = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
> +		.cfg.def = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
> +		.cfg.max = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
> +		.cfg.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> +		.cfg.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
> +		.cfg.menu_skip_mask =
> +			BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
> +		.cfg.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
> +		.cfg.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
> +		.cfg.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS,
> +		.cfg.ops = &rkvdec_ctrl_ops,
> +		.cfg.dims = { 65 },
> +	},
> +	{
> +		.cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS,
> +		.cfg.ops = &rkvdec_ctrl_ops,
> +		.cfg.dims = { 65 },
> +	},
> +};
> +
> +static const struct rkvdec_ctrls vdpu346_hevc_ctrls = {
> +	.ctrls = vdpu346_hevc_ctrl_descs,
> +	.num_ctrls = ARRAY_SIZE(vdpu346_hevc_ctrl_descs),
> +};
> +
>  static const struct rkvdec_ctrl_desc vdpu38x_hevc_ctrl_descs[] = {
>  	{
>  		.cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
> @@ -463,6 +519,41 @@ static const struct rkvdec_coded_fmt_desc rk3288_coded_fmts[] = {
>  	}
>  };
>  
> +static const struct rkvdec_coded_fmt_desc vdpu346_coded_fmts[] = {
> +	{
> +		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
> +		.frmsize = {
> +			.min_width = 64,
> +			.max_width = 4096,
> +			.step_width = 64,
> +			.min_height = 64,
> +			.max_height = 2304,
> +			.step_height = 16,
> +		},
> +		.ctrls = &vdpu346_hevc_ctrls,
> +		.ops = &rkvdec_vdpu381_hevc_fmt_ops,
> +		.num_decoded_fmts = ARRAY_SIZE(rkvdec_hevc_decoded_fmts),
> +		.decoded_fmts = rkvdec_hevc_decoded_fmts,
> +		.subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> +		.frmsize = {
> +			.min_width = 64,
> +			.max_width =  4096,
> +			.step_width = 64,
> +			.min_height = 64,
> +			.max_height =  2304,
> +			.step_height = 16,
> +		},
> +		.ctrls = &rkvdec_h264_ctrls,
> +		.ops = &rkvdec_vdpu381_h264_fmt_ops,
> +		.num_decoded_fmts = ARRAY_SIZE(rkvdec_h264_decoded_fmts),
> +		.decoded_fmts = rkvdec_h264_decoded_fmts,
> +		.subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
> +	},
> +};
> +
>  static const struct rkvdec_coded_fmt_desc vdpu381_coded_fmts[] = {
>  	{
>  		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
> @@ -1657,6 +1748,14 @@ static const struct rkvdec_variant_ops vdpu381_variant_ops = {
>  	.flatten_matrices = transpose_and_flatten_matrices,
>  };
>  
> +static const struct rkvdec_variant vdpu346_variant = {
> +	.coded_fmts = vdpu346_coded_fmts,
> +	.num_coded_fmts = ARRAY_SIZE(vdpu346_coded_fmts),
> +	.rcb_sizes = vdpu381_rcb_sizes,

AFAICT this is not correct, the rcb_sizes are different for vdpu346 vs
vdpu381. While for vdpu381 the sizes are the same across codecs, they
vary for vdpu346. And vdpu346 does not have 'STRMD Row', 'Transd Row'
and 'Transd col'.

For RK3588/vdpu381 it is defined in RK3588 TRM V1.0 Part1 in
paragraph 5.4.4.3 in 'Table 5-13 Row or Col buffer size required' on
page 381.

For RK3568/vdpu346 is is defines in RK3568 TRM V1.1 Part2 in
paragraph 10.4.8 in 'Table 10-9 Row or Col buffer size required' on page
474 and 475.

Cheers,
  Diederik

> +	.num_rcb_sizes = ARRAY_SIZE(vdpu381_rcb_sizes),
> +	.ops = &vdpu381_variant_ops,
> +};
> +
>  static const struct rkvdec_variant vdpu381_variant = {
>  	.coded_fmts = vdpu381_coded_fmts,
>  	.num_coded_fmts = ARRAY_SIZE(vdpu381_coded_fmts),
> @@ -1705,6 +1804,10 @@ static const struct of_device_id of_rkvdec_match[] = {
>  		.compatible = "rockchip,rk3399-vdec",
>  		.data = &rk3399_rkvdec_variant,
>  	},
> +	{
> +		.compatible = "rockchip,rk3568-vdec",
> +		.data = &vdpu346_variant,
> +	},
>  	{
>  		.compatible = "rockchip,rk3588-vdec",
>  		.data = &vdpu381_variant,

Re: [PATCH v3 2/3] media: rkvdec: Add support for the VDPU346 variant

[Christian Hewitt]

> On 10 Jan 2026, at 11:35 pm, Diederik de Haas <diederik@cknow-tech.com> wrote:
> 
> Hi Christian,
> 
> On Sat Jan 10, 2026 at 6:37 AM CET, Christian Hewitt wrote:
>> VDPU346 is similar to VDPU381 but with a single core and limited
>> to 4K60 media. It is also limited to H264 L5.1 and omits AV1 and
>> AVS2 capabilities. VDPU346 is used with RK3566 and RK3568.
>> 
>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
>> Tested-by: Dang Huynh <dang.huynh@mainlining.org> # Pinetab2
>> ---
>> .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
>> 1 file changed, 103 insertions(+)
>> 
>> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>> index a5cf6f3240f8..6e49b129d11f 100644
>> --- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>> @@ -236,6 +236,62 @@ static const struct rkvdec_ctrls rkvdec_hevc_ctrls = {
>> .num_ctrls = ARRAY_SIZE(rkvdec_hevc_ctrl_descs),
>> };
>> 
>> +static const struct rkvdec_ctrl_desc vdpu346_hevc_ctrl_descs[] = {
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_SPS,
>> + .cfg.ops = &rkvdec_ctrl_ops,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_PPS,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_MODE,
>> + .cfg.min = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>> + .cfg.max = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>> + .cfg.def = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_START_CODE,
>> + .cfg.min = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>> + .cfg.def = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>> + .cfg.max = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
>> + .cfg.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
>> + .cfg.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
>> + .cfg.menu_skip_mask =
>> + BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
>> + .cfg.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
>> + .cfg.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
>> + .cfg.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS,
>> + .cfg.ops = &rkvdec_ctrl_ops,
>> + .cfg.dims = { 65 },
>> + },
>> + {
>> + .cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS,
>> + .cfg.ops = &rkvdec_ctrl_ops,
>> + .cfg.dims = { 65 },
>> + },
>> +};
>> +
>> +static const struct rkvdec_ctrls vdpu346_hevc_ctrls = {
>> + .ctrls = vdpu346_hevc_ctrl_descs,
>> + .num_ctrls = ARRAY_SIZE(vdpu346_hevc_ctrl_descs),
>> +};
>> +
>> static const struct rkvdec_ctrl_desc vdpu38x_hevc_ctrl_descs[] = {
>> {
>> .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
>> @@ -463,6 +519,41 @@ static const struct rkvdec_coded_fmt_desc rk3288_coded_fmts[] = {
>> }
>> };
>> 
>> +static const struct rkvdec_coded_fmt_desc vdpu346_coded_fmts[] = {
>> + {
>> + .fourcc = V4L2_PIX_FMT_HEVC_SLICE,
>> + .frmsize = {
>> + .min_width = 64,
>> + .max_width = 4096,
>> + .step_width = 64,
>> + .min_height = 64,
>> + .max_height = 2304,
>> + .step_height = 16,
>> + },
>> + .ctrls = &vdpu346_hevc_ctrls,
>> + .ops = &rkvdec_vdpu381_hevc_fmt_ops,
>> + .num_decoded_fmts = ARRAY_SIZE(rkvdec_hevc_decoded_fmts),
>> + .decoded_fmts = rkvdec_hevc_decoded_fmts,
>> + .subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
>> + },
>> + {
>> + .fourcc = V4L2_PIX_FMT_H264_SLICE,
>> + .frmsize = {
>> + .min_width = 64,
>> + .max_width =  4096,
>> + .step_width = 64,
>> + .min_height = 64,
>> + .max_height =  2304,
>> + .step_height = 16,
>> + },
>> + .ctrls = &rkvdec_h264_ctrls,
>> + .ops = &rkvdec_vdpu381_h264_fmt_ops,
>> + .num_decoded_fmts = ARRAY_SIZE(rkvdec_h264_decoded_fmts),
>> + .decoded_fmts = rkvdec_h264_decoded_fmts,
>> + .subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
>> + },
>> +};
>> +
>> static const struct rkvdec_coded_fmt_desc vdpu381_coded_fmts[] = {
>> {
>> .fourcc = V4L2_PIX_FMT_HEVC_SLICE,
>> @@ -1657,6 +1748,14 @@ static const struct rkvdec_variant_ops vdpu381_variant_ops = {
>> .flatten_matrices = transpose_and_flatten_matrices,
>> };
>> 
>> +static const struct rkvdec_variant vdpu346_variant = {
>> + .coded_fmts = vdpu346_coded_fmts,
>> + .num_coded_fmts = ARRAY_SIZE(vdpu346_coded_fmts),
>> + .rcb_sizes = vdpu381_rcb_sizes,
> 
> AFAICT this is not correct, the rcb_sizes are different for vdpu346 vs
> vdpu381. While for vdpu381 the sizes are the same across codecs, they
> vary for vdpu346. And vdpu346 does not have 'STRMD Row', 'Transd Row'
> and 'Transd col'.
> 
> For RK3588/vdpu381 it is defined in RK3588 TRM V1.0 Part1 in
> paragraph 5.4.4.3 in 'Table 5-13 Row or Col buffer size required' on
> page 381.
> 
> For RK3568/vdpu346 is is defines in RK3568 TRM V1.1 Part2 in
> paragraph 10.4.8 in 'Table 10-9 Row or Col buffer size required' on page
> 474 and 475.

This is what I’m hinting/referring to in the cover-letter. How
to correctly handle the differences in code is currently beyond
my n00b level comprehension of c and coding skills. I’ll need to
ask the audience for some assistance and coaching :)

Christian

>> + .num_rcb_sizes = ARRAY_SIZE(vdpu381_rcb_sizes),
>> + .ops = &vdpu381_variant_ops,
>> +};
>> +
>> static const struct rkvdec_variant vdpu381_variant = {
>> .coded_fmts = vdpu381_coded_fmts,
>> .num_coded_fmts = ARRAY_SIZE(vdpu381_coded_fmts),
>> @@ -1705,6 +1804,10 @@ static const struct of_device_id of_rkvdec_match[] = {
>> .compatible = "rockchip,rk3399-vdec",
>> .data = &rk3399_rkvdec_variant,
>> },
>> + {
>> + .compatible = "rockchip,rk3568-vdec",
>> + .data = &vdpu346_variant,
>> + },
>> {
>> .compatible = "rockchip,rk3588-vdec",
>> .data = &vdpu381_variant,

Re: [PATCH v3 2/3] media: rkvdec: Add support for the VDPU346 variant

[Diederik de Haas]

On Sun Jan 11, 2026 at 2:30 PM CET, Christian Hewitt wrote:
>> On 10 Jan 2026, at 11:35 pm, Diederik de Haas <diederik@cknow-tech.com> wrote:
>> On Sat Jan 10, 2026 at 6:37 AM CET, Christian Hewitt wrote:
>>> VDPU346 is similar to VDPU381 but with a single core and limited
>>> to 4K60 media. It is also limited to H264 L5.1 and omits AV1 and
>>> AVS2 capabilities. VDPU346 is used with RK3566 and RK3568.
>>> 
>>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>>> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
>>> Tested-by: Dang Huynh <dang.huynh@mainlining.org> # Pinetab2
>>> ---
>>> .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
>>> 1 file changed, 103 insertions(+)
>>> 
>>> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>>> index a5cf6f3240f8..6e49b129d11f 100644
>>> --- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>>> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
>>> @@ -236,6 +236,62 @@ static const struct rkvdec_ctrls rkvdec_hevc_ctrls = {
>>> .num_ctrls = ARRAY_SIZE(rkvdec_hevc_ctrl_descs),
>>> };
>>> 
>>> +static const struct rkvdec_ctrl_desc vdpu346_hevc_ctrl_descs[] = {
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_SPS,
>>> + .cfg.ops = &rkvdec_ctrl_ops,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_PPS,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_SCALING_MATRIX,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_MODE,
>>> + .cfg.min = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>>> + .cfg.max = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>>> + .cfg.def = V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_START_CODE,
>>> + .cfg.min = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>>> + .cfg.def = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>>> + .cfg.max = V4L2_STATELESS_HEVC_START_CODE_ANNEX_B,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
>>> + .cfg.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
>>> + .cfg.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
>>> + .cfg.menu_skip_mask =
>>> + BIT(V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE),
>>> + .cfg.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
>>> + .cfg.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
>>> + .cfg.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS,
>>> + .cfg.ops = &rkvdec_ctrl_ops,
>>> + .cfg.dims = { 65 },
>>> + },
>>> + {
>>> + .cfg.id = V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS,
>>> + .cfg.ops = &rkvdec_ctrl_ops,
>>> + .cfg.dims = { 65 },
>>> + },
>>> +};
>>> +
>>> +static const struct rkvdec_ctrls vdpu346_hevc_ctrls = {
>>> + .ctrls = vdpu346_hevc_ctrl_descs,
>>> + .num_ctrls = ARRAY_SIZE(vdpu346_hevc_ctrl_descs),
>>> +};
>>> +
>>> static const struct rkvdec_ctrl_desc vdpu38x_hevc_ctrl_descs[] = {
>>> {
>>> .cfg.id = V4L2_CID_STATELESS_HEVC_DECODE_PARAMS,
>>> @@ -463,6 +519,41 @@ static const struct rkvdec_coded_fmt_desc rk3288_coded_fmts[] = {
>>> }
>>> };
>>> 
>>> +static const struct rkvdec_coded_fmt_desc vdpu346_coded_fmts[] = {
>>> + {
>>> + .fourcc = V4L2_PIX_FMT_HEVC_SLICE,
>>> + .frmsize = {
>>> + .min_width = 64,
>>> + .max_width = 4096,
>>> + .step_width = 64,
>>> + .min_height = 64,
>>> + .max_height = 2304,
>>> + .step_height = 16,
>>> + },
>>> + .ctrls = &vdpu346_hevc_ctrls,
>>> + .ops = &rkvdec_vdpu381_hevc_fmt_ops,
>>> + .num_decoded_fmts = ARRAY_SIZE(rkvdec_hevc_decoded_fmts),
>>> + .decoded_fmts = rkvdec_hevc_decoded_fmts,
>>> + .subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
>>> + },
>>> + {
>>> + .fourcc = V4L2_PIX_FMT_H264_SLICE,
>>> + .frmsize = {
>>> + .min_width = 64,
>>> + .max_width =  4096,
>>> + .step_width = 64,
>>> + .min_height = 64,
>>> + .max_height =  2304,
>>> + .step_height = 16,
>>> + },
>>> + .ctrls = &rkvdec_h264_ctrls,
>>> + .ops = &rkvdec_vdpu381_h264_fmt_ops,
>>> + .num_decoded_fmts = ARRAY_SIZE(rkvdec_h264_decoded_fmts),
>>> + .decoded_fmts = rkvdec_h264_decoded_fmts,
>>> + .subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF,
>>> + },
>>> +};
>>> +
>>> static const struct rkvdec_coded_fmt_desc vdpu381_coded_fmts[] = {
>>> {
>>> .fourcc = V4L2_PIX_FMT_HEVC_SLICE,
>>> @@ -1657,6 +1748,14 @@ static const struct rkvdec_variant_ops vdpu381_variant_ops = {
>>> .flatten_matrices = transpose_and_flatten_matrices,
>>> };
>>> 
>>> +static const struct rkvdec_variant vdpu346_variant = {
>>> + .coded_fmts = vdpu346_coded_fmts,
>>> + .num_coded_fmts = ARRAY_SIZE(vdpu346_coded_fmts),
>>> + .rcb_sizes = vdpu381_rcb_sizes,
>> 
>> AFAICT this is not correct, the rcb_sizes are different for vdpu346 vs
>> vdpu381. While for vdpu381 the sizes are the same across codecs, they
>> vary for vdpu346. And vdpu346 does not have 'STRMD Row', 'Transd Row'
>> and 'Transd col'.
>> 
>> For RK3588/vdpu381 it is defined in RK3588 TRM V1.0 Part1 in
>> paragraph 5.4.4.3 in 'Table 5-13 Row or Col buffer size required' on
>> page 381.
>> 
>> For RK3568/vdpu346 is is defines in RK3568 TRM V1.1 Part2 in
>> paragraph 10.4.8 in 'Table 10-9 Row or Col buffer size required' on page
>> 474 and 475.
>
> This is what I’m hinting/referring to in the cover-letter. How
> to correctly handle the differences in code is currently beyond
> my n00b level comprehension of c and coding skills. I’ll need to
> ask the audience for some assistance and coaching :)

Sorry, I should've been (more) clear that this remark was meant as a
'research note', to further improve support for RK3568.

And I forgot to mention that with Detlev's v8 series and your patch set,
all my test videos, except 4K, now play without any (visual) artifacts.
\o/

I still want to do more/further tests and wait till Detlev's series get
accepted, before giving my Tested-by tag.

Cheers,
  Diederik

> Christian
>
>>> + .num_rcb_sizes = ARRAY_SIZE(vdpu381_rcb_sizes),
>>> + .ops = &vdpu381_variant_ops,
>>> +};
>>> +
>>> static const struct rkvdec_variant vdpu381_variant = {
>>> .coded_fmts = vdpu381_coded_fmts,
>>> .num_coded_fmts = ARRAY_SIZE(vdpu381_coded_fmts),
>>> @@ -1705,6 +1804,10 @@ static const struct of_device_id of_rkvdec_match[] = {
>>> .compatible = "rockchip,rk3399-vdec",
>>> .data = &rk3399_rkvdec_variant,
>>> },
>>> + {
>>> + .compatible = "rockchip,rk3568-vdec",
>>> + .data = &vdpu346_variant,
>>> + },
>>> {
>>> .compatible = "rockchip,rk3588-vdec",
>>> .data = &vdpu381_variant,

[PATCH v3 3/3] arm64: dts: rockchip: Add the vdpu346 Video Decoders on RK356X

[Christian Hewitt]

Add the vdpu346 Video Decoders to the rk356x-base devicetree to
enable support on RK3566 and RK3568 boards. Also add the needed
sram and vdec_mmu nodes.

Suggested-by: Diederik de Haas <diederik@cknow-tech.com>
Suggested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index a2c4957a5899..11536684479b 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -383,6 +383,19 @@ usb2phy1_grf: syscon@fdca8000 {
 		reg = <0x0 0xfdca8000 0x0 0x8000>;
 	};
 
+	sram@fdcc0000 {
+		compatible = "mmio-sram";
+		reg = <0x0 0xfdcc0000 0x0 0xb000>;
+		ranges = <0x0 0x0 0xfdcc0000 0xb000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		vdec_sram: rkvdec-sram@0 {
+			reg = <0x0 0xb000>;
+			pool;
+		};
+	};
+
 	pmucru: clock-controller@fdd00000 {
 		compatible = "rockchip,rk3568-pmucru";
 		reg = <0x0 0xfdd00000 0x0 0x1000>;
@@ -619,6 +632,42 @@ vepu_mmu: iommu@fdee0800 {
 		#iommu-cells = <0>;
 	};
 
+	vdec: video-codec@fdf80100 {
+		compatible = "rockchip,rk3568-vdec";
+		reg = <0x0 0xfdf80200 0x0 0x500>,
+		      <0x0 0xfdf80100 0x0 0x100>,
+		      <0x0 0xfdf80700 0x0 0x100>;
+		reg-names = "function", "link", "cache";
+		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_RKVDEC>, <&cru HCLK_RKVDEC>,
+			 <&cru CLK_RKVDEC_CA>, <&cru CLK_RKVDEC_CORE>,
+			 <&cru CLK_RKVDEC_HEVC_CA>;
+		clock-names = "axi", "ahb", "cabac", "core", "hevc_cabac";
+		assigned-clocks = <&cru ACLK_RKVDEC>,
+				  <&cru CLK_RKVDEC_CORE>,
+				  <&cru CLK_RKVDEC_CA>,
+				  <&cru CLK_RKVDEC_HEVC_CA>;
+		assigned-clock-rates = <297000000>, <297000000>,
+				       <297000000>, <600000000>;
+		iommus = <&vdec_mmu>;
+		power-domains = <&power RK3568_PD_RKVDEC>;
+		resets = <&cru SRST_A_RKVDEC>, <&cru SRST_H_RKVDEC>,
+			 <&cru SRST_RKVDEC_CA>, <&cru SRST_RKVDEC_CORE>,
+			 <&cru SRST_RKVDEC_HEVC_CA>;
+		reset-names = "axi", "ahb", "cabac", "core", "hevc_cabac";
+		sram = <&vdec_sram>;
+	};
+
+	vdec_mmu: iommu@fdf80800 {
+		compatible = "rockchip,rk3568-iommu";
+		reg = <0x0 0xfdf80800 0x0 0x40>, <0x0 0xfdf80840 0x0 0x40>;
+		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_RKVDEC>, <&cru HCLK_RKVDEC>;
+		clock-names = "aclk", "iface";
+		power-domains = <&power RK3568_PD_RKVDEC>;
+		#iommu-cells = <0>;
+	};
+
 	vicap: video-capture@fdfe0000 {
 		compatible = "rockchip,rk3568-vicap";
 		reg = <0x0 0xfdfe0000 0x0 0x200>;
-- 
2.43.0

Re: [PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant

[Diederik de Haas]

Hi Christian,

On Sat Jan 10, 2026 at 6:37 AM CET, Christian Hewitt wrote:
> This series depends upon Detlev Casanova's current v8 series for VDPU381 and
> VDPU383 support [0]. It adds support for the VDPU346 IP block used for H264,
> HEVC and (in active work) VP9 on the RK356X boards. VDPU346 appears to be a
> close relation to VDPU381 used with RK3588, except with a single core, output
> limited to 4K, and minor feature differences, e.g. HEVC level 5.1 on VDPU346
> vs 6.1 on VDPU381. To handle differences we declare a new compatible.
> ...
> NB: Testing with the v1 series showed lower mbps bitrate performance. This
> appears to be resolved though it's unclear to me whether this results from
> kernel changes or the ongoing reworking of ffmpeg v4l2_request support [2].
> However with my current Linux 6.19-rc4 test branch [3] I'm now able to play
> Jellyfish H264 and HEVC test media over 100mbps.

I've now done quite a bit of testing on 3 separate devices: TL;DR:

Tested-by: Diederik de Haas <diederik@cknow-tech.com>  # PineTab2, Quartz64-A, NanoPi R5S

My main test setup was with Sway and mpv, which was based on a
self-compiled ffmpeg from [2] (commit: ea34873176, [4]) and mpv PR 14690
[5] (commit: 307d2a8 [6]).
That all ran on a Debian Forky system with my own 6.19-rc5 kernel ([7]).
Detlev's v8 series made things quite a bit better vs previous versions.

I also did a quick test with that same mpv and kernel, but then on KDE
Plasma and only on the PineTab2.

Finally, I did some tests with custom LibreELEC builds [8], which also
uses the code from this patch set.

While using the ``--vo=dmabuf-wayland`` parameter with mpv wasn't needed
on Rock 5B (RK3588) with most of my test files, it was absolutely needed
for all my test files on RK3566/RK3568.

Playing 1080p (or lower) media was either perfect or quite good, meaning
sometimes little artifacts were visible. This was on the PineTab2's
(RK3566) own screen or on my 1080p monitor with the Q64-A (RK3566) or
the NanoPi R5S (RK3568). Using the 'i'/'I' keyboard shortcut to display
an overlay with display statistics or enabling subtitles was generally a
'way' to get more artifacts. With 'i'/'I' you'd then also see the frame
drop count rise.
This was the case with both H264 and HEVC files, where I got the
'feeling' that HEVC worked (just) a bit better. Dunno if that's because
of the codec or that the video bitrate is lower with HEVC. Quite a few
of my test files are in both H264 as HEVC.

Testing with the 'Jellyfin' files was generally perfect. The maximum
bitrate I have is 30M though. There were some artifacts visible on the
PineTab2 though. With Jellyfin's HEVC files, but not my own HEVC files,
I did see the following warnings in dmesg:

  rkvdec_hevc_run: 291 callbacks suppressed
  rkvdec fdf80200.video-codec: Long an short term RPS not set

But I think that's expected? (given Detlev's remark on v8 cover page)

Playing 4K media on a 1080p (or lower) screen resulted in severe audio
sync issues. It seems the video rendering actually works, but in 'slow
motion'. Hearing 2 secs of audio for 1 sec of video was not uncommon.
Even with 4K media files, the CPU utilization was still around 15-25% on
all cores.

When testing on KDE Plasma, the display results were quite a bit worse.
I primarily mention this as I suspect that the 'display pipeline'
(possibly not the correct technical term), plays an (important) factor.
CPU utilization often around 40% on all cores.

I then connected the Q64-A or NanoPi R5S to my 4K TV. Displaying 1080
media was generally 'reasonable', meaning artifacts were visible several
times during playback. 4K media files still had severe 'audio sync'
issues.

I then went on to try LibreELEC's builds. The artifacts I (sometimes)
saw, were gone :-D OTOH, I did get several major issues 'in return',
like rk_iommu Page fault resulting in a black screen and the only way to
'recover' from it, was a reboot. I also got a kernel oops.
Some dmesg logs available at [9].

Then I tried something ... for 'shits and giggles'.
I recently learned about a Costa Rica 'test video' in 4K HDR (YT ID:
``LXb3EKWsInQ``) and I converted that to H264 and HEVC. The H264 version
was identified by MediaInfo as 'High 10@L6' and the HEVC version as
'Main 10@L5.1@Main'.
I tried to play that on the Q64-A (RK3566) ... and saw my TV show a
'popup' indicating it recognized it as HDR :-O And it actually played
them. It seems it couldn't completely keep up as it seems too slow at
some points and then appear to make a 'jump' to the then current time
spot. I think it worked a bit better with the HEVC version then the H264
one. But proper viewing/testing was always interrupted by a rk_iommu
Page fault and thus a black screen.
It worked even better on the NanoPi R5S (RK3568) and may even have
played it correctly; otherwise it came *really* close. But here too, the
fun was interrrupted by a black screen at some point.

So it seems it may be able to play video files/formats which, according
to the TRM, it isn't supposed to be able to play?
Too early to tell, but seeing the 'HDR popup' was a really cool surprise.

So, it's not perfect and I suspect various elements in the 'display
pipeline' can/should/need to be improved. I have no idea which though.
But the current state is good enough for me to give my Tested-by tag.

HTH,
  Diederik

> [0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=1040540
> [1] https://github.com/rockchip-linux/kernel/blob/develop-6.6/arch/arm64/boot/dts/rockchip/rk356x.dtsi#L1539
> [2] https://code.ffmpeg.org/Kwiboo/FFmpeg/commits/branch/v4l2request-v3
> [3] https://github.com/chewitt/linux/commits/rockchip-6.19.y

[4] https://salsa.debian.org/diederik/ffmpeg/-/tree/v4l2request-v3-n8.1
[5] https://github.com/mpv-player/mpv/pull/14690
[6] https://salsa.debian.org/diederik/mpv/-/tree/v4l2request-support
[7] https://salsa.debian.org/diederik/linux/-/tree/cknow/master-next
[8] https://chewitt.libreelec.tv/testing/
[9] https://paste.sr.ht/~diederik/1d9468cbc52c49ec210b4b29754486608a9efea2
    https://paste.sr.ht/~diederik/214eb00f6ac634d16f54f25b2ec578ca27dc5134
    https://paste.sr.ht/~diederik/669c3731a108f650f9e0bdc03df848a69355d56f

> Christian Hewitt (3):
>   media: dt-bindings: rockchip: Add RK3568 Video Decoder bindings
>   media: rkvdec: Add support for the VDPU346 variant
>   arm64: dts: rockchip: Add the vdpu346 Video Decoders on RK356X
>
>  .../bindings/media/rockchip,vdec.yaml         |   2 +
>  arch/arm64/boot/dts/rockchip/rk356x-base.dtsi |  49 +++++++++
>  .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
>  3 files changed, 154 insertions(+)