On Thu, Feb 9, 2012 at 10:59 AM, Peter Ujfalusi <peter.ujfalusi@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
