[alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Aggarwal, Anuj]

> > -----Original Message-----
> > From: Aggarwal, Anuj
> > Sent: Monday, November 30, 2009 5:21 PM
> > To: ext-eero.nurkkala at nokia.com
> > Cc: ext Jarkko Nikula; alsa-devel at alsa-project.org; Wang, Jane;
> > broonie at opensource.wolfsonmicro.com; Ujfalusi Peter (Nokia-D/Tampere);
> > linux-omap at vger.kernel.org
> > Subject: RE: [alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume
> failure
> > fix
> >
> > > > Looking at the very original patch, I don't know how things could
> get
> > > > into deep sleep by disabling the fclk only... need to disable the
> iclk
> > > > also. In threshold mode, HW autogates the iclk, so you may be just
> > > > "lucky".
> > > [Anuj] No, I am not :(. I had to modify the original patch to include
> > > the disable part for the ICLK too. Without that, I was not able to hit
> > > retention.
> > > I will try to do some further regression on OMAP3 EVM and post my
> > > findings. As of now, audio is working fine with these patches + ICLK
> > > modification.
> > [Aggarwal, Anuj] After further testing, I found that there is some
> > problem in the capture path. While capturing in background, if I tried
> > to do suspend, capture fails after a few seconds giving;
> > arecord: pcm_read:1617: read error: Input/output error
> > This I was discussing in another thread (*) for AIC23/AM3517 on NFS but
> > now
> > I realized after finishing my tests that this behavior is common for
> > both omap3530/twl4030 and am3517/aic23. Moreover, the problem doesn't
> > depend on the underlying file system - both NFS and ramdisk produce the
> > same error.
> > To make matter worse, if suspend/resume is tried while audio
> > loopback is running, system just hangs. Even telnet to the evm doesn't
> > work.
> > So the audio capture path, from suspend/resume point of view, definitely
> > needs some more time.
> > I will continue debugging at my end. But pointers are always welcome.
> [Aggarwal, Anuj] I think I found one possible root cause of the hang which
> is observed if suspend/resume is tried while audio loopback is going on.
> 
> soc_suspend() calls snd_pcm_suspend_all() which calls snd_pcm_suspend()
> for all the substreams in the pcm->streams[]. On debugging, I found that
> I am not able to come out of snd_pcm_suspend_all(). I think this API needs
> some fix as the comment also suggests:
> FIXME: the open/close code should lock this as well
> 
> Could this be the root cause of this hang? Any pointers on what needs to
> be
> fixed?
> 
[Aggarwal, Anuj] Can someone please confirm that the problem lies in this 
API? Also, any help on how that can be fixed would be great.

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