[PATCH v3 0/2] arm64: dts: rockchip: Add vdpu 381 and 383 nodes

Detlev Casanova posted 2 patches 3 months, 2 weeks ago
arch/arm64/boot/dts/rockchip/rk3576.dtsi      | 36 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 74 +++++++++++++++++++
2 files changed, 110 insertions(+)
[PATCH v3 0/2] arm64: dts: rockchip: Add vdpu 381 and 383 nodes
Posted by Detlev Casanova 3 months, 2 weeks ago
Add the nodes for vdpu 381 and 383, respectively RK3588 and RK3576.
To keep compatibility with older variants, the reg ranges order is not
in register order so that the function reg range is kept first.

Also adds the corresponding iommu nodes.

Note that on RK3588, both cores are added as it represents the hardware,
but the driver, later will only register the first one.

Regards,
Detlev.

Changes since v2:
 - Set the correct IRQ number for the second rk3588 core

Changes since v1:
 - Set node name to match first reg range

Detlev Casanova (2):
  arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588
  arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576

 arch/arm64/boot/dts/rockchip/rk3576.dtsi      | 36 +++++++++
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 74 +++++++++++++++++++
 2 files changed, 110 insertions(+)

-- 
2.51.1.dirty
Re: [PATCH v3 0/2] arm64: dts: rockchip: Add vdpu 381 and 383 nodes
Posted by Heiko Stuebner 4 weeks ago
On Mon, 20 Oct 2025 17:20:07 -0400, Detlev Casanova wrote:
> Add the nodes for vdpu 381 and 383, respectively RK3588 and RK3576.
> To keep compatibility with older variants, the reg ranges order is not
> in register order so that the function reg range is kept first.
> 
> Also adds the corresponding iommu nodes.
> 
> Note that on RK3588, both cores are added as it represents the hardware,
> but the driver, later will only register the first one.
> 
> [...]

Applied, thanks!

[1/2] arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588
      commit: f61731bd60627b129b688c2d7b2071a5fe7f01d7
[2/2] arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576
      commit: da0de806d8b46238ac3891a894806da4d1c26cdf

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>
Re: [PATCH v3 0/2] arm64: dts: rockchip: Add vdpu 381 and 383 nodes
Posted by Diederik de Haas 3 months, 2 weeks ago
Hi Detlev,

On Mon Oct 20, 2025 at 11:20 PM CEST, Detlev Casanova wrote:
> Add the nodes for vdpu 381 and 383, respectively RK3588 and RK3576.
> To keep compatibility with older variants, the reg ranges order is not
> in register order so that the function reg range is kept first.

This is a great comment, which I'd have preferred to have seen in the
commit messages themselves.

Especially since I'm getting DTB validation warnings:

  DTC [C] arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb
arch/arm64/boot/dts/rockchip/rk3576.dtsi:1292.30-1314.5: Warning (simple_bus_reg):
/soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
  DTC [C] arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dtb
arch/arm64/boot/dts/rockchip/rk3576.dtsi:1292.30-1314.5: Warning (simple_bus_reg):
/soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"


For some reason I'm not getting that for rk3588, which I need to
investigate further. Technically, I ran my DTB validation script on your
'add-vdpu381-and-383-to-rkvdec-v3-on-next' branch, but I don't see how
that would/could change the outcome.

My validation script does essentially this:
``make CHECK_DTBS=y W=1 $(get_my_dtbs)``

('get_my_dtbs' returns a list of dtb files I want to check)

So it looks like the DTB validation tool is not happy that the
reg ranges are not sorted in 'proper' order.

Note that the ``W=1`` is essential to see the warning, it does not show
up when ``W=0`` is used.
I'll leave it up to you and the maintainers to judge whether this is
problematic or not, but wanted to mention it.

Cheers,
  Diederik

> Also adds the corresponding iommu nodes.
>
> Note that on RK3588, both cores are added as it represents the hardware,
> but the driver, later will only register the first one.
>
> Regards,
> Detlev.
>
> Changes since v2:
>  - Set the correct IRQ number for the second rk3588 core
>
> Changes since v1:
>  - Set node name to match first reg range
>
> Detlev Casanova (2):
>   arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588
>   arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576
>
>  arch/arm64/boot/dts/rockchip/rk3576.dtsi      | 36 +++++++++
>  arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 74 +++++++++++++++++++
>  2 files changed, 110 insertions(+)
Re: [PATCH v3 0/2] arm64: dts: rockchip: Add vdpu 381 and 383 nodes
Posted by Detlev Casanova 3 months, 1 week ago
Hi Diederick,

On 10/24/25 15:20, Diederik de Haas wrote:
> Hi Detlev,
>
> On Mon Oct 20, 2025 at 11:20 PM CEST, Detlev Casanova wrote:
>> Add the nodes for vdpu 381 and 383, respectively RK3588 and RK3576.
>> To keep compatibility with older variants, the reg ranges order is not
>> in register order so that the function reg range is kept first.
> This is a great comment, which I'd have preferred to have seen in the
> commit messages themselves.
>
> Especially since I'm getting DTB validation warnings:
>
>    DTC [C] arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb
> arch/arm64/boot/dts/rockchip/rk3576.dtsi:1292.30-1314.5: Warning (simple_bus_reg):
> /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
>    DTC [C] arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dtb
> arch/arm64/boot/dts/rockchip/rk3576.dtsi:1292.30-1314.5: Warning (simple_bus_reg):
> /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
>
>
> For some reason I'm not getting that for rk3588, which I need to
> investigate further. Technically, I ran my DTB validation script on your
> 'add-vdpu381-and-383-to-rkvdec-v3-on-next' branch, but I don't see how
> that would/could change the outcome.
>
> My validation script does essentially this:
> ``make CHECK_DTBS=y W=1 $(get_my_dtbs)``
>
> ('get_my_dtbs' returns a list of dtb files I want to check)
>
> So it looks like the DTB validation tool is not happy that the
> reg ranges are not sorted in 'proper' order.
>
> Note that the ``W=1`` is essential to see the warning, it does not show
> up when ``W=0`` is used.
> I'll leave it up to you and the maintainers to judge whether this is
> problematic or not, but wanted to mention it.

The main reason for doing it this way is that the bindings are added to 
the already existing media/rockchip,vdec.yaml file.

In the previous version of the decoder, only the "function" registers 
existed. But in these 2 SoCs, the function registers are prepended by a 
range of 0x100 registers called "link".

At the binding level, I only could add "link" and "cache" after 
"function", so that rk3399 uses "maxItems: 1" and the other 2 use 
"minItems: 3".

Unfortunately, that forces the order in the device tree:

- function

- link

-cache

Which is not in register offset order, making the node called 
video-codec@27b00000 have its first reg entry at 27b00100.

I have to admit I only checked that the check tools were happy for 
rk3588 and did the same for rk3576.

The only difference I see that could explain why it warns only on rk356 
is that rk3576 device nodes are children of "/soc" and the rk3588 ones 
are children of "/".

Let's see what maintainers think indeed.


Detlev.

>
> Cheers,
>    Diederik

>> Also adds the corresponding iommu nodes.
>>
>> Note that on RK3588, both cores are added as it represents the hardware,
>> but the driver, later will only register the first one.
>>
>> Regards,
>> Detlev.
>>
>> Changes since v2:
>>   - Set the correct IRQ number for the second rk3588 core
>>
>> Changes since v1:
>>   - Set node name to match first reg range
>>
>> Detlev Casanova (2):
>>    arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588
>>    arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576
>>
>>   arch/arm64/boot/dts/rockchip/rk3576.dtsi      | 36 +++++++++
>>   arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 74 +++++++++++++++++++
>>   2 files changed, 110 insertions(+)
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip