[alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Peter Ujfalusi]

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