All of lore.kernel.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

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

  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.