ASoC related suspend problems on OMAP3

ASoC related suspend problems on OMAP3

[Grazvydas Ignotas]

Hi,

On OMAP3 pandora, system suspend stops working properly after using
audio at least once:

(just after boot):
# echo mem > /sys/power/state
[   12.578186] PM: Entering mem sleep
[   12.678802] PM: suspend of devices complete after 92.834 msecs
[   12.688201] PM: late suspend of devices complete after 3.173 msecs
[   17.607971] Successfully put all powerdomains to target state

# aplay /dev/zero
^C
# echo mem > /sys/power/state
[  104.404663] PM: suspend of devices complete after 78.794 msecs
[  104.413909] PM: late suspend of devices complete after 3.021 msecs
[  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
[  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
[  106.613739] Could not enter target state in pm_suspend

I'm seeing this on 3.2, unable to verify on current Linus HEAD as
something else is preventing core/per low power states there.
Any ideas what could be causing this? Perhaps some clock is left enabled?

-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ASoC related suspend problems on OMAP3

[Jarkko Nikula]

On 02/08/2012 02:34 AM, Grazvydas Ignotas wrote:
> Hi,
> 
> On OMAP3 pandora, system suspend stops working properly after using
> audio at least once:
> 
> (just after boot):
> # echo mem > /sys/power/state
> [   12.578186] PM: Entering mem sleep
> [   12.678802] PM: suspend of devices complete after 92.834 msecs
> [   12.688201] PM: late suspend of devices complete after 3.173 msecs
> [   17.607971] Successfully put all powerdomains to target state
> 
> # aplay /dev/zero
> ^C
> # echo mem > /sys/power/state
> [  104.404663] PM: suspend of devices complete after 78.794 msecs
> [  104.413909] PM: late suspend of devices complete after 3.021 msecs
> [  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
> [  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
> [  106.613739] Could not enter target state in pm_suspend
> 
> I'm seeing this on 3.2, unable to verify on current Linus HEAD as
> something else is preventing core/per low power states there.
> Any ideas what could be causing this? Perhaps some clock is left enabled?
> 
If this is still working in 3.1 then one possible reason could be my
mcbsp changes between commits 40246e..7bc0c4 that went to 3.2.

Unfortunately I'm not near my OMAP3 boards in coming days so I cannot
bisect myself.

-- 
Jarkko

Re: ASoC related suspend problems on OMAP3

[Peter Ujfalusi]

On 02/08/2012 02:34 AM, Grazvydas Ignotas wrote:
> Hi,
> 
> On OMAP3 pandora, system suspend stops working properly after using
> audio at least once:
> 
> (just after boot):
> # echo mem > /sys/power/state
> [   12.578186] PM: Entering mem sleep
> [   12.678802] PM: suspend of devices complete after 92.834 msecs
> [   12.688201] PM: late suspend of devices complete after 3.173 msecs
> [   17.607971] Successfully put all powerdomains to target state
> 
> # aplay /dev/zero
> ^C
> # echo mem > /sys/power/state
> [  104.404663] PM: suspend of devices complete after 78.794 msecs
> [  104.413909] PM: late suspend of devices complete after 3.021 msecs
> [  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
> [  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
> [  106.613739] Could not enter target state in pm_suspend
> 
> I'm seeing this on 3.2, unable to verify on current Linus HEAD as
> something else is preventing core/per low power states there.
> Any ideas what could be causing this? Perhaps some clock is left enabled?

I would bet that some clocks left enabled, but it as far as I can tell
the audio path is well balanced in regards of clocks.

So I'm not sure, but I just checked with 3.3-rc2 on Beagle xM (Rev C):

after boot:
# echo mem > /sys/power/state
[  163.776153] Freezing user space processes ...
[  163.804595] (elapsed 0.02 seconds) done.
[  163.808746] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
[  163.837097] Suspending console(s) (use no_console_suspend to debug)
[  164.019042] PM: suspend of devices complete after 157.684 msecs
[  164.025115] PM: late suspend of devices complete after 6.011 msecs
[  164.025238] Disabling non-boot CPUs ...
[  172.497528] Successfully put all powerdomains to target state

aplay <some wav>

# echo mem > /sys/power/state
[  300.574920] Freezing user space processes ...
[  300.602874] (elapsed 0.02 seconds) done.
[  300.607025] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
[  300.635620] Suspending console(s) (use no_console_suspend to debug)
[  300.809692] PM: suspend of devices complete after 149.810 msecs
[  300.814117] PM: late suspend of devices complete after 4.364 msecs
[  300.814147] Disabling non-boot CPUs ...
[  309.520721] Successfully put all powerdomains to target state

Here it seams to be OK...
You could try to compare the clock counts after boot, and after the aplay:

cat /sys/kernel/debug/clock/summary

if they differ we leave have unbalanced clock handling...

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ASoC related suspend problems on OMAP3

[Mark Brown]

On Wed, Feb 08, 2012 at 02:34:38AM +0200, Grazvydas Ignotas wrote:
> Hi,
> 
> On OMAP3 pandora, system suspend stops working properly after using
> audio at least once:

Also adding Liam to the CC list (and not deleting any context for
visibility).

> 
> (just after boot):
> # echo mem > /sys/power/state
> [   12.578186] PM: Entering mem sleep
> [   12.678802] PM: suspend of devices complete after 92.834 msecs
> [   12.688201] PM: late suspend of devices complete after 3.173 msecs
> [   17.607971] Successfully put all powerdomains to target state
> 
> # aplay /dev/zero
> ^C
> # echo mem > /sys/power/state
> [  104.404663] PM: suspend of devices complete after 78.794 msecs
> [  104.413909] PM: late suspend of devices complete after 3.021 msecs
> [  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
> [  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
> [  106.613739] Could not enter target state in pm_suspend
> 
> I'm seeing this on 3.2, unable to verify on current Linus HEAD as
> something else is preventing core/per low power states there.
> Any ideas what could be causing this? Perhaps some clock is left enabled?
> 
> -- 
> Gra??vydas
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: [alsa-devel] ASoC related suspend problems on OMAP3

[Grazvydas Ignotas]

On Wed, Feb 8, 2012 at 1:51 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Feb 08, 2012 at 02:34:38AM +0200, Grazvydas Ignotas wrote:
>> # aplay /dev/zero
>> ^C
>> # echo mem > /sys/power/state
>> [  104.404663] PM: suspend of devices complete after 78.794 msecs
>> [  104.413909] PM: late suspend of devices complete after 3.021 msecs
>> [  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
>> [  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
>> [  106.613739] Could not enter target state in pm_suspend
>>
>> I'm seeing this on 3.2, unable to verify on current Linus HEAD as
>> something else is preventing core/per low power states there.
>> Any ideas what could be causing this? Perhaps some clock is left enabled?

ok I've figured it out myself - it's because of McBSP2 clock source
selection. Pandora has rather unusual config (compared to other
boards) that it gets McBSP2 audio clock through external pin. As long
as it's set to PRCM functional clock (OMAP internal, reset default)
the system suspends fine, but if it's set to external,
per_pwrdm+core_pwrdm won't switch to lower power states.

Pandora sets this by calling snd_soc_dai_set_sysclk() from
snd_soc_ops.hw_params callback. Now I wonder, where should I set the
clock back so it suspends again, perhaps from snd_soc_ops.hw_free
callback? Or maybe it should be handled by omap-mcbsp ASoC driver,
perhaps something needs to be configured on McBSP itself for it to go
idle with external clock set?

-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] ASoC related suspend problems on OMAP3

[Peter Ujfalusi]

On 02/08/2012 06:19 PM, Grazvydas Ignotas wrote:
> ok I've figured it out myself - it's because of McBSP2 clock source
> selection. Pandora has rather unusual config (compared to other
> boards) that it gets McBSP2 audio clock through external pin. As long
> as it's set to PRCM functional clock (OMAP internal, reset default)
> the system suspends fine, but if it's set to external,
> per_pwrdm+core_pwrdm won't switch to lower power states.
> 
> Pandora sets this by calling snd_soc_dai_set_sysclk() from
> snd_soc_ops.hw_params callback. Now I wonder, where should I set the
> clock back so it suspends again, perhaps from snd_soc_ops.hw_free
> callback? Or maybe it should be handled by omap-mcbsp ASoC driver,
> perhaps something needs to be configured on McBSP itself for it to go
> idle with external clock set?

I assume this worked in the past on pandora (suspend), right?

Can you try one _hack_ to see if it helps?
In omap_mcbsp_request function:
set the CLOCKACTIVITY field to 0x3 in the sysconfig register.
Or you can as well try to do the same in
mach-omap2/omap_hwmod_3xxx_data.c, look for omap3xxx_mcbsp_sysc, and
change the .clockact = 0x2 to 0x3.

Not sure if this helps, but I would be interested to see the results...

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ASoC related suspend problems on OMAP3

[Grazvydas Ignotas]

On Thu, Feb 9, 2012 at 10:59 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 02/08/2012 06:19 PM, Grazvydas Ignotas wrote:
>> ok I've figured it out myself - it's because of McBSP2 clock source
>> selection. Pandora has rather unusual config (compared to other
>> boards) that it gets McBSP2 audio clock through external pin. As long
>> as it's set to PRCM functional clock (OMAP internal, reset default)
>> the system suspends fine, but if it's set to external,
>> per_pwrdm+core_pwrdm won't switch to lower power states.
>>
>> Pandora sets this by calling snd_soc_dai_set_sysclk() from
>> snd_soc_ops.hw_params callback. Now I wonder, where should I set the
>> clock back so it suspends again, perhaps from snd_soc_ops.hw_free
>> callback? Or maybe it should be handled by omap-mcbsp ASoC driver,
>> perhaps something needs to be configured on McBSP itself for it to go
>> idle with external clock set?
>
> I assume this worked in the past on pandora (suspend), right?

Not really, we did not have working suspend until now due to unrelated
driver issues (we are slow, I know..).

> Can you try one _hack_ to see if it helps?
> In omap_mcbsp_request function:
> set the CLOCKACTIVITY field to 0x3 in the sysconfig register.
> Or you can as well try to do the same in
> mach-omap2/omap_hwmod_3xxx_data.c, look for omap3xxx_mcbsp_sysc, and
> change the .clockact = 0x2 to 0x3.
>
> Not sure if this helps, but I would be interested to see the results...

I've changed the hwmod data and it doesn't seem to help. After
playing, just before suspend, I've tried to read mcbsp2 SYSCONFIG
through /dev/mem and it seems CLOCKACTIVITY is 0 at that time. Also
tried forcing CLOCKACTIVITY to 3, 2, 1 using the same method just
before suspend, didn't help either. As soon as I cleared MCBSP2_CLKS
in CONTROL_DEVCONF0 it started suspending properly.


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