andy git 06/15 suspend/resume observations
sean at mcneil.com
Tue Jun 17 01:16:46 CEST 2008
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
> 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
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
> | 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
> |> 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.
More information about the openmoko-kernel