user/sven/linux.git/include/linux/cpufreq.h, branch v3.10.36

cpufreq: Notify all policy->cpus in cpufreq_notify_transition()

2013-04-02T13:24:00Z

policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together. Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core. This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API. Signed-off-by: Viresh Kumar Acked-by: Stephen Warren Tested-by: Stephen Warren Signed-off-by: Rafael J. Wysocki

cpufreq: governor: Implement per policy instances of governors

2013-03-31T23:11:34Z

Currently, there can't be multiple instances of single governor_type. If we have a multi-package system, where we have multiple instances of struct policy (per package), we can't have multiple instances of same governor. i.e. We can't have multiple instances of ondemand governor for multiple packages. Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/ governor-name/. Which again reflects that there can be only one instance of a governor_type in the system. This is a bottleneck for multicluster system, where we want different packages to use same governor type, but with different tunables. This patch uses the infrastructure provided by earlier patch and implements init/exit routines for ondemand and conservative governors. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Add per policy governor-init/exit infrastructure

2013-03-31T23:11:34Z

Currently, there can't be multiple instances of single governor_type. If we have a multi-package system, where we have multiple instances of struct policy (per package), we can't have multiple instances of same governor. i.e. We can't have multiple instances of ondemand governor for multiple packages. Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/ governor-name/. Which again reflects that there can be only one instance of a governor_type in the system. This is a bottleneck for multicluster system, where we want different packages to use same governor type, but with different tunables. This patch is inclined towards providing this infrastructure. Because we are required to allocate governor's resources dynamically now, we must do it at policy creation and end. And so got CPUFREQ_GOV_POLICY_INIT/EXIT. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Remove unnecessary use of policy->shared_type

2013-02-02T00:29:32Z

policy->shared_type field was added only for SoCs with ACPI support: commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36 Author: Venkatesh Pallipadi Date: Wed Dec 14 15:05:00 2005 -0500 P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Many non-ACPI systems are filling this field by mistake, which makes its usage confusing. Lets clean it. Signed-off-by: Viresh Kumar Acked-by: Santosh Shilimkar Signed-off-by: Rafael J. Wysocki

cpufreq: governors: Reset tunables only for cpufreq_unregister_governor()

2013-02-02T00:29:31Z

Currently, whenever governor->governor() is called for CPUFRREQ_GOV_START event we reset few tunables of governor. Which isn't correct, as this routine is called for every cpu hot-[un]plugging event. We should actually be resetting these only when the governor module is removed and re-installed. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: governors: implement generic policy_is_shared

2013-02-01T23:01:16Z

Implement a generic helper function policy_is_shared() to replace the current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be used by code other than cpufreq governors. Suggested-by: Viresh Kumar Signed-off-by: Fabio Baltieri Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Update Documentation for cpus and related_cpus

2013-02-01T23:01:16Z

Documentation related to cpus and related_cpus is confusing and not very clear. Over that CPUFreq core has seen much changes recently. Lets update documentation and comments for cpus and related_cpus. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Sort function prototypes properly

2013-02-01T23:01:15Z

Move function prototypes to a place where they logically fit better. Signed-off-by: Borislav Petkov Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Add a get_current_driver helper

2013-02-01T23:01:15Z

Add a helper function to return cpufreq_driver->name. Signed-off-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki

cpufreq: Simplify __cpufreq_remove_dev()

2013-02-01T23:01:14Z

__cpufreq_remove_dev() is called on multiple occasions: cpufreq_driver unregister and cpu removals. Current implementation of this routine is overly complex without much need. If the cpu to be removed is the policy->cpu, we remove the policy first and add all other cpus again from policy->cpus and then finally call __cpufreq_remove_dev() again to remove the cpu to be deleted. Haahhhh.. There exist a simple solution to removal of a cpu: - Simply use the old policy structure - update its fields like: policy->cpu, etc. - notify any users of cpufreq, which depend on changing policy->cpu Hence this patch, which tries to implement the above theory. It is tested well by myself on ARM big.LITTLE TC2 SoC, which has 5 cores (2 A15 and 3 A7). Both A15's share same struct policy and all A7's share same policy structure. Signed-off-by: Viresh Kumar Tested-by: Shawn Guo Signed-off-by: Rafael J. Wysocki