Govindraj, On Fri, Jan 20, 2012 at 12:21 PM, Govindraj <[email protected]> wrote: > On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <[email protected]> wrote: >> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: >>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <[email protected]> >>> wrote: >>> > Hi, >>> > >>> > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably >>> > related to PM. >>> > >>> > First, when I boot up, the console (via USB serial) is very laggy, it >>> > often takes many seconds until the key pressed appears so it's more or >>> > less unusable. >>> >>> can you try enabling CONFIG_CPU_IDLE ? >> >> Enabling CPU_IDLE does remove the problems. I don't know what it's >> supposed to do, but it seems to keep the MPU and DSS in ON state all the >> time, so the problem disappears. > > 3.3-rc1 has uart runtime patches merged we have removed uart dependency > for system to enter low powers states and used pm_qos calls, > but pm_qos api's seem do get activated only by enabling config_cpu_idle. > > Question to kevin/Paul, > > Shouldn't system be doing wfi if cpu_idle is not enabled ? > > since we are mapping omap3_pm_idle to pm_idle thread > system enters low power states even if config_cpu_idle is not enabled. > Is this expected behavior? Yes the wfi instruction gets executed in all cases. However with CPU_IDLE enabled a valid C-state is selected, depending on the requested PM QoS constraints. Then the MPU and CORE next power states are programmed accordingly.
Cf. code in arch/arm/mach-omap2/cpuidle34xx.c which is conditionally compiled on the CPU_IDLE option. Jean > > -- > Thanks, > Govindraj.R > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
