From: Torsten Duwe <duwe@lst.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 6/9] regulator: Add support for ramp delay
Date: Mon, 18 Feb 2019 16:26:57 +0100 [thread overview]
Message-ID: <20190218152657.GC6623@lst.de> (raw)
In-Reply-To: <CAJKOXPfhuONpy0TY6WpE9RORhLddUAvWn5uu112Kq40MjnY-bQ@mail.gmail.com>
On Mon, Feb 18, 2019 at 03:28:46PM +0100, Krzysztof Kozlowski wrote:
> On Mon, 18 Feb 2019 at 15:03, Torsten Duwe <duwe@lst.de> wrote:
> >
> > > --- a/doc/device-tree-bindings/regulator/regulator.txt
> > > +++ b/doc/device-tree-bindings/regulator/regulator.txt
> > > @@ -35,6 +35,7 @@ Optional properties:
> > > - regulator-max-microamp: a maximum allowed Current value
> > > - regulator-always-on: regulator should never be disabled
> > > - regulator-boot-on: enabled by bootloader/firmware
> > > +- regulator-ramp-delay: ramp delay for regulator (in uV/us)
> >
> > I guess you mean s/V, not V/s; at least the code suggests so.
>
> uV/uS. It is correct in the code:
> int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
> delay = (uV - uV) / (uV / uS) = uS
You're right. _divide_ by that value; somhow this has escaped me.
Sorry for the noise.
nit: "s" is for seconds, "S" is for conductance.
> > But my main point is: is the required delay always a linear
> > function of the voltage jump? Depending on the dampening and
> > load on the rail this could be an overshoot and settle, no?
> >
> > So I suggest to make that an array with 2 elements: a fixed part
> > and a time per voltage change. Does that make sense?
>
> Just to make it clear - then we do not follow Linux kernel DT bindings.
> The voltage change might have exponential characteristic and/or have
> additional fixed delay time (see patch 7 here). We could re-use some
> properties from Linux bindings for that purpose:
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L19
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L24
I see. But then "static void regulator_set_value_delay(...)" should either
at least have a "ramp" somewhere in its name or it should discover the device
properties on its own, in order to be able to handle regulator-settling-time*
and regulator-enable-ramp-delay as well in the future. (i.e. pass it uc_pdata
instead of uc_pdata->ramp_delay and also let it handle the condition).
Torsten
next prev parent reply other threads:[~2019-02-18 15:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-16 9:45 [U-Boot] [PATCH v3 0/9] arm: exynos: Fix reboot on Odroid HC1 Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 1/9] adc: exynos-adc: Fix wrong bit operation used to stop the ADC Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 2/9] power: regulator: s2mps11: Fix step for LDO27 and LDO35 Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 3/9] arm: exynos: Detect revision later, when all resources are ready Krzysztof Kozlowski
2019-02-17 22:34 ` Lukasz Majewski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 4/9] arm: exynos: odroid-xu3: Display info late to have proper type Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 5/9] arm: exynos: Wait till ADC stabilizes before checking Odroid HC1 revision Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 6/9] regulator: Add support for ramp delay Krzysztof Kozlowski
2019-02-18 14:03 ` Torsten Duwe
2019-02-18 14:28 ` Krzysztof Kozlowski
2019-02-18 15:26 ` Torsten Duwe [this message]
2019-02-19 12:14 ` Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 7/9] power: regulator: s2mps11: Add enable delay Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 8/9] arm: dts: exynos: Add supply for ADC block to Odroid XU3 family Krzysztof Kozlowski
2019-02-16 9:45 ` [U-Boot] [PATCH v3 9/9] arm: dts: exynos: Add ramp delay property to LDO regulators " Krzysztof Kozlowski
2019-02-24 12:55 ` [U-Boot] [PATCH v3 0/9] arm: exynos: Fix reboot on Odroid HC1 Anand Moon
2019-03-05 10:16 ` Minkyu Kang
2019-03-05 19:54 ` Krzysztof Kozlowski
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=20190218152657.GC6623@lst.de \
--to=duwe@lst.de \
--cc=u-boot@lists.denx.de \
/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