> > -----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: [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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
