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

["Heiko Stübner" <heiko@sntech.de>]

Am Freitag, 6. Juni 2025, 04:17:53 Mitteleuropäische Sommerzeit schrieb Chen-Yu Tsai:
> On Fri, Jun 6, 2025 at 2:57 AM Heiko Stuebner <heiko@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.

yeah - definitly.

After sending this v2 yesterday, I re-read Quentin's comment on v1 and
finally understood the meaning - which was the same, that the driver
might be a nicer place for default values.

So yesterday evening I did parse the datasheets of all the regulator
variants to get the relevant (and different) startup times.

Hopefully I'll get this done and sent out before lunch today :-) .

Heiko