Re: system suspend and live audio streams

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

Hi,

On 04/15/2012 10:18 PM, Jarkko Nikula wrote:
> On 04/14/2012 06:40 PM, Grazvydas Ignotas wrote:
>> Hi,
>>
>> Currently on OMAP the system fails to suspend properly if there are
>> audio streams active (PER and CORE don't enter low power states). I
>> wonder if this is expected to be handled by the driver and can be
>> considered a bug, or is it audio daemon's/system's responsibility to
>> stop all audio streams before kernel to is asked to start suspending?

Did the suspend/resume worked in the past during audio activity?

>>
> Hmm.. this is actually something which is not implemented.
> 
> Before arch/arm/plat-omap/mcbsp: omap_mcbsp_request used to enable
> clocks and keep them active until omap_mcbsp_free. I.e.
> omap_mcbsp_stop/_start which are called during suspend-resume cycle
> don't change the clock state.
> 
> I don't actually remember why it used to be so. Might be related to SPI
> mode use on OMAP1?

We need to have the clocks enabled in order to change McBSP registers.
We do register writes in several places after startup (prepare,
hw_params, clock configuration).

> But as now the SPI support is dropped (no users and not supported in
> later omaps) and mcbsp is merged with omap-mcbsp (no other users than
> audio) I don't see why the clocks (or runtime pm) should be active
> before omap_mcbsp_start.

Because we need to write registers (configure McPBSP).

> I don't know immediately does this require any major changes for McBSP
> register access that are done in function calls before omap_mcbsp_start
> (IRCC hwmod might set already ICLK gating for register access) but some
> code is needed to deal with McBSP register cache restore (due OMAP
> OFFMODE that might be hit) and most probably for McBSP FIFO draining as
> well.

What we need to do is to have proper register store/restore for McBSP to
support suspend during audio activity. But. Even with that if the McBSP
is hitting OFF mode we will loose the McBSP FIFO content (invalidated).
This means we are going to have missing samples. Probably the user will
not going to notice it, but it is going to happen.
I'm sure this issue present on other platforms as well. The pm_runtime
is handled by the core, we should have suspend/resume checked in ASoC
core, if there's an issue we need to fix it. After that the McBSP
store/restore need to be implemented.

-- 
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel