[UPSTREAM] Use new regulator API for pcf50633
balajirrao at openmoko.org
Tue Oct 28 15:07:53 CET 2008
On Tue, Oct 28, 2008 at 01:24:40PM +0000, Mark Brown wrote:
> On Tue, Oct 28, 2008 at 06:30:22PM +0530, Balaji Rao wrote:
> > The changed regulator API requires that we create a platform device for
> > every regulator. This causes some races with devices initialization. The
> > attach_child_devices callback can be called only after all regulators
> > have been registred with the core.
> The way this is dealth with in the Wolfson PMICs is to have a callback
> in the platform data for the PMIC which is invoked at an appropriate
> point in device setup. The Wolfson devices need to offer an opportunity
> for the platform to do things like configure multi-function pins on the
> device so this is needed anyway.
We already have such a callback in the platform data which is invoked
when the probe method of the i2c driver completes.
The probe method creates the platform devices for the regulators. My
question is, can we be 100% sure that when the
platform_device_register returns, the regulators have been registered ?
Though it happens mostly, I thought that somehow we couldn't guarantee that
every single time. If we can, then we have no problem at all.
> > I've not touched the suspend/resume part. Suspending regulators is
> > done through the regulator_prepare_suspend function, which can be called
> > from pcf50633_suspend ? But how do we get the regulators back to active
> > state on resume ?
> At the minute drivers handle this through a combination of the client
> drivers disabling and enabling their regulators as they suspend and
> resume and the hardware having explicit support for using a different
> configuration while suspended (the regulator API has support for
> configuring that through the machine suspend mode settings).
> What exactly needs doing to restore the hardware state here?
> That said, I can't see any reason why there shouldn't be a matching call
> for use in early resume.
> I'd expect these to be called from the platform code rather than the
> pcf50633 driver - it'll affect all regulators in the system, not just
> those in the pcf50633. If it's the pcf50633 it should just be able to
> talk to its own regulator drivers directly.
OK. I got it. Thanks.
More information about the openmoko-kernel