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

[Govindraj <govindraj.ti@gmail.com>]

On Fri, Jan 20, 2012 at 6:02 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Govindraj,
>
> On Fri, Jan 20, 2012 at 12:21 PM, Govindraj <govindraj.ti@gmail.com> wrote:
>> On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> 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@ti.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html