Re: [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Jarkko Nikula <jhnikula@gmail.com>]

On Fri, 20 Nov 2009 09:51:13 +0200
Peter Ujfalusi <peter.ujfalusi@nokia.com> 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.


-- 
Jarkko