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