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

[Anuj Aggarwal]

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
> "lucky".
[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
retention.
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
modification.
>
> 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
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>