Audio suspend/resume status on OMAP3 based platforms

Audio suspend/resume status on OMAP3 based platforms

[Aggarwal, Anuj]

Hi,

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.

Regards,
Anuj Aggarwal

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

[Mark Brown]

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.

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

[Anuj Aggarwal]

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

Re: Audio suspend/resume status on OMAP3 based platforms

[Jarkko Nikula]

On Tue, 12 Jan 2010 21:35:15 +0530
"Aggarwal, Anuj" <anuj.aggarwal@ti.com> wrote:

> 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.
> 
Unfortunately the proper OMAP ASoC suspend/resume functionality is still
missing and the development progress has been slow. There are few
issues in low-level McBSP code like proper clock management,
context save/restore, how to deal with the FIFO, etc. and those should
be addressed first.

Fortunately Janusz Krzysztofik has been cleaning up and developing the
register cache support in McBSP and that work could help the PM work as
well. Clock management changes don't look complicated but just requires
that one develops it.

http://mailman.alsa-project.org/pipermail/alsa-devel/2009-November/023119.html


-- 
Jarkko

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

[Peter Ujfalusi]

On Tuesday 12 January 2010 18:05:15 ext Aggarwal, Anuj wrote:
> Hi,
> 
> 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)?
I think we might have different issues with suspend/resume when OMAP McBSP is 
slave or if it is master.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio suspend/resume status on OMAP3 based platforms

[Aggarwal, Anuj]

> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com]
> Sent: Wednesday, January 13, 2010 12:40 PM
> To: alsa-devel@alsa-project.org
> Cc: Aggarwal, Anuj; linux-omap@vger.kernel.org
> Subject: Re: [alsa-devel] Audio suspend/resume status on OMAP3 based
> platforms
> 
> On Tuesday 12 January 2010 18:05:15 ext Aggarwal, Anuj wrote:
> > Hi,
> >
> > 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.

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