system suspend and live audio streams

system suspend and live audio streams

[Grazvydas Ignotas]

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?

-- 
Gražvydas
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: system suspend and live audio streams

[Jarkko Nikula]

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.

-- 
Jarkko

Re: system suspend and live audio streams

[Peter Ujfalusi]

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

Re: system suspend and live audio streams

[Mark Brown]

On Mon, Apr 16, 2012 at 01:40:41PM +0300, Peter Ujfalusi wrote:

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

If the driver is using runtime PM and needs to ensure that a reference
is held outside of audio streaming then it should be taking care of
holding a reference itself.

Tegra is now handling this using the regmap cache infrastructure to make
the device powerdown transparent.

Re: system suspend and live audio streams

[Jarkko Nikula]

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.

-- 
Jarkko

Re: system suspend and live audio streams

[Grazvydas Ignotas]

On Mon, Apr 16, 2012 at 1:40 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 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?

I don't think so.

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

Could we maybe first get it working with RET (I think it's currently
default for suspend to RAM), where register contents are not lost
AFAIK? What needs to be done there, transmitter stopped and clocks
disabled I guess, anything else? I wonder if ongoing DMA needs to be
handled somehow too.
For our use case FIFO loss, if it happens, shouldn't be a big deal.


-- 
Gražvydas
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel