On Fri, Jan 20, 2012 at 6:02 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> wrote: > Govindraj, > > On Fri, Jan 20, 2012 at 12:21 PM, Govindraj <govindraj.ti@xxxxxxxxx> wrote: >> On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: >>> On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: >>>> On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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. > okay, but if cpuidle is not selected shouldn't it prevent system from going to low power state. -- Govindraj.R -- 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
