> > 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. *) http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg19845.html > > > > One may want to be aware of this also: > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- > 2.6.git;a=commitdiff;h=72cc6d715d5b018e2cff4adb68966855850d4e77 > > > > I think it's an undocumented feature. > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
