-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On 8/20/08, Werner Almesberger <[EMAIL PROTECTED]> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkir/SsACgkQOjLpvpq7dMqeOQCePJ2PWx8or18aF9t+VtOIGDde 9g8An030MqieQL05TBau1AhCcn1AcoJR =t3cQ -----END PGP SIGNATURE----- _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
