Andy Green andy at openmoko.com
Wed Aug 20 13:16:59 CEST 2008

Hash: SHA1

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
until later.

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.

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


More information about the hardware mailing list