On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
All files which are directly present in cpu/cpu*/cpufreq/ folder. I am not talking about governor tunables but policy tunables. Things like scaling_[min]max_freq are policy tunables.
No, on x86 those are the P-states frequencies. They're defined by the hardware.
Policies don't have a name associated with them and so cpu/cpufreq/policies doesn't make any sense. Rather one policy is related to multiple cpus and its tunables are linked in all the cpus that belong to it, like scaling_[min]max_freq.
Then do the following:
cpu/cpufreq/policies/ |-> policy0 |-> min_freq |-> max_freq |-> affected_cpus ...
or whatever needs to be a flexible interface for multi-policy cpufreq support.
Remember: once you do those, they're more or less cast in stone so take your time and do the design right, do not hurry those.
Don't have examples of these, but there can be few. Over that it is a must for multicluster systems as clusters normally have separate clock control.
Yeah, nice try. We only support real hardware in the kernel, not what could there be.
But then we will get governors tunables in cpu/cpu*/cpufreq/ instead of cpu/cpufreq/ . Will that not break userspace for other systems?
What's wrong with having both? The cpu/cpufreq/ governor will set the system-wide governor and the cpu/cpu*/cpufreq/ will add the different policies.