[PATCH v2 08/12] arm64: dts: rockchip: rk3588s-nanopi: remove always-on from vdd_npu_s0 reg
Jonas Karlman
jonas at kwiboo.se
Sun Jul 12 11:22:31 PDT 2026
Hi Joachim,
On 7/12/2026 8:00 PM, Joachim Eastwood wrote:
> Hi Jonas,
>
> On Sat, 11 Jul 2026 at 01:24, Jonas Karlman <jonas at kwiboo.xyz> wrote:
>>
>> Hi Joachim,
>>
>> On 7/11/2026 12:11 AM, Joachim Eastwood via B4 Relay wrote:
>>> From: Joachim Eastwood <joachim.eastwood at gmail.com>
>>>
>>> Since the NPU is hooked up on these the always-on isn't needed anymore.
>>>
>>> Signed-off-by: Joachim Eastwood <joachim.eastwood at gmail.com>
>>> ---
>>> arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
>>> index bcb2f5d63a61..463cfeddf270 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
>>> @@ -258,7 +258,6 @@ vdd_npu_s0: regulator at 42 {
>>> regulator-max-microvolt = <950000>;
>>> regulator-ramp-delay = <2300>;
>>> regulator-boot-on;
>>
>> Why is boot-on kept?, NPU is likely not needed until OS has started.
>
> I am not really sure.
> Looking at the other rk3588(s) boards, they also kept the boot-on parameter
> when the always-on was removed.
Ahh, those board should likely also drop the boot-on prop. There should
really not be any need to force the PMIC to enable this regulator from
firmware. If it was left intentionally for other boards, maybe there is
a bug in software that need to be fixed.
>
>> With PD domain-supply the regulator should be enabled automatically, or
>> is there some other issue that requires boot firmware to enable this
>> regulator before OS is started?
>
> Maybe some Rockchip people can enlighten us?
>
> I haven't had the time to actually test the NPU. I'll try to test it next week.
> So this patch is based on similar changes done to other RK3588 boards.
Yes, please drop the boot-on prop and test :-)
Regards,
Jonas
>
>
> best regards,
> Joachim Eastwood
More information about the Linux-rockchip
mailing list