Mike Turquette <mturquette@xxxxxx> writes: > Kevin Hilman wrote: >> Mike Turquette <mturquette@xxxxxxxxx> writes: >> >>> Adjust OMAP3 frequency transition latency from 10,000,000uS to a more >>> reasonable 300,000uS. This causes ondemand and conservative governors to >>> sample CPU load more often resulting in more responsive behavior. >>> >>> Tested on Android 2.6.29; using this value and conservative governor, CORE >>> power consumption on Zoom2 was comparable to the old and unresponsive >>> 10,000,000uS value while UI responsiveness was greatly improved. >>> >>> This patch applies against Tony's omap-fixes branch. >>> >>> Signed-off-by: Mike Turquette <mturquette@xxxxxx> >>> --- >>> arch/arm/plat-omap/cpu-omap.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c >>> index 1868c0d..341235c 100644 >>> --- a/arch/arm/plat-omap/cpu-omap.c >>> +++ b/arch/arm/plat-omap/cpu-omap.c >>> @@ -127,7 +127,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) >>> } >>> /* FIXME: what's the actual transition time? */ >> >> Can probably drop this 'FIXME' comment now. > > I chose not to drop the FIXME since the worst-case transition time is > still unknown. At some point I'd like to revisit this number with > something better supported by data from the hardware guys. This > number was deemed "safe", but may not be optimal. OK by me. Kevin > >>> - policy->cpuinfo.transition_latency = 10 * 1000 * 1000; >>> + policy->cpuinfo.transition_latency = 300 * 1000; >> >> otherwise, >> >> Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> >> >> Tony, can this still be queued for .32-rc? >> >> Kevin >> -- 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
