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 well.