RE: [RFC] Regulator state after regulator_get

[kalle.jokiniemi]

Hi,

 > -----Original Message-----
 > From: Sakari Ailus [mailto:sakari.ailus@xxxxxxxxx]
 > Sent: 28. huhtikuuta 2011 12:34
 > To: Jokiniemi Kalle (Nokia-SD/Tampere)
 > Cc: broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx; lrg@xxxxxxxxxxxxxxx;
 > mchehab@xxxxxxxxxxxxx; svarbatov@xxxxxxxxxx; saaguirre@xxxxxx;
 > grosikopulos@xxxxxxxxxx; Zutshi Vimarsh (Nokia-SD/Helsinki); linux-
 > kernel@xxxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx; Laurent Pinchart
 > Subject: Re: [RFC] Regulator state after regulator_get
 > 
 > 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?

Not an option, the device has shipped and there will be no updates to
the bootloader.

 > 
 > Does the problem exist in other boards beyond N900?

Don't know, I currently have only N900 to test with.

 > 
 > 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.

This sounds like a good option actually. Liam, Mark, any opinions?

- Kalle

 > 
 > Just my 0,05 euros. ;-)
 > 
 > Cc Laurent Pinchart.
 > 
 > Regards,
 > 
 > --
 > Sakari Ailus
 > sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/