[alsa-devel] Audio suspend/resume status on OMAP3 based platforms

[Aggarwal, Anuj]

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