| Submitter | Mike Turquette |
|---|---|
| Date | 2009-10-29 21:02:09 |
| Message ID | <1256850129-31618-1-git-send-email-mturquette@ti.com> |
| Download | mbox | patch |
| Permalink | /patch/56520/ |
| State | Accepted |
| Commit | 2a817bb46c1cd125e2091cf2d7209ec7995adf84 |
| Headers | show |
Comments
Mike Turquette <mturquette@gmail.com> 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@ti.com> > --- > 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. > - policy->cpuinfo.transition_latency = 10 * 1000 * 1000; > + policy->cpuinfo.transition_latency = 300 * 1000; otherwise, Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mike Turquette <mturquette@ti.com> writes: > Kevin Hilman wrote: >> Mike Turquette <mturquette@gmail.com> 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@ti.com> >>> --- >>> 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@deeprootsystems.com> >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin Hilman wrote: > Mike Turquette <mturquette@gmail.com> 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@ti.com> >> --- >> 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@deeprootsystems.com> > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kevin Hilman <khilman@deeprootsystems.com> [091029 14:14]: > Mike Turquette <mturquette@gmail.com> 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@ti.com> > > --- > > 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. > > > - policy->cpuinfo.transition_latency = 10 * 1000 * 1000; > > + policy->cpuinfo.transition_latency = 300 * 1000; > > otherwise, > > Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> > > Tony, can this still be queued for .32-rc? Sure, I'll put together one more omap-fixes series this week. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 2a817bb46c1cd125e2091cf2d7209ec7995adf84 PatchWorks http://patchwork.kernel.org/patch/56520/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2a817bb46c1cd125e2091cf2d7209ec7995adf84 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch
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? */ - policy->cpuinfo.transition_latency = 10 * 1000 * 1000; + policy->cpuinfo.transition_latency = 300 * 1000; return 0; }
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@ti.com> --- arch/arm/plat-omap/cpu-omap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)