Hi Jeremy,
Sorry for delay sending out this patch, I was slow down by other
things and eye infection :(
I followed your suggestion to make clock debug interface cleaner and
more independent, like removing unnecessary #ifdef and moving all
operations to kernel/clk.c.
>From 2b6c378c3c42d695f72f987e
On Thursday 25 November 2010 13:05:49 Vishwanath Sripathy wrote:
> Thanks David.
> If I would like to fine tune up_threshold and sampling_down_factor for
> say OMAP platform, is there any way to do it in kernel itself?
> I know these are configurable via sysfs entries. But if I want to
> optimize t
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,
transito
Thanks David.
If I would like to fine tune up_threshold and sampling_down_factor for
say OMAP platform, is there any way to do it in kernel itself?
I know these are configurable via sysfs entries. But if I want to
optimize them in kernel itself, is there anyway? I see that default
values are set in
Thanks for running the tests, Vishwa. Your results are what I'd expect
but it's good to see independent confirmation. In my benchmarks I saw
95-100% of the performance governor's performance, but the conditions
were more favorable and the original ondemand governor was "only"
degrading performan