public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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


      reply	other threads:[~2025-06-05  9:24 UTC|newest]

Thread overview: 5+ 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-05  8:57 ` Quentin Schulz
2025-06-05  9:05   ` Quentin Schulz
2025-06-05  9:09   ` Heiko Stübner
2025-06-05  9:22     ` Quentin Schulz [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox