public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@nokia.com>
To: "Jokiniemi Kalle (Nokia-SD/Tampere)" <kalle.jokiniemi@nokia.com>
Cc: "broonie@opensource.wolfsonmicro.com"
	<broonie@opensource.wolfsonmicro.com>,
	"lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>,
	"mchehab@infradead.org" <mchehab@infradead.org>,
	"svarbatov@mm-sol.com" <svarbatov@mm-sol.com>,
	"saaguirre@ti.com" <saaguirre@ti.com>,
	"grosikopulos@mm-sol.com" <grosikopulos@mm-sol.com>,
	"Zutshi Vimarsh (Nokia-SD/Helsinki)" <vimarsh.zutshi@nokia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] Regulator state after regulator_get
Date: Thu, 28 Apr 2011 12:34:05 +0300	[thread overview]
Message-ID: <4DB9348D.7000501@nokia.com> (raw)
In-Reply-To: <9D0D31AA57AAF5499AFDC63D6472631B09C76A@008-AM1MPN1-036.mgdnok.nokia.com>

Hello,

Jokiniemi Kalle (Nokia-SD/Tampere) wrote:
> Hello regulator FW and OMAP3 ISP fellows,
> 
> I'm currently optimizing power management for Nokia N900 MeeGo DE release,
> and found an issue with how regulators are handled at boot.
> 
> The N900 uses VAUX2 regulator in OMAP3430 to power the CSIb IO complex
> that is used by the camera. While implementing regulator FW support to
> handle this regulator in the camera driver I noticed a problem with the
> regulator init sequence:
> 
> 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. 
> 
> I found couple of solutions to this:
> 1. reset all regulators that have users (regulator_get is called on them) with
> a regulator_enable/disable cycle within the regulator FW.
> 2. enable/disable the specific vdds_csib regulator in the omap3isp driver
> to reset this one specific regulator to disabled state.
> 
> So, please share comments on which approach is more appropriate to take?
> Or maybe there is option 3?
> 
> Here are example code for the two options (based on .37 kernel, will update
> on top of appropriate tree once right solution is agreed):
> 
> Option1:
> 
> If a consumer device of a regulator gets a regulator, but
> does not enable/disable it during probe, the regulator may
> be left active from boot, even though it is not needed. If
> it were needed it would be enabled by the consumer device.
> 
> So reset the regulator on first regulator_get call to make
> sure that any regulator that has users is not left active
> needlessly.

I'm not an expert in the regulator framework, but I'd think that one
should be able to assume a regulator is in a sane state after boot. The
fact that the regulator is enabled when it has no users should likely be
fixed in the boot loader. Is that an option?

Does the problem exist in other boards beyond N900?

Another alternative to the first option you proposed could be to add a
flags field to regulator_consumer_supply, and use a flag to recognise
regulators which need to be disabled during initialisation. The flag
could be set by using a new macro e.g. REGULATOR_SUPPLY_NASTY() when
defining the regulator.

Just my 0,05 euros. ;-)

Cc Laurent Pinchart.

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

  reply	other threads:[~2011-04-28  9:34 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 [this message]
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
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=4DB9348D.7000501@nokia.com \
    --to=sakari.ailus@nokia.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=grosikopulos@mm-sol.com \
    --cc=kalle.jokiniemi@nokia.com \
    --cc=laurent.pinchart@ideasonboard.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