[alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix
anuj.aggarwal at ti.com
Fri Nov 20 15:47:48 CET 2009
On Fri, Nov 20, 2009 at 7:39 PM, Eero Nurkkala
<ext-eero.nurkkala at nokia.com> 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 at 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.
> 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
[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
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
> One may want to be aware of this also:
> I think it's an undocumented feature.
> - Eero
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel