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.