From: Mark Brown <broonie@kernel.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"rob@landley.net" <rob@landley.net>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>
Subject: Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
Date: Thu, 12 Sep 2013 11:12:29 +0100 [thread overview]
Message-ID: <20130912101229.GD29403@sirena.org.uk> (raw)
In-Reply-To: <5230AF94.60007@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
On Wed, Sep 11, 2013 at 11:59:48AM -0600, Stephen Warren wrote:
> On 09/11/2013 12:09 PM, Laxman Dewangan wrote:
> >> I suppose that either is fine from a DT perspective. But, the regulator
> >> drivers already know their internal delay, so presumably driver code
> >> will have to take the value from DT, and subtract out whatever delay the
> >> driver already embodies, in order to calculate the extra delay required?
> >> Or, if this property is set, does the driver-specified delay just get
> >> ignored?
> > Yes, if property is available then driver-specified delay get ignored.
> > Delay will be used from dt provided value.
> I'm not sure whether I prefer one option or the other. Perhaps Mark can
> decide?
The drivers don't implement their own delays, this is already factored
out of them into the framework. It seems simpler from both a user and
implementation point of view for the delay specified in the DT to just
completely override what the drivers know.
> That said, what if the internal ramp rate of the regulator itself is
> configurable, and can change at run-time. Won't that affect the total
> time? If so, having this property represent the additional time might
> better allow the total time to be recalculated based on internal
> regulator ramp delay changes. Perhaps the additional time varies if the
> internal ramp rate varies though, so perhaps it's not worth thinking
> about this situation.
There's very little use case for varying the ramp rate from cold at run
time - it's mostly just used to limit inrush current on initial power
on. I think it's OK to just say that if someone specifies a fixed dleay
and varies the ramp rate then they probably aren't being sensible and
get to keep all the pieces.
> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply
microseconds.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2013-09-12 10:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 12:58 [PATCH V2] regulator: core: add support for configuring turn-on time through constraints Laxman Dewangan
2013-09-11 12:58 ` Laxman Dewangan
2013-09-11 17:17 ` Stephen Warren
2013-09-11 17:46 ` Laxman Dewangan
2013-09-11 17:46 ` Stephen Warren
2013-09-11 18:09 ` Laxman Dewangan
2013-09-11 17:59 ` Stephen Warren
2013-09-12 10:12 ` Mark Brown [this message]
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=20130912101229.GD29403@sirena.org.uk \
--to=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ldewangan@nvidia.com \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=swarren@wwwdotorg.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.