Hello Benoit, One comment below: > > In fact, this is Mike who started that analysis. We discussed that internally and > our point is that if the CPUFreq ondemand or conservative heuristic is not able > to increase quickly enough the CPU need to handle correctly the UI, we have > to somehow improve or modify the governor in order to provide it a extra > information in term of constraint maybe in order to increase immediately the > frequency. The information as you mention needs to be supplied by the driver. The governor would then act on behalf of the driver! This begs for a new governor API or a signature change to an existing governor API. > > This should not be done in the low level omap_pm code; this is not the right > level to do that. The issue is in the ondemand and must be fixed there. > At the end of the day it would still be the driver making the decision! Regards, -Romit -- 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