-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Andy, | | This is great work. I have the following observations... | | Pros: | display looks so nice now on resume. No flash at all, no degradation | over time while suspended.
Oho excellent. | Resume speed seems much better as well. | I think I had some sort of invalid wakeup before. I thought it was | because of the GSM but now I am uncertain. I no longer get the | mysterious resumes. | | Cons: | audio pop is still there for me. I don't know if you committed changes No I just started seeing if I could reproduce it late last night. Happily Joerg saved me from meddling in probably the wrong area in the meanwhile. | that should affect it. When I do fully resume and write to the device it | hangs. Perhaps they are both related to something with DMA? I get around | the hang in the application layer by using a timeout, close, reopen. | That brings audio back to life. Ah Hum. This is likely something to do with the recent locking / power mode stuff that allows the audio resume to get parallelized out of the resume critical path. Mark added it (which I am glad of because I don't know any of that Alsa stuff). I have tested it (and just tested it again) with no handles up on alsa in suspend and it is fine. I didn't test the case that we have it in use at the time. It sounds like previously this would work OK for you? | Also, still getting hangs where it will not resume. The only thing I can | do at this point is to ping the device over usb. I have root mounted | over usb, by the way, but I don't think that is the issue. Well I think we come down to a real difference it config or something else now that makes a race I can never see. I just did: ~ while [ 1 ] ; do sleep 1s ; echo mem >/sys/power/state ; done for 100 resumes straight, zero problems. (Even the low probability "juddery resume display" error didn't come, we can hope the last Glamo changes got rid of that too.) If the Ethernet over USB up, has its IP and can do ICMP, we are not in any global panic, it smells like a deadlock involving one of the resume callbacks, so it can't advance through all the resumes. Another way we saw before to make this kind of issue is to yield / sleep in resume function when timer is not up yet for scheduler. If I could reproduce it, I would attack this by moving "light an LED" code around the resume functions binary chop style, using the dmesg list of resume ordering as a guide. It's not much fun but it will identify where we are sticking. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhWHlUACgkQOjLpvpq7dMou5QCgkA67V+ZRgIBPasMBP7bDGXZx 5fkAn1WMv43wVT7idAp/P07q6iQldji1 =pOmo -----END PGP SIGNATURE-----
