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@vger.kernel.org/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.