-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| Now, when skipping the reset, I get this: | http://people.openmoko.org/werner/suspend-noreset.png | | The first suspend is very fast now, confirming that WLAN was the | principal element slowing everything down. But all subsequent | suspends are as slow as they've ever been. OK. | This suggests that there's something in the suspend path that | creates a fairly large delay on suspend (> 3s) and that only | comes alive after a resume. | | Since you've been poking around suspend/resume quite a bit, does | this ring any bells ? The only monster delay I knew about was the WLAN one, but there are delays floating about in jbt6k74 stuff that can be suspicious. Also although Balaji took it out AFAIK, i2c is slow and if we sat there pulling registers in pcf50633 it would do it. We don't do much in Glamo suspend AFAIK. Could it be something like a sync or jffs2 action? To get a clue where it starts, maybe the timed dmesg stuff that prints on resume can help? There's some mix of config that gets it to call out each driver as it suspends and resumes them, with the timestamp it can give the right idea. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkl0a1kACgkQOjLpvpq7dMok1QCdGTn55J4kins9mdXaBeuHLB6d qSMAnieD5z3wjrIe9npYB/H13SN3qAGd =iaYq -----END PGP SIGNATURE-----
