On Thursday 19 November 2009 21:48:26 ext Anuj Aggarwal wrote: > [Anuj] Yes, w/o audio, it goes into suspend neatly. > After going through the entire patch series "[PATCHv5 00/20] OMAP > ASoC changes in DMA utilization", which I missed earlier, I found that the > sysfs entry dma_op_mode can be toggled among element/frame/threshold, > by default which is element hence not allowing the mcbsp driver to go into > idle state. I changed that at run time and after that I am able to hit > the suspend > state while playing back audio (at least the log doesn't > show that the system is not able to hit suspend). > 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. In some cases the element mode is desirable over the threshold mode, and probably there are additional modes can be implemented for other cases, hence the sysfs interface is really useful feature. Back than there were quite a bit of discussion here about the threshold mode: in the original series the threshold mode was the default, but we decided to not to do that before others have the chance to test it. We have been using the threshold mode without issues internally, so it should be really stable, but it is still a new mode, which can break other implementations. So please test the threshold mode in your HW, and report if it is working there OK, if we have enough positive feedbacks, than we can make it as default. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
