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