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