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