From: Aleksandr Frid <afrid@nvidia.com>
To: Doug Anderson <dianders@chromium.org>,
Laxman Dewangan <ldewangan@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Lee Jones <lee.jones@linaro.org>,
Brian Norris <briannorris@chromium.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Heiko Stuebner <heiko@sntech.de>,
Thierry Reding <thierry.reding@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] regulator: pwm: Fix regulator ramp delay for continuous mode
Date: Thu, 7 Jul 2016 18:23:22 +0000 [thread overview]
Message-ID: <47095a54f7b44f8a98bdfe05cdea7865@HQMAIL106.nvidia.com> (raw)
In-Reply-To: <CAD=FV=UQw7ttMECtO0aomx56G6xGWZh96NRug6Y4QuPJfXq8Tw@mail.gmail.com>
Hi,
>>
In that case we should probably add a new PWM regulator property and not abuse the existing one. Maybe you use "pwm-regulator-settle-us"
or something?
>>
Looks reasonable to me.
>>
actually the right thing is probably to implement 'regulator-ramp-delay' as doing several small steps in that case
>>
Ramp delay uV/us is not a "real" metric for some PWM regulators with exponential transition -- as opposite to fixed slew-rate linear transition on other regulators. So splitting transition into multiple steps to implement artificial (in this case) metric seems questionable.
-----Original Message-----
From: dianders@google.com [mailto:dianders@google.com] On Behalf Of Doug Anderson
Sent: Thursday, July 07, 2016 9:31 AM
To: Laxman Dewangan
Cc: Mark Brown; Boris Brezillon; Lee Jones; Brian Norris; open list:ARM/Rockchip SoC...; Heiko Stuebner; Thierry Reding; Liam Girdwood; linux-kernel@vger.kernel.org; Aleksandr Frid
Subject: Re: [PATCH v2] regulator: pwm: Fix regulator ramp delay for continuous mode
Hi,
On Thu, Jul 7, 2016 at 1:36 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
> On Thursday 07 July 2016 12:12 AM, Douglas Anderson 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).
>>
>> 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%.
>>
>> NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
>> That could be done in a future patch when someone has a user of that
>> featre.
>>
>> Though this patch is shows as "fixing" a bug, there are no actual
>> known users of continuous mode PWM regulator w/ ramp delay in
>> mainline and so this likely won't have any effect on anyone unless
>> they are working out-of-tree with private patches. For anyone in
>> this state, it is highly encouraged to also pick Boris Brezillon's
>> WIP patches to get yourself a reliable and glitch-free regulator.
>>
>> Fixes: 4773be185a0f ("regulator: pwm-regulator: Add support for
>> continuous-voltage")
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
>
>
> Looks fine here.
> Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
>
> BTW, for some PWM regulator, the settling time for voltage change is
> same for any steps.
In that case we should probably add a new PWM regulator property and not abuse the existing one. Maybe you use "pwm-regulator-settle-us"
or something? ...and actually the right thing is probably to implement 'regulator-ramp-delay' as doing several small steps in that case. So if you've got:
* settle time: 10 us
* ramp delay = 5000 uV / us
* voltage change of 200000 uV
In that case you'd probably want to break your 200 mV voltage change into a few steps? So you could do bump by 50mV, delay 10us, bump by 50mV, delay 10us, bump by 50mV, delay by 10us.
The final delay would be the same as with my patch applied but you'd get there more smoothly.
-Doug
next prev parent reply other threads:[~2016-07-07 18:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 18:42 Douglas Anderson
2016-07-07 8:36 ` Laxman Dewangan
2016-07-07 16:30 ` Doug Anderson
2016-07-07 18:23 ` Aleksandr Frid [this message]
2016-07-07 18:31 ` Doug Anderson
2016-07-07 18:43 ` Aleksandr Frid
2016-07-08 8:53 ` Mark Brown
2016-07-07 10:01 ` Applied "regulator: pwm: Fix regulator ramp delay for continuous mode" to the regulator tree Mark Brown
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=47095a54f7b44f8a98bdfe05cdea7865@HQMAIL106.nvidia.com \
--to=afrid@nvidia.com \
--cc=boris.brezillon@free-electrons.com \
--cc=briannorris@chromium.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=ldewangan@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=thierry.reding@gmail.com \
/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
Powered by JetHome