[PATCH] OMAP3: decrease cpufreq transition latency

[PATCH] OMAP3: decrease cpufreq transition latency

[Mike Turquette]

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? */
-	policy->cpuinfo.transition_latency = 10 * 1000 * 1000;
+	policy->cpuinfo.transition_latency = 300 * 1000;
 
 	return 0;
 }
-- 
1.6.3.2

Re: [PATCH] OMAP3: decrease cpufreq transition latency

[Kevin Hilman]

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

Re: [PATCH] OMAP3: decrease cpufreq transition latency

[Kevin Hilman]

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

Re: [PATCH] OMAP3: decrease cpufreq transition latency

[Mike Turquette]

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
> 

Re: [PATCH] OMAP3: decrease cpufreq transition latency

[Tony Lindgren]

* 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

[APPLIED] [PATCH] OMAP3: decrease cpufreq transition latency

[Tony Lindgren]

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