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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Aggarwal, Anuj
> Sent: Monday, November 30, 2009 5:21 PM
> To: ext-eero.nurkkala@xxxxxxxxx
> Cc: ext Jarkko Nikula; alsa-devel@xxxxxxxxxxxxxxxx; Wang, Jane;
> broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx; Ujfalusi Peter (Nokia-D/Tampere);
> linux-omap@xxxxxxxxxxxxxxx
> 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?

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux