Re: [PATCH v3 1/3] rockchip: Add initial RK3582 support

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Jonas,

On 8/11/25 7:09 PM, Jonas Karlman wrote:
> Hi Quentin,
> 
> On 8/11/2025 5:44 PM, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 8/11/25 12:26 AM, Jonas Karlman wrote:
>>> The RK3582 SoC is a variant of the RK3588S with some IP blocks disabled.
>>> What blocks are disabled/non-working is indicated by ip-state in OTP.
>>>
>>> This add initial support for RK3582 by using ft_system_setup() to mark
>>> any cpu and/or vdec/venc node with status=fail as indicated by ip-state.
>>>
>>> This apply same policy as vendor U-Boot for RK3582, i.e. two big cpu
>>> cores and one vdec/venc core is always failed/disabled.
>>>
>>> Enable Kconfig option OF_SYSTEM_SETUP in board defconfig to make use of
>>> the required DT fixups for RK3582 board variants.
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> Changes in v3:
>>> - Apply same policy for RK3582/RK3583 to match vendor U-Boot
>>>     linux-6.1-stan-rkr6 tag, allow use of the GPU and one vdec core.
>>
>> Isn't the GPU supposed to be possibly non-fonctional on RK3582/RK3583?
>> If we don't disable it in the DT, how will the system actually behave?
> 
> Not sure about this, I was also wondering what happened to the GPU, but
> this matches the updated policy [1] in vendor U-Boot and I do not want to
> deviate from the vendor policy:
> 
> [1] https://github.com/Kwiboo/u-boot-rockchip/commit/5566d7d920d20932d2188c0cec57cb9036a9eefd
> 

Fair enough.

>>
>> @Kever may have more official info on that?
>>
>> See remarks on v2 otherwise, most of them still apply.
>>
>>> - Update rkvdec node name to match latest mainling Linux DT patches.
>>
>> Should we rather wait for the patches to be actually merged before
>> trying to patch the device tree nodes that do not exist yet?
> 
> This is what I did for v1, however Kever mentioned:
> 
> "it would better to follow the vendor U-Boot as-is to handle the dts, eg.
> seems you have skip the dts handle for rkvenc/rkvdec".
> 
> So for v2+ I tried to anticipate those node names, and have also sent
> multiple reviews [2] to Linux ML for the rkvdec nodes to ensure the
> names matches. However, the latest DT patch [3] changed the reg order
> and thus the node name changed once again.
> 
> We could drop the rkvdec/rkvenc handling and add it later once nodes
> have finally landed, or keep the handling and just patch U-Boot in
> case the node names ends up being changed before merge.
> 

I just don't want to have to support patching multiple addresses if they 
change again before beign merged in linux :)

But Kever is the maintainer here and I don't have a strong opinion on 
this, so I would go with what Kever said.

Cheers,
Quentin