[alsa-devel] system suspend and live audio streams

Jarkko Nikula jarkko.nikula at bitmer.com
Sun Apr 15 21:18:11 CEST 2012

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?
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?

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.

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


More information about the Alsa-devel mailing list