Path: csiph.com!news.freedyn.net!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod
From: Brian Norris <briannorris@chromium.org>
Newsgroups: linux.kernel
Subject: Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode
Date: Tue, 28 Jun 2016 18:10:01 +0200
Message-ID: <rP3Kh-Rj-9@gated-at.bofh.it>
References: <rOThT-25m-15@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 64
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1433086

On Mon, Jun 27, 2016 at 9:53 PM, Douglas Anderson <dianders@chromium.org> wrote:
> The original commit adding support for continuous voltage mode didn't
> handle the regulator ramp delay properly.  It treated the delay as a
> fixed delay in uS despite the property being defined as uV / uS.  Let's
> adjust it.  Luckily there appear to be no users of this ramp delay for
> PWM regulators (as per grepping through device trees in linuxnext).

My grepping agrees, though I'm sure I didn't do a very thorough job.

> Note also that the upper bound of usleep_range probably shouldn't be a
> full 1 ms longer than the lower bound since I've seen plenty of hardware
> with a ramp rate of ~5000 uS / uV and for small jumps the total delays
> are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
> and use 10%
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Note that this patch is atop Boris's recent PWM regulator fixes.  If
> desired it wouldn't be too hard to write it atop the old code, though
> quite honestly anyone using a PWM regulator should probably be using his
> new code.
>
>  drivers/regulator/pwm-regulator.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
> index fa1c74c77bb0..de94d19f6e1f 100644
> --- a/drivers/regulator/pwm-regulator.c
> +++ b/drivers/regulator/pwm-regulator.c
> @@ -188,6 +188,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
>         struct pwm_state pstate;
>         unsigned int diff_duty;
>         unsigned int dutycycle;
> +       int old_uV = pwm_regulator_get_voltage(rdev);
>         int ret;
>
>         pwm_init_state(drvdata->pwm, &pstate);
> @@ -219,8 +220,12 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
>                 return ret;
>         }
>
> -       /* Delay required by PWM regulator to settle to the new voltage */
> -       usleep_range(ramp_delay, ramp_delay + 1000);

I was curious about the side effects of the unconditional
usleep_range(ramp_delay, ...), even when ramp_delay is 0 (e.g., would
we ever sleep here for up to 1ms?), but apparently the implementation
optimizes the '0' case to be an unconditional, immediate wake-up. So
refactoring this shouldn't have any accidental effects.

> +       if (ramp_delay == 0)
> +               return 0;
> +
> +       /* Ramp delay is in uV/uS. Adjust to uS and delay */
> +       ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
> +       usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));

Math checks out to me.

>
>         return 0;
>  }

Reviewed-by: Brian Norris <briannorris@chromium.org>