On Fri, Nov 20, 2009 at 7:39 PM, Eero Nurkkala <ext-eero.nurkkala@xxxxxxxxx> wrote: > On Fri, 2009-11-20 at 14:53 +0100, ext Jarkko Nikula wrote: >> On Fri, 20 Nov 2009 09:51:13 +0200 >> Peter Ujfalusi <peter.ujfalusi@xxxxxxxxx> wrote: >> >> > > My question is: is sysfs the only way to choose threshold or can it be made >> > > as default? I could not see that happening in the code so thinking of the >> > > possible reason of choosing not to do so. Because the user who wants to >> > > hit suspend will not like to issue driver specific commands. Any specific >> > > reason of not doing that by default? >> > >> > It is not selected as default on OMAP3, since it is a new feature, and we don't >> > want to change the behavior of the audio. If the reports are positive regarding >> > to the threshold mode, than we can make it as default on OMAP3, at least that is >> > the plan AFAIK. >> >> Yep. Currently we want to keep DMA behaviour consistent across the >> OMAPs and McBSP ports since the large internal FIFO is found only >> from McBSP2 on OMAP3. >> >> This is good finding that you have found that it's the audio preventing >> the suspend and the threshold transfer mode can make it hit better. >> >> But anyway, I'm afraid that threshold mode doesn't help to create >> robust suspend. Threshold allow the DMA and core to be mode in idle >> between the FIFO fills and probably that's why suspend might work >> during these idle periods. For robust implementation there must be >> explicit code stopping and resuming all activity gracefully so that it >> can hit the suspend also if the fill is happening or if using another >> transfer mode. >> >> > > 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. > > 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. > > - Eero > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
