Re: PM(?) problems on v3.3-rc1 on OMAP3

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Fri, 20 Jan 2012 17:00:09 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
wrote:


> Hmm, So CPU_IDLE is also about other power domains than mpu? What does
> it do? The CONFIG_CPU_IDLE help text doesn't say much.

On OMAP3x, CPU_IDLE is about the MPU and CORE power domains .. and about PER
to some extent I think.

Different CPU_IDLE states put one or both of MPU and CORE into lower power
states (RET or OFF).  If a domain is turned off, then the code restores stuff
afterwards.

But CPU_IDLE also does stuff with clocks, and I think this is where the issue
is.

I modified my kernel to refuse any CPU_IDLE state where MPU or CORE were
anything but ON - so only C1 and C2 were allowed.
I still had problems with DSS SYNC.

I then modified the C2 state so that it didn't allow the clocks to
auto-idle.  This is the main difference between C1 and C2 I think.

i.e. in omap3_enter_idle() in cpuidle34xx.c, I enforced the

		pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
		pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);

and 

		pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
		pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);

loops for C1 - they are normally only active for C1.

This allowed DSS to work fine.  It also removed my issues with HDQ.

This code disables the auto-idling of some clocks ... not entirely sure of
the details.

So it seems that it isn't a low power state but rather some clock being
allowed to turn off which is the problem.

I guess I could selective try denying idle on each clock domain until I find
the one that is the problem..

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]