resume/suspend observations

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

> A few more resume/suspend observations from my experiments:

I think the work on this I did last week is only explained on my
whiteboard so far.  Currently there are a range of exciting weirdnesses
that happen for me on resume, including breakage of I2C very similar to
that reported by Mickey Lauer here back in October

http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=79

> - with kernel and defconfig from SVN, plus the workqueue fix below,
>   none of the I2C issues or long delays happen

The story here is that because I run the git config with extra
diagnostic configurations, I found a BUG() on resume that is missed by
the stock config (it also found serious locking problems in the WLAN
that Sameo fixed, it's really good to have around).  It is quite
interesting because the BUG() happens is in the code that starts the
"tick" timer again so we have a process heartbeat, it wants to use the
clk class stuff but it uses mutexes in resume's atomic context and blows
the BUG().  I asked Werner's advice on whether a workqueue to defer the
tick timer init would actually work here given the lack of tick() and we
decided to give it a go, so I wrote a patch to add the workqueue (it
seems to work) some days ago and gave it to Werner earlier.

> - trying to resume with AUX causes the u-boot in NOR to start without
>   doing the resume. Instead, u-boot comes up but power seems to be
>   very unstable (the display content quivers horizontally), and the
>   system crashes and powers down within seconds.

NOR is the one thing we can't update :-)  Make sure you retry without a
battery in if you had one in.

> - inserting/removing the headset allows us to resume immediately

Great.

> - pressing the HOLD button (on the headset) has no effect at all.
>   Apparently, this is a solved issue. Needs checking.

Well, if it is broken I guess resume from Hold button is not a critical
feature... does it have a scenario where it is useful?

> - when pressing the POWER button, the system resumes after about
>   5-6 seconds
> 
> - if we suspend after having resumed with a PMU event (i.e., POWER
>   or an RTC alarm), no other PMU event will bring us out of suspend

Hm.

> - after resume, the display stays white. Restarting Xglamo makes no
>   difference.

Matt is on that one.

> Using Andy's .config (and the SVN tree), my system still behaves most
> of the time. In particular, there is no I2C timeout. However, a few
> anomalies creep up:

The main difference between the git config and the stock one is that I
moved most key drivers into the monolithic kernel.

> - every once in a while, the kernel hangs right after initializing the
>   Glamo, about 2s into the kernel start (this is not related to suspend)

Hm.

> - after resume, the kernel every once in a while hangs in
>   "Restarting tasks ..."

Curiouser and curiouser, since it is just my "=Y" config on your same
tree.  That would make one think of a race we didn't take care of.

I think we need a bit more of an explanation than blaming the (valid)
config for these behaviours when it must be coming out of the code.
Tomorrow I guess my first move is to reconfirm that nothing in my git
patchset makes the I2C problem directly.

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

iD8DBQFHwXUkOjLpvpq7dMoRAh6VAJ4s2DL8NYuCTXglVdpr4IcJ69THuQCdEsfE
W/oQ0aFZoFTfh9Jj3lCxSEU=
=CfbS
-----END PGP SIGNATURE-----