Hi Govindraj,

On Thu, Oct 13, 2011 at 3:09 AM, Govindraj [off-list ref] wrote:
...

quoted

Yes, but obviously comes at the expense of power savings. ?IOW, This is
a hard-coded power vs. performance trade off that we are trying to get
away from.

So, the root of the problem is that the MPU wakeup latency is causing a
"sluggish" console. ?The solution? ?request an MPU wakeup latency
constraint.

Okay, Will explore this.

quoted

This is a classic use-case for such a constraint, and the serial driver
should have the option of requesting a constraint to prevent the sluggish
console. ?The constraint only needs to be held until the auto-suspend
delay expires, so should be relased in the ->runtime_suspend() method of
the driver.

This constraint needs to be configurable, probably from the board file,
so that it is optional, and so users who don't care about sluggish
consoles (or non-console UART users who don't care about response time)
have the option of preferring power savings over UART responsiveness.

As a reference, the i2c driver is currently doing something similar
in that it request an MPU constraint to prevent the MPU from going into
retention/off while waiting for an i2c interrupt to arrive.

Thanks, will check and try to use the mpu constraints

As a reference the pm-qos branch of
https://gitorious.org/jpihet/omap-pm has the latest code for the
per-device constraints framework.

Please refer to the documentation at Documentation/power/pm_qos_interface.txt.
The commit dbec9ed1 [1] shows how I2C is using the framework.

[1] https://gitorious.org/jpihet/omap-pm/commit/dbec9ed1a6d6341d2ad2352a9578d66d15d198f4

Regards,
Jean

--
Govindraj.R.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html