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

[Grazvydas Ignotas <notasas@gmail.com>]

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