Re: [alsa-devel] ASoC related suspend problems on OMAP3
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] ASoC related suspend problems on OMAP3
On Thu, Feb 9, 2012 at 10:59 AM, Peter Ujfalusi peter.ujfal...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASoC related suspend problems on OMAP3
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] ASoC related suspend problems on OMAP3
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-de...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] ASoC related suspend problems on OMAP3
On Wed, Feb 8, 2012 at 1:51 PM, Mark Brown broo...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASoC related suspend problems on OMAP3
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
