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.
Mike
- 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
