u-boot low-battery handling

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> Reality is we have to engage with this at pcf50633 kernel driver for
|> GTA03,
|
| Or maybe even user space: bring up user space really quickly, fire
| up the power policy daemon, then let it figure out what to do next.
| Power-wise, it shouldn't really matter whether we're running kernel
| code or user-space, and if there are no secret handshakes between
| USB and the PMU, that's just a few race conditions or deadlocks who
| will not come to haunt us later.
|
|> For example we may need the spinning action in U-Boot in pcf50633 for
|> GTA03 under 100mA / PC USB power circumstance, since at some point Linux
|> would otherwise bring up GSM.
|
| GSM, maybe some blinkenlights, ... sounds like a great task for user
| space :-)

Critical startup power management sequencing is not actually driven by
events in userspace but by kernel -- pcf50633 driver init and USB
enumeration that is completely decoupled from userspace.

For something as critical as recovering from dead battery and low level
charger management, I don't think we want to introduce dependencies on
that most delicate of things, having a working userspace.  Not only
working but having to run specialized stuff for the phone.  Userspace
can start up what it likes when we determined at earliest and most
robust opportunity in kernel it's OK, and "policy" for power up and
charging on PC USB is a fixed thing that fits in kernel.

And if you look where we are headed with it, it is away from the CPU at
all for this low level power management action.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkizkF8ACgkQOjLpvpq7dMo6OgCfe51cFl3mdR6h/N9iw3tWsEQ/
aLEAoJHiRfk8ahhjV9rdEYbCsdOT0IDe
=NiY0
-----END PGP SIGNATURE-----