public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: kalle.jokiniemi@nokia.com
Cc: lrg@slimlogic.co.uk, mchehab@infradead.org, svarbatov@mm-sol.com,
	saaguirre@ti.com, grosikopulos@mm-sol.com,
	vimarsh.zutshi@nokia.com, Sakari.Ailus@nokia.com,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [RFC] Regulator state after regulator_get
Date: Thu, 28 Apr 2011 11:06:29 +0100	[thread overview]
Message-ID: <20110428100629.GA14494@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <9D0D31AA57AAF5499AFDC63D6472631B09C76A@008-AM1MPN1-036.mgdnok.nokia.com>

On Thu, Apr 28, 2011 at 09:01:03AM +0000, kalle.jokiniemi@nokia.com wrote:

> If the device driver using the regulator does not enable and disable the
> regulator after regulator_get, the regulator is left in the state that it was
> after bootloader. In case of N900 this is a problem as the regulator is left
> on to leak current. Of course there is the option to let regulator FW disable
> all unused regulators, but this will break the N900 functionality, as the
> regulator handling is not in place for many drivers. 

You should use regulator_full_constraints() if your board has a fully
described set of regulators.  This will cause the framework to power
down any regulators which aren't in use after init has completed.  If
you have some regulators with no consumers or missing consumers you need
to mark them as always_on in their constraints.

> So reset the regulator on first regulator_get call to make
> sure that any regulator that has users is not left active
> needlessly.

This would cause lots of breakage, it would mean that all regulators
that aren't always_on would get bounced off at least once during startup
- that's not going to be great for things like the backlight.

  parent reply	other threads:[~2011-04-28 10:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28  9:01 [RFC] Regulator state after regulator_get kalle.jokiniemi
2011-04-28  9:34 ` Sakari Ailus
2011-04-28  9:44   ` kalle.jokiniemi
2011-04-28 10:20     ` Mark Brown
2011-04-28 10:27       ` Sakari Ailus
2011-04-28 10:40         ` Mark Brown
2011-04-28 11:07           ` Sakari Ailus
2011-04-28 10:06 ` Mark Brown [this message]
2011-04-28 11:08   ` kalle.jokiniemi
2011-04-28 11:14     ` Mark Brown
2011-04-28 11:58       ` kalle.jokiniemi

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=20110428100629.GA14494@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=Sakari.Ailus@nokia.com \
    --cc=grosikopulos@mm-sol.com \
    --cc=kalle.jokiniemi@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=mchehab@infradead.org \
    --cc=saaguirre@ti.com \
    --cc=svarbatov@mm-sol.com \
    --cc=vimarsh.zutshi@nokia.com \
    /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