Re: [PATCH] OMAP3: decrease cpufreq transition latency

[Kevin Hilman <khilman@deeprootsystems.com>]

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