aux button interrupt to pmu?

Andy Green andy at
Fri Jun 6 11:43:41 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
|>> In fact there should be limited trouble it can cause since we jump to a
|>> wake address in a fixed CPU register that survives suspend, if NOR
|>> U-Boot can deal with wake at all it should be safe.  The main thing
|>> that'll be broken is the wake reason, since NOR image AFAIK is too old
|>> to have the patch.
| Yes, I think this will have compatible issue if user don't have debug
| board for re-flash the NOR.

Can be, but we can maybe work around it.  For example we can look in
resume function of "keyboard" that deals with buttons to see if AUX is
still down when it resumes, and infer from this that we woke from AUX,
set the AUX resume reason bit right then.

Carsten mentioned it doesn't wake at the moment, I think it's probably
because it isn't enabled as wake source.  If it does wake through to
Linux OK from AUX -> NOR U-Boot -> Linux then the workaround above will
probably work for even current NOR U-Boot.

| Will want to wake up from AUX in ASU, but I don't think ASU should have
| _NOR regression in as AUX wake up source_ issue.


| We might could use hardware id we to difference the hardware ship with
| ASU, and make suspend resume behavior differently in ASU software/NOR.
| And this should not affect original GTA02 install ASU for update.
| werner might need to help on this item and logic, including the initial
| set aux as wake up source and wake up source check for resume logic.
|> so unless the nor contents are changed... it isnt a fully functional wake
|> source - right? at this stage the spec is much more malleable than the
|> hardware. the aux for wake is new in the last few weeks.
| Yes, might be 3 weeks before in some ASU meeting.

Hardware design is a little bit older than this :-)

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


More information about the openmoko-kernel mailing list