andy at openmoko.com
Wed Aug 20 13:16:59 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| On 8/20/08, Werner Almesberger <werner at openmoko.org> wrote:
|> That's why try to control as many signals to subsystems that are
|> active in PMU.STANDBY as possible from PMU GPIOs. And yes, it would
|> be great to have more GPIOs that are guaraneteed to have a defined
|> state in PMU.STANDBY for things like MODEM_RST and MODEM_ON as well.
| You need stringent sequencing for IOs and Powerswitching.
| And that must sit hierarchically above any other driver code.
We have no control over PMU startup. It brings up various rails how it
likes all at the same time at levels it likes.
Problems with startup at low battery (I guess the foot-tangling you
mean) are caused by inrush current limiting also being set too high by
PMU itself and again out of our control because the CPU does not come up
These are some of the reasons we would like an always-on MPU to manage
PMU startup in a way we control from the start.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the hardware