[PATCH] OMAP PM: Optimize cpufreq transition latency

Vishwanath BS vishwanath.bs at ti.com
Thu Nov 25 13:38:11 UTC 2010


Currently cpufreq transition latency value does not really reflect the actual
OMAP OPP transition delay. This patch has the actual latency value.
I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value 
goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer 
expiry.
With this change, performance of ondemand governor is improved when tested
using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand
performance as 40% of performance governor, and with this patch it's around 70%
(using below procedure).

cpufreq-bench: 
http://lwn.net/Articles/339862/
http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/

Command used for performance testing:
cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -v

Signed-off-by: Vishwanath BS <vishwanath.bs at ti.com>
---
 arch/arm/plat-omap/cpu-omap.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c

diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
old mode 100644
new mode 100755
index c47faf8..d3fc423
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 	policy->max = policy->cpuinfo.max_freq;
 	policy->cur = omap_getspeed(0);
 
-	/* FIXME: what's the actual transition time? */
-	policy->cpuinfo.transition_latency = 300 * 1000;
+	/* Program the actual transition time for worstcase */
+	policy->cpuinfo.transition_latency = 30 * 1000;
 
 	return 0;
 }
-- 
1.7.0.4




More information about the linaro-dev mailing list