andy git 06/15 suspend/resume observations

[Andy Green]

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

Somebody in the thread at some point said:

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

Yes Graeme's experience was the same here.  I added a patch to andy
which basically ignores the error from the lrclk sync call and reduced
the timeout... if we can see lrclk we sync to it, if we can't we go on
anyway.

I also found out I can suppress the pop on resume -- only on resume
here, same for you? -- if I delay turning the amp on for 3s.  I saw that
there is some code to set Vref with 5K source impedence for 2s and then
50K for the rest of the time the thing is in use, I started meddling
with that as well but didn't get to the end of it yet.  So the "no sound
continuation" issue should be worked around in current git and a pop
solution is coming if I can hide the 3s a bit more.

BTW Mark... we use the sideband path for voice data... no *ALSA* device
is opened during that time, but we could do with 50K source impedence to
Vref not 500K which happens shortly after you close an alsa device.  How
do you think we should come at that?  Keep 50K up while there is any
active analogue routing path open?  Or a new ALSA switch, or something else?

| 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

Ah well that is indeed my standard way, click the power button.  I just
did 100 headphone jack insert / pulls using the same script and that
works perfectly too though.

| see the unit waking up on occasion because of GSM and then eventually
| nothing will wake it up.

What happens if you keep banging the headphone jack in and out?  Is it
in fact GSM or some other EINT wake source that you need to kill it?  I
guess we can't always tell what woke it if it doesn't come back up.  But
if power button NEVER kills it (as I see here) then that is interesting.

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

~  while [ 1 ] ; do echo mem >/sys/power/state ; done

doesn't make any trouble.  But if you're doing it asynchronously in a
kernel driver, I don't know what will happen.  Normally I would think
that the pm stuff knows not to tread on its own toes.  And this problem
predates the deferred codec resume.

Maybe you can try sticking the re-suspend as delayed work for a second
or two.

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

Great, if we can figure out a recipe for reproducing it here it'll save
you the bother though.  It sounds like we are seeing a great deal of
similar behaviour now anyway which is encouraging, maybe all of the
difference is only in my testing actions and your different code.

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

iEYEARECAAYFAkhW6wgACgkQOjLpvpq7dMpWrgCdGfnFw46WLT8urhjuNCRSnhs1
UB0AnRvhnxR61v3m1zcxdR/rO4Jd0D3W
=0t5s
-----END PGP SIGNATURE-----