devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

      reply	other threads:[~2013-09-12 10:12 UTC|newest]

Thread overview: 7+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).