linux-kernel - Re: [PATCH v2] pwm-regulator: Add support for a fixed delay after duty cycle changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2016 19:57:38 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Javier Martinez Canillas <javier@...hile0.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] pwm-regulator: Add support for a fixed delay after
 duty cycle changes

Hi,

On Fri, Aug 26, 2016 at 5:20 PM, Matthias Kaehlcke <mka@...omium.org> wrote:
> A change of the duty cycle doesn't necessarily cause an inmediate switch
> to the target voltage. The voltage change may be gradual and complete
> with a certain delay. This change introduces the device tree properties
> "settle-time-up-us" and "settle-time-down-us", which allow to specify a
> fixed delay after a voltage increase or decrease. Often it is not
> strictly necessary for a voltage decrease to complete, therefore the
> delays may be asymmetric. For regulators with a ramp delay the
> corresponding settle time is added to the ramp delay.
>
> Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> ---
>  .../bindings/regulator/pwm-regulator.txt           | 10 +++++++++
>  drivers/regulator/pwm-regulator.c                  | 25 ++++++++++++++++++----
>  2 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> index 3aeba9f..42b6819 100644
> --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> @@ -29,6 +29,16 @@ Required properties:
>
>  - pwms:                        PWM specification (See: ../pwm/pwm.txt)
>
> +Optional properties:
> +--------------------
> +- settle-time-up-us:   Time to settle down after a voltage increase
> +                       (unit: us). For regulators with a ramp delay
> +                       the two values are added.
> +
> +- settle-time-down-us: Time to settle down after a voltage decrease
> +                       (unit: us). For regulators with a ramp delay
> +                       the two values are added.

Based on investigations that we've been doing recently, it might make
sense to leave "settle-time-down-us" out of this patch for now.  From
how our EEs appear to have designed our hardware:

* There's no "ramp up" time that's in terms of uV / uS, just a
"settle-time-up-us" like you have here.

* For going down there's not really a settle time or a ramp down time.
The regulator will just fall at a rate that depends on the current
load.  ...and it's kinda slow / not worth it to block waiting for the
regulator to go down.

* We may want to introduce some other properties related to the
downward ramp to keep the regulator from falling too fast.  On our
board if you drop down too fast you can trigger the PWM regulator over
voltage protection, so on downward ramps we might have to break into
additional steps.


To say it another way:

- settle-time-up-us looks great.

- settle-time-down-us isn't useful on our board and it's probably
better to wait until there's a user before adding this property.

- future properties will come to help break the downward transition
into multiple steps.


Does that sound sane?

-Doug