Andy Green wrote:
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?
Sorry I didn't clarify, but this has been the case for quite a while now
(audio hang on resume). I only mentioned the problem now as it occurred
to me that they might be related somehow. I could see a pop happening if
the dma is resumed improperly and it also being responsible for the
hang. Looks like the culprit on the hang has already been identified,
though.
| 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.)
Are you looking at only button pushes as the resume reason? I get the
hang when I do not do a resume for an extended period of time. Seems
like everything is OK if I keep manually resuming. If I leave alone I
see the unit waking up on occasion because of GSM and then eventually
nothing will wake it up.
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.
Could this happen if a suspend is initiated before the resume is
completed? I'm using a kernel driver that calls
pm_suspend(PM_SUSPEND_MEM) and perhaps pm_suspend returns before
everything is resumed? If the driver finds no reason for the resume, it
will call suspend again quite quickly.
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.
Yes, that sounds like a good plan. I may be able to find the time to try
this with your guidance if it becomes necessary.
-Andy
