On Tue, Jan 12, 2010 at 9:41 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:

On Tue, Jan 12, 2010 at 09:35:15PM +0530, Aggarwal, Anuj wrote:

...

b) same command, when audio loopback is running in background

It'd be helpful to specify what you mean by audio loopback here - I think you mean something along the lines of 'arecord | aplay -' but it'd be good to confirm since there's multiple meanings people use for the term.

Thanks for pointing it out, I meant the same: arecord -f cd | aplay & echo mem > /sys/power/state

...

...

I want to check the status of suspend/resume functionality when audio subsystem is being used. Specifically, has some one tried the

following

...

...

tests on their omap3 based platforms:

a) echo mem > /sys/power/state, when audio playback is running in background b) same command, when audio capture is running in background b) same command, when audio loopback is running in background

I am facing some issues with (b) & (c) so wanted to confirm whether someone else has faced similar problem or not.

As Jarkko pointed out in a separate mail, we should not expect the suspend/resume to be working correctly until the context save/restore,

and

...

the clock management is sorted out.

On the other hand it seams that the problem is in the capture path (b

and

...

c having issues).

How is the McBSP configured in your setup (master or slave)?

[Aggarwal, Anuj] TWL4030 is master and McBSP is slave.

...

I think we might have different issues with suspend/resume when OMAP

McBSP

...

is slave or if it is master.

Few (+)updates from my side:

a) Capture not working after suspend/resume: After taking a dump of mcbsp, DMA and codec registers and comparing them, I found out that DMA.CCR[Enable] and DMA.CSR[Sync] bits were set when system was coming out of suspend. I don't understand why these two bits are not set in case of playback running in backgnd but when I forcefully clear them in omap_pcm_trigger() fn under SNDRV_PCM_TRIGGER_RESUME, my problem goes away. Now I am able to do suspend/resume successfully while capture is running in bg without getting the Input/output error.

b) McBSP registers being accessed from omap_pcm_trigger(): When audio playback is running in background and I try suspend, I saw mcbsp registers getting read/written by omap_pcm_trigger() through dma_data->set_threshold(). This happens when soc_pcm_trigger() calls platform->pcm_ops->trigger before cpu_dai->ops->trigger and the clocks are getting enabled only in cpu_dai->trigger. Because of this, I found one warning coming through but this needs a fix.

c) System hangs when audio loopback is going on in background: Finally, I was able to narrow down the problem. After the mcbsp clocks are cut for playback stream, when suspend gets called for capture, mcbsp is stopped inside omap_mcbsp_dai_trigger->SNDRV_PCM_TRIGGER_PAUSE_PUSH, before disabling the clocks. This resulted in hang and the system doesn't come out of snd_pcm_suspend_all() which I reported in my previous email. I modified the clock disabling routine and averted the hang. Now the problem is with the mcbsp/DMA configuration as I am not able to resume the loopback fully (1 in 5 times only it works) and receive this error:

ALSA sound/core/pcm_lib.c:1708: playback write error (DMA or IRQ trouble?)

After this, the application exits gracefully. On further debugging, I realized that mcbsp is not getting configured properly on either the playback or capture stream, while resuming. Hence the error. I think this problem can go if I apply the mcbsp-register-cache patches but I have to try that before I can come to a conclusion.

I have (dirty) fixes for (a) and (b) which, on cleaning, I would be sending for reviews.

Thanks for the suggestions/pointers.