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