On 26 November 2014 at 03:22, Mason <mpeg.blue@xxxxxxx> wrote: > If I remember correctly (please correct me if I am mistaken), > the kernel keeps a list of timers, ordered by deadline, and > dynamically configures the system timer to fire at the next > deadline. Yes. >> Look for: /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate >> this is the rate at which cpufreq core checks if cpu's freq require revisiting. > > I think setting the sampling rate to 50 ms should make the > system reactive enough to load swings? Depends on the kind of load system is under. If load changes quite frequently then 50 ms can be a very big value. If it doesn't then 50 ms might be good. But it has to be tuned properly based on how much load the system has and how much power it consumes. Some information about that tuning can be found here: https://www.youtube.com/watch?v=he1UO__K9ao This is an presentation given by Mathieu Poirier (Linaro) about the work done on ARM's big LITTLE architecture. Slides: http://events.linuxfoundation.org/images/stories/slides/elc2013_poirier.pdf >>> This 'struct clk' is an elusive beast. >>> Where is it defined? I only run into forward declarations. >> >> Its architecture specific. What's the architecture you are working on? >> You may implement your own routine instead of cpufreq_generic_get(). > > The SoC is made by Sigma Designs. It is based on the ARM Cortex-A9. Okay, life should be easy then. Normally there will be few programmable PLLs on your platform. You need to write a clock driver for them similar to the ones present here: drivers/clk/ And then you can reuse cpufreq-dt.c cpufreq driver, which is generic enough for everybody :) >> Yes. Documentation/clk.txt. > > Oh boy! platform, device tree, cpu-freq, cpuidle, clk, ... so much > to learn, so few hours in a day. :) -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
