andy git 06/15 suspend/resume observations

[Sean McNeil]

Andy Green wrote:
> 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.
>

Yes, I only get the pop now on resume.

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

In my application, I always have an *ALSA* device open when in a call. I 
open different pseudo devices depending on the mode (normal with 
speaker, normal in a call, speaker out in a call, headphone stuff, etc).

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

I'll try to see if I can get it to happen with headphone jack. I can 
also try disabling the radio interface to see if it will hang without a 
GSM wakeup. Also keep in mind there is a long period of being in suspend 
before an attempted resume. Make sure you give it 10 minutes or more 
between suspend/resume.

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

I'll try to narrow the problem down before I do this.

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