linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	OMAP <linux-omap@vger.kernel.org>
Subject: Re: [patch 2.6.29-rc8 regulator-next] regulator: init fixes (v4)
Date: Tue, 17 Mar 2009 20:08:32 +0000	[thread overview]
Message-ID: <20090317200828.GA7060@sirena.org.uk> (raw)
In-Reply-To: <200903171115.06685.david-b@pacbell.net>

On Tue, Mar 17, 2009 at 11:15:06AM -0700, David Brownell wrote:
> On Monday 16 March 2009, Mark Brown wrote:

> > Devices that need to do things like set voltages are fairly likely to
> > own the regulator but with devices that just need to ensure that they
> > have their supplies enabled it's much more likely that the supplies will
> > be shared.

> Right.  Do you have a model how such shared supplies would
> coexist with the "enabled at boot time" model, and still
> support being disabled?

The drivers can essentially ignore the physical status of the regulator
when they start, enabling when they need them and disabling when they're
done.  So long as at least one device has the regulator enabled the
regulator will remain on but when the reference count drops to zero then
the regulator will be disabled.

This works well when the driver will be enabling the regulators at
startup and then disabling them later on.  It will also work well with a
late_initcall which disables any unreferenced regulators - that should
become the default at some future point (2.6.31 might be a good candiate
here, I posted a patch the other day providing an implementation which
warns if there are affected regulators and which machines can activate
if they want).

> My first thought is that the system designer should avoid
> such boot_on modes.  But that's not always going to work.

Yes, that's not something that can realistically be achieved in the
general case.  Machines should probably avoid it but often people want
to do things like bring LCDs up in the bootloader and providing graceful
handover to the actual driver helps the user experience.

  reply	other threads:[~2009-03-17 20:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12  0:43 [patch 2.6.29-rc7 regulator-next] regulator: refcount fixes David Brownell
2009-03-12  2:32 ` [patch 2.6.29-rc7 regulator-next] regulator: init fixes David Brownell
2009-03-12 12:01   ` Mark Brown
2009-03-15  0:25     ` [patch 2.6.29-rc8 regulator-next] regulator: init fixes (v4) David Brownell
2009-03-15  0:37       ` Mark Brown
2009-03-15  4:05         ` David Brownell
2009-03-16 21:54           ` Mark Brown
2009-03-17 18:15             ` David Brownell
2009-03-17 20:08               ` Mark Brown [this message]
2009-03-18 19:25                 ` David Brownell
2009-03-18 20:33                   ` Mark Brown
2009-03-18 21:02                     ` David Brownell
2009-03-19 19:27                       ` Mark Brown
2009-03-18 21:14                     ` David Brownell
2009-03-19 16:59                       ` Mark Brown
2009-03-15  4:16     ` [patch 2.6.29-rc7 regulator-next] regulator: init fixes David Brownell
2009-03-12 10:37 ` [patch 2.6.29-rc7 regulator-next] regulator: refcount fixes Mark Brown
2009-03-12 20:35   ` David Brownell
2009-03-12 21:05     ` Mark Brown
2009-03-12 23:02       ` David Brownell
2009-03-13  1:38         ` Mark Brown
2009-03-14 21:29           ` David Brownell
2009-03-15  0:30             ` Mark Brown
2009-03-15  4:27               ` David Brownell
2009-03-12 10:56 ` Liam Girdwood

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=20090317200828.GA7060@sirena.org.uk \
    --to=broonie@sirena.org.uk \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@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;
as well as URLs for NNTP newsgroup(s).