Device probe order (i2c regulator vs. platform device)
Mark Brown
broonie at opensource.wolfsonmicro.com
Wed Mar 24 07:32:41 EDT 2010
On Wed, Mar 24, 2010 at 09:19:58AM +0000, Andy Green wrote:
> Delaying registering devices is only half the problem. You must
> also correct these device's parent dev to be the PMU's.
> Otherwise your suspend and resume ordering turns to crap and you
> will immediately be in Hell, for example the PMIC may go down taking
> away power from the SD Card before you finished talking to it.
This has not been a practical issue in systems - it is very rare to
explicitly suspend the regulator part of the PMIC. Obviously the PMIC
suspend will usually involve killing the power to the processor so it is
almost always triggered from hardware as part of the processor poweroff
after software has halted.
It'd be nice to explicitly save and restore the regulator state over
suspend and resume for devices that don't support that natively but
that's mostly orthogonal and mostly just flops out of devices doing
their own management at suspend and resume anyway.
> It would be very good is this was regularized somehow into a
> standard API because it's absolutely a requirement for many boards
> that their devices ARE dependent on PMU as a parent.
The only system I'm aware of which had any stuff like this was the
GTA02. I never investigated to figure out why the code there was doing
what it was.
More information about the linux-arm-kernel
mailing list