Hi Govindraj, On Thu, Oct 13, 2011 at 3:09 AM, Govindraj <govindraj.ti@xxxxxxxxx> wrote: ... >> >> 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. > >> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
