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

[Detlev Casanova <detlev.casanova@collabora.com>]

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