Suspend mode measuring

Andy Green andy at
Thu Feb 7 21:03:01 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> 2) I looked at other SDIO designs and they do not pull up the SD / SDIO
>> clock line.  Can make R7909 NC?
> Having a pull-up on the clock definitely sounds like a bug, yes.
>> 3) R1710 / R1741 is a bit of a strange pair.  R1741 should be NC?  Or is
>> there a bigger story there?
> I think the story goes like this: ultimately, we would have liked to
> have a (very weak) pull-down there, so that we can use KEEPACT to
> signal that the CPU have come out of reset and is in charge.
> R1710 is only there to make KEEPACT work until we've implemented and
> tested the software side of it.
> However, if we're going to drop that functionality anyway, we should
> remove R1741 and probably also make R1710 a bit larger. KEEPACT leaks
> up to 1uA, so 100kOhm for R1710 would be perfect.

Hi Werner -

Don't forget the leakage on the CPU pin side of the KEEPACT net
additionally... maybe the max pull up or down should be 33K here.

Maybe we should add KEEPACT driving high in U-Boot, if it can act within
100ms of getting power.  We're talking about the guy pressing the power
button, it failed to boot somehow and it just loses power right away.
Thinking about it that's pretty good because his retry mechanism is
simply pressing the power button again (or aux to retry in NOR) right
away, it's real clear and predictable.  The way it is, if we failed to
come up for whatever reason it's crashed and he has to remove the
battery to get a retry.

Of course this is an unusual scenario, the thing powers up 100% reliably
here now the VB_SYS decoupling is resolved.

Nah why don't we just do R1741 -> NC and R1710 -> 33K, we're not
fighting a real problem here.  It's still open for us to put the PMU in
heartbeat mode for KEEPACT in the Linux driver later and require toggles
on KEEPACT at >2Hz do have a "power watchdog".

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list