From: Mark Brown <broonie@sirena.org.uk>
To: David Brownell <david-b@pacbell.net>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2.6.28-rc3] regulator: add REGULATOR_MODE_OFF
Date: Thu, 15 Jan 2009 12:29:38 +0000 [thread overview]
Message-ID: <20090115122937.GC2147@sirena.org.uk> (raw)
In-Reply-To: <200901142303.09217.david-b@pacbell.net>
")
Fcc: +sent-mail
On Wed, Jan 14, 2009 at 11:03:09PM -0800, David Brownell wrote:
> introspection. Example: troubleshooting, as we previously
> discussed; or, I can see some regulators that are wrongly
> enabled, primarily because of bootloader goofage.
> That raises an issue: how can Linux get such regulators to
> turn off? Clock frameworks have the same issue, and they
> tend to resolve this with a SoC-specific Kconfig option to
> disable unused clocks (in a late_initcall, after everthing
> has had a chance to start up). That conserves power.
That's something that should be done by constraints - add a new flag
that can be set.
> I'm thinking it'd be worth having a similar Kconfig option
> for regulators too. It could kick in regulator core code to
> call regulator_ops.disable() whenever regulator_dev.use_count
> is zero, possibly warning if !regulator_ops.is_disabled().
> (Handling constraints.always_on too.)
> Comments?
Given the model the API has of not doing anything unless explicitly
told to I'd not expect to see this as a Kconfig option but rather as
something enabled per regulator or at least per board.
The warning would be a bit interesting; ideally there should be one
since it's probably an indication that something is wrong but there
are probably going to be use cases for it that can't be covered by
always_on, not that I can think of any right now.
next prev parent reply other threads:[~2009-01-15 12:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-09 23:31 [patch 2.6.28-rc3] regulator: add REGULATOR_MODE_OFF David Brownell
2008-11-10 13:14 ` Liam Girdwood
2008-11-10 15:43 ` David Brownell
2008-11-10 16:56 ` Mark Brown
2008-11-11 4:56 ` David Brownell
2008-11-12 11:25 ` Mark Brown
2008-11-12 21:42 ` David Brownell
2008-11-12 23:09 ` Mark Brown
2008-11-12 22:23 ` Liam Girdwood
2008-11-13 0:00 ` David Brownell
2008-11-13 19:40 ` David Brownell
2008-11-13 21:53 ` Mark Brown
2008-11-15 1:15 ` David Brownell
2008-11-15 4:37 ` Mark Brown
2008-11-16 20:28 ` David Brownell
2008-11-16 22:58 ` David Brownell
2008-11-17 1:51 ` Mark Brown
2009-01-15 7:03 ` David Brownell
2009-01-15 12:29 ` Mark Brown [this message]
2009-01-15 22:32 ` David Brownell
2009-01-16 1:08 ` Mark Brown
2009-01-15 7:03 ` [patch 2.6.29-rc] regulator: add get_status() David Brownell
2009-01-15 12:04 ` Liam Girdwood
2009-01-15 12:40 ` Mark Brown
2009-01-15 12:50 ` Liam Girdwood
2009-01-15 15:35 ` David Brownell
2009-01-15 16:05 ` Mark Brown
2009-01-15 16:54 ` David Brownell
2009-01-15 18:11 ` David Brownell
2009-01-15 18:24 ` 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=20090115122937.GC2147@sirena.org.uk \
--to=broonie@sirena.org.uk \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
/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