On Fri, 20 Jan 2012 17:00:09 +0200 Tomi Valkeinen <tomi.valkei...@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
signature.asc
Description: PGP signature
