Measurements: Massive Display-related power savings

[Andy Green]

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

Somebody in the thread at some point said:
| Klaus Kurzmann ha scritto:
| [snip]
|> I can unblank it fine from deep-standby, if I do it within the first
|> minute after entering deep-standby... Afterwards I get a WSoD. Same with
|> resume - I could resume fine within the first minute after suspend, but
|> not afterwards...
|>
|> Mok
|
| This is the exact behaviour that me and some other friends of mine are
| having. I'm not a kernel dev so i don't know if this idea is mad due to
| a lot of things or it can be done, but, why we can't simply reset glamo
| and lcd controller? I've noticed that when i boot my FR or when i reboot

That's what is done now on stable-tracking, basically seems we can't
trust the Glamo to retain state through suspend, especially given the
hard resets that are seen from the bad reset circuit, so we now reset it
on resume and bring it back up as if from cold "roll with the punch" style.

What stable-tracking has right now is that on resume, after this reset
action video is coming again, MMC is working, everything is cool except
the Glamo GPIO do not move as part of the bitbang SPI to the LCM ASIC so
we still have a WSOD.

But otherwise, the bad resume behaviours from Glamo are gone since the
decision to hard reset it and suspend - resume is apparently OK.

There are only two serious problems left with stable-tracking AFAIK
right now, this Glamo GPIO not working on resume somehow leading to
WSOD, and the NAND / ECC issue; and two smaller problems breakage on
Accel and warnings from WLAN driver about "warn_on_slowpath".

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

iEYEARECAAYFAkkH9+8ACgkQOjLpvpq7dMrcgwCeI0YDdaN+A0Dn+Lhmc/HF31uS
MeUAn0hgVP/U+a5o73ZeeuVOBy+uXeqk
=tlFi
-----END PGP SIGNATURE-----