-----Original Message----- From: Aggarwal, Anuj Sent: Monday, November 30, 2009 5:21 PM To: ext-eero.nurkkala@nokia.com Cc: ext Jarkko Nikula; alsa-devel@alsa-project.org; Wang, Jane; broonie@opensource.wolfsonmicro.com; Ujfalusi Peter (Nokia-D/Tampere); linux-omap@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html