-----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-----
