[PATCH v2] arm64: dts: rockchip: add regulator-enable-ramp-delay to RK860-0/-2/-3 regulators

[Chen-Yu Tsai]

On Fri, Jun 6, 2025 at 2:57 AM Heiko Stuebner <heiko at sntech.de> wrote:
>
> The RK860-0/-1/-2/-3 regulators are used on rk3588 boards in addition to
> the main pmic, to supply components like the big cpu-clusters and npu.
>
> So far nobody had a use-case for turning these off. The supplies for the
> big cpu-clusters are on by default and those clusters normally are not
> completely turned off during runtime.
>
> This changed with the new Rocket driver for the NPU, which does use
> runtime-pm and thus does turn off and on the NPU's supply regulator as
> needed. This regulator is also needed to run to actually turn on the
> power-domain for the NPU.
>
> If the rocket driver now runtime-suspends while running a load and then
> runtime-resumes again, hangs can be observed with messages like
>
>   rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set domain 'nputop' on, val=0
>
> A way to "fix" that issue when it happens, is to set the regulator to
> always-on. This suggests that the power-domain is trying to get power
> from the regulator before it is ready to deliver power.
>
> And in fact the datasheet for the regulator defines an "Internal soft-start
> time" characteristic. For a target output voltage of 1.0V the _typical_
> time to reach at least 92% of the output, is given as 260uS.
>
> That means the time is dependent on the target voltage (up to 1.5V for
> the type) and also the rest of the board design.
>
> So add a regulator-enable-ramp-delay to all rk860-2/-3 nodes we have in
> mainline right now. I've chosen 500uS to be on the safe side, as
> 260uS is the "typical" value for 1.0V and sadly no max value is given
> in the datasheet.

Since these are characteristics of the PMIC, I wonder if it makes more
sense to put them in the driver? At least that's what we've done with a
similar fix for the AXP PMICs.

ChenYu

>
> This adds the property to all rk8600, rk8602 and rk8603 occurences that
> are in mainline as of 6.16-rc1. There is currently no rk8601 used in
> any in-kernel devicetree.