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

Jean Pihet
2012-01-20T12:32:39Z

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.

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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html