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.

On 04/16/2012 01:40 PM, Peter Ujfalusi wrote:

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.

I meant above if hwmod has already set ICLK so (was it autogating?) that manual enable/disable cycle for ICLK may not be needed for register access if clock is automatically gated. I have vague memory that I saw something like this in hwmod for some block but I'm not sure about this.

But that reminds me that did we have some use-case where FCLK was needed during register access?

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.

For register store/restore there is already much implemented thanks to Janusz's register cache workaround for OMAP1510 :-)

For FIFO I was thinking, if possible, to drain it out before going to suspend.