From: Quentin Schulz <quentin.schulz@cherry.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: jonas@kwiboo.se, dsimic@manjaro.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: add regulator-enable-ramp-delay to RK860-2/-3 regulators
Date: Thu, 5 Jun 2025 11:22:26 +0200 [thread overview]
Message-ID: <b42e28fb-e254-4901-932f-c5282c189dea@cherry.de> (raw)
In-Reply-To: <49977521.MN2xkq1pzW@diego>
Hi Heiko,
On 6/5/25 11:09 AM, Heiko Stübner wrote:
> Am Donnerstag, 5. Juni 2025, 10:57:13 Mitteleuropäische Sommerzeit schrieb Quentin Schulz:
>> Hi Heiko,
>>
>> On 6/4/25 10:24 PM, Heiko Stuebner wrote:
[...]
>>> And in fact the datasheet for the regulator defines an "Internal soft-start
>>> time". For a target output voltage of 1.0V the _typical_ time to reach at
>>> least 92% of the output is given as 260uS.
>>>
>>
>> Indeed. Now looking at the existing Device Trees, it seems some set the
>> ramp-up delay already, but to 2300 and not 500 like suggested here.
>> Maybe it'd be safer to go for 2300 by default then?
>
> enable-ramp-delay is a totally different beast than the ramp-delay.
> ramp-delay is needed when changing the running voltage and uses a unit
> of "uV/us", so microvolt per microsecond ... where the enable-ramp-delay
> is the one for enabling the regulator and uses uS.
Thanks for the explanation.
[...]
>>> 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.
>>>
>>
>> Reading the rk808 regulator driver... maybe we should also set the
>> typical delay as default in the fan53555.c driver? See rk805_reg which
>> sets the enable_time for some (typically the LDO with 400 and the DCDC
>> at 0). I assume those can be overridden from the DT anyway, but at least
>> we would have some decently safe defaults?
>>
>> If we do not do this, then we should probably force the presence of
>> regulator-ramp-delay property for the rk860x DT binding so we don't
>> forget for future Device Trees?
>
> that is scope-creep (rk808 != rk860) ... but I find the idea of trying to
I was just hinting at the possibility to set a default enable_time if
one's missing from the Device Tree because the rk808 driver seems to be
doing something like that. rk860-x is indeed supported by a different
driver, which doesn't set this by default, hence my suggestion :)
> set the enable-ramp-delay as required for the rk860-x interesting :-) .
>
But incompatible with the "default in driver" approach :) So one or the
other :)
Cheers,
Quentin
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Schulz <quentin.schulz@cherry.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: jonas@kwiboo.se, dsimic@manjaro.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: add regulator-enable-ramp-delay to RK860-2/-3 regulators
Date: Thu, 5 Jun 2025 11:22:26 +0200 [thread overview]
Message-ID: <b42e28fb-e254-4901-932f-c5282c189dea@cherry.de> (raw)
In-Reply-To: <49977521.MN2xkq1pzW@diego>
Hi Heiko,
On 6/5/25 11:09 AM, Heiko Stübner wrote:
> Am Donnerstag, 5. Juni 2025, 10:57:13 Mitteleuropäische Sommerzeit schrieb Quentin Schulz:
>> Hi Heiko,
>>
>> On 6/4/25 10:24 PM, Heiko Stuebner wrote:
[...]
>>> And in fact the datasheet for the regulator defines an "Internal soft-start
>>> time". For a target output voltage of 1.0V the _typical_ time to reach at
>>> least 92% of the output is given as 260uS.
>>>
>>
>> Indeed. Now looking at the existing Device Trees, it seems some set the
>> ramp-up delay already, but to 2300 and not 500 like suggested here.
>> Maybe it'd be safer to go for 2300 by default then?
>
> enable-ramp-delay is a totally different beast than the ramp-delay.
> ramp-delay is needed when changing the running voltage and uses a unit
> of "uV/us", so microvolt per microsecond ... where the enable-ramp-delay
> is the one for enabling the regulator and uses uS.
Thanks for the explanation.
[...]
>>> 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.
>>>
>>
>> Reading the rk808 regulator driver... maybe we should also set the
>> typical delay as default in the fan53555.c driver? See rk805_reg which
>> sets the enable_time for some (typically the LDO with 400 and the DCDC
>> at 0). I assume those can be overridden from the DT anyway, but at least
>> we would have some decently safe defaults?
>>
>> If we do not do this, then we should probably force the presence of
>> regulator-ramp-delay property for the rk860x DT binding so we don't
>> forget for future Device Trees?
>
> that is scope-creep (rk808 != rk860) ... but I find the idea of trying to
I was just hinting at the possibility to set a default enable_time if
one's missing from the Device Tree because the rk808 driver seems to be
doing something like that. rk860-x is indeed supported by a different
driver, which doesn't set this by default, hence my suggestion :)
> set the enable-ramp-delay as required for the rk860-x interesting :-) .
>
But incompatible with the "default in driver" approach :) So one or the
other :)
Cheers,
Quentin
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-06-05 9:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 20:24 [PATCH] arm64: dts: rockchip: add regulator-enable-ramp-delay to RK860-2/-3 regulators Heiko Stuebner
2025-06-04 20:24 ` Heiko Stuebner
2025-06-05 8:57 ` Quentin Schulz
2025-06-05 8:57 ` Quentin Schulz
2025-06-05 9:05 ` Quentin Schulz
2025-06-05 9:05 ` Quentin Schulz
2025-06-05 9:09 ` Heiko Stübner
2025-06-05 9:09 ` Heiko Stübner
2025-06-05 9:22 ` Quentin Schulz [this message]
2025-06-05 9:22 ` Quentin Schulz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b42e28fb-e254-4901-932f-c5282c189dea@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=dsimic@manjaro.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.