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

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

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