From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Liam Girdwood <lrg@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: boot_on regulator constraint vs. regulator-boot-on DT property
Date: Thu, 21 Jun 2012 00:46:48 +0100 [thread overview]
Message-ID: <20120620234648.GE4037@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FE238C9.3010408@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Wed, Jun 20, 2012 at 02:55:37PM -0600, Stephen Warren wrote:
> include/linux/regulator/machine.h says:
> > * @boot_on: Set if the regulator is enabled when the system is initially
> > * started. If the regulator is not enabled by the hardware or
> > * bootloader then it will be enabled when the constraints are
> > * applied.
> Documentation/devicetree/bindings/regulator/regulator.txt says:
> > - regulator-boot-on: bootloader/firmware enabled regulator
> ... and of_regulator.c sets the boot_on constraint based on this property.
> The former quote implies that this is a flag to tell Linux to turn on
> the regulator when it's first registered, whereas the latter quote
> implies that it's guaranteeing the state that previous SW placed the
> regulator into already.
> I assume the documentation from machine.h is correct, and I should send
> a patch to make regulator.txt match it?
There's no great inconsistency between the two, this is only supposed to
be used for supplies which are already enabled on boot but if the supply
is not already enabled then currently the API will try to make it so
since probably there's some reason for that. Generally it's supposed to
be used as a crutch to keep hotplug going.
I'm not sure we should clarify this since I'm not sure that for DT
setups which (as we were discussing in the other thread) are supposed to
be usable over many software versions it's something that should really
be used. We ought to in the endgame be able to have DT systems turn on
full constraints and that probably breaks anything relying too much on
boot-on, I'd expect they either need the regulator to be always on or
some more consumers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-20 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 20:55 boot_on regulator constraint vs. regulator-boot-on DT property Stephen Warren
2012-06-20 23:46 ` Mark Brown [this message]
2012-06-21 1:26 ` Stephen Warren
2012-06-21 9:12 ` 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=20120620234648.GE4037@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--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