- 09 Feb, 2013 13 commits
-
-
Dirk Brandewie authored
Add a P-state driver for the Intel Sandy bridge processor. In cpufreq terminology this driver implements a scaling driver with an internal governor. When built into the the kernel this driver will be the preferred scaling driver for Sandy bridge processors. In addition to the interfaces provided by the cpufreq subsystem for controlling scaling drivers. The user may control the behavior of the driver via three sysfs files located in "/sys/devices/system/cpu/intel_pstate". max_perf_pct: limits the maximum P state that will be requested by the driver stated as a percentage of the avail performance. min_perf_pct: limits the minimum P state that will be requested by the driver stated as a percentage of the avail performance. no_turbo: limits the driver to selecting P states below the turbo frequency range. Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Dirk Brandewie authored
The sysfs files for cpufreq_stats are created in cpufreq_stats_create_table() called from cpufreq_stat_notifier_policy() when a policy is added to the cpu. cpufreq_stats_create_table() will not be called if the scaling driver does not export a frequency table to cpufreq. Use the same fence on tear down. Signed-off-by:
-
Dirk Brandewie authored
Scaling drivers that implement internal governors do not have governor structures assocaited with them. Only track the name of the governor associated with the CPU if the driver does not implement cpufreq_driver.setpolicy() Signed-off-by:
-
Dirk Brandewie authored
Scaling drivers that implement cpufreq_driver.setpolicy() have internal governors that do not signal changes via cpufreq_notify_transition() so the frequncy in the policy will almost certainly be different than the current frequncy. Only call cpufreq_out_of_sync() when the underlying driver implements cpufreq_driver.target() Signed-off-by:
-
Dirk Brandewie authored
Scaling drivers that implement the cpufreq_driver.setpolicy() versus the cpufreq_driver.target() interface do not set policy->cur. Normally policy->cur is set during the call to cpufreq_driver.target() when the frequnecy request is made by the governor. If the scaling driver implements cpufreq_driver.setpolicy() and cpufreq_driver.get() interfaces use cpufreq_driver.get() to retrieve the current frequency. Signed-off-by:
-
Viresh Kumar authored
cpufreq core uses two locks: - cpufreq_driver_lock: General lock for driver and cpufreq_cpu_data array. - cpu_policy_rwsemfix locking: per CPU reader-writer semaphore designed to cure all cpufreq/hotplug/workqueue/etc related lock issues. These locks were not used properly and are placed against their principle (present before their definition) at various places. This patch is an attempt to fix their use. Signed-off-by:
-
Viresh Kumar authored
On the lines of macro: lock_policy_rwsem, we can create another macro for unlock_policy_rwsem. Lets do it. Signed-off-by:
-
Viresh Kumar authored
Because the sibling cpu of any online cpu is identified very early in cpufreq_add_dev(), below code is never executed. And so can be removed. Signed-off-by:
-
Viresh Kumar authored
On multi-policy systems there is a single instance of governor for both the policies (if same governor is chosen for both policies). With the code update from following patches: 8eeed095 cpufreq: governors: Get rid of dbs_data->enable field b394058f cpufreq: governors: Reset tunables only for cpufreq_unregister_governor() We are creating/removing sysfs directory of governor for for every call to GOV_START and STOP. This would fail for multi-policy system as there is a per-policy call to START/STOP. This patch reuses the governor->initialized variable to detect total users of governor. Signed-off-by:
-
Stratos Karafotis authored
In order to avoid the calculation of up_threshold - down_differential every time that the frequency must be decreased, we replace the down_differential tuner with the adj_up_threshold which keeps the difference across multiple checks. Update the adj_up_threshold only when the up_theshold is also updated. Signed-off-by:
Stratos Karafotis <stratosk@semaphore.gr> Acked-by:
-
Viresh Kumar authored
Macro "CPUFREQ_STATDEVICE_ATTR" is defined local to cpufreq_stats.c file and is almost a copy of the generic version present in cpufreq.h file. Lets use the generic version instead. Signed-off-by:
-
Viresh Kumar authored
policy->cpu or cpus in policy->cpus can't be offline anymore. And so we don't need to check if they are online or not. Signed-off-by:
-
Shawn Guo authored
Add an imx6q-cpufreq driver for Freescale i.MX6Q SoC to handle the hardware specific frequency and voltage scaling requirements. The driver supports module build and is instantiated by the platform device/driver mechanism, so that it will not be instantiated on other platforms, as IMX is built with multiplatform support. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Reviewed-by:
-
- 05 Feb, 2013 1 commit
-
-
Viresh Kumar authored
"cpufreq" directory in policy->cpu is never created using sysfs_create_link(), but using kobject_init_and_add(). And so we shouldn't call sysfs_remove_link() for policy->cpu(). sysfs stuff for policy->cpu is automatically removed when we call kobject_put() for dying policy. Signed-off-by:
Dirk Brandewie <dirk.brandewie@gmail.com> Signed-off-by:
-
- 02 Feb, 2013 5 commits
-
-
Viresh Kumar authored
policy->shared_type field was added only for SoCs with ACPI support: commit 3b2d9942 Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> 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:
Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
Viresh Kumar authored
With following patch, we need to set policy->cpus with mask of all possible cpus and policy->related_cpus would be filled automatically by the core. commit 4948b355e90080cd5ec1e91189f65a01e4186ef2 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Tue Jan 29 14:39:08 2013 +0000 cpufreq: Simplify cpufreq_add_dev() Lets fix it for all single cluster SoCs. Signed-off-by:
-
Viresh Kumar authored
For multicore SoC's, with cores sharing clock line, we are required to set policy->cpus and policy->related_cpus with mask of cpus. With following patch, we need to set policy->cpus with mask of all possible cpus and policy->related_cpus would be filled automatically by the cpufreq core. commit 4948b355e90080cd5ec1e91189f65a01e4186ef2 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Tue Jan 29 14:39:08 2013 +0000 cpufreq: Simplify cpufreq_add_dev() Current Tegra driver fills only ->related_cpus and not ->cpus, which looks to be incorrect. Lets fix it. Signed-off-by: -
Viresh Kumar authored
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 authored
With the inclusion of following patches: 9f4eb10 cpufreq: conservative: call dbs_check_cpu only when necessary 772b4b1 cpufreq: ondemand: call dbs_check_cpu only when necessary code redundancy between the conservative and ondemand governors is introduced again, so get rid of it. [rjw: Changelog] Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Signed-off-by:
-
- 01 Feb, 2013 21 commits
-
-
Viresh Kumar authored
CPUFREQ_GOV_START/STOP are called only once for all policy->cpus and hence we don't need to adapt cpufreq_governor_dbs() routine for multiple calls. So, this patch removes dbs_data->enable field entirely. And rearrange code a bit. Signed-off-by:
-
Fabio Baltieri authored
Fix governors code to set all cpu's cdbs->cpu to the the actual cpu id and use cur_policy->cpu istead of cdbs->cpu to track current governor's leader cpu. Reported-by:
-
Fabio Baltieri authored
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 authored
SPEAr cpufreq driver supports dual core Cortex-A9 SoC's, where cpus share policy structure. Whenever we update frequency of a cpu, we must notify all policy->cpus. Signed-off-by:
-
Viresh Kumar authored
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:
-
Shawn Guo authored
As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() will be called on all the platforms to initialize cpufreq-cpu0 driver. To eliminate this undesired the effect, the patch changes cpufreq-cpu0 driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "cpufreq-cpu0". Along with the change, it also changes cpu_dev to be &pdev->dev, so that managed functions can start working, and module build gets supported too. The highbank-cpufreq driver is also updated accordingly to adapt the changes on cpufreq-cpu0. Signed-off-by:
Mark Langsdorf <mark.langsdorf@calxeda.com> Signed-off-by:
-
Fabio Baltieri authored
Drop unused arguments from dbs_timer_init and clean dbs_timer_exit and cpufreq_governor_dbs to remove non necessary special cases. Reported-by:
-
Viresh Kumar authored
Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and then checks if this CPU is already managed or not. And if it is already managed, its policy is freed. We can save all this if we somehow know that CPU is managed or not in advance. policy->related_cpus contains the list of all valid sibling CPUs of policy->cpu. We can check this to see if the current CPU is already managed. From now on, platforms don't really need to set related_cpus from their init() routines, as the same work is done by core too. If a platform driver needs to set the related_cpus mask with some additional CPUs, other than CPUs present in policy->cpus, they are free to do it, though, as we don't override anything. [rjw: Changelog] Signed-off-by:
-
Viresh Kumar authored
This reverts commit 956f339 "cpufreq: Don't use cpu removed during cpufreq_driver_unregister". With the addition of the following commit, this change/variable is not required any more: commit b9ba2725343ae57add3f324dfa5074167f48de96 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Mon Jan 14 13:23:03 2013 +0000 cpufreq: Simplify __cpufreq_remove_dev() [rjw: Subject and changelog] Signed-off-by: -
Mark Langsdorf authored
Export cpufreq helpers in OPP to make the cpufreq-core0 and highbank-cpufreq drivers loadable as modules. Signed-off-by:
Nishanth Menon <nm@ti.com> Acked-by:
-
Nishanth Menon authored
We are GPLV2 library, so be clear in the symbols exported as well. Signed-off-by:
-
Mark Langsdorf authored
Highbank processors depend on the external ECME to perform voltage management based on a requested frequency. Communication between the A9 cores and the ECME happens over the pl320 IPC channel. Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Rob Herring authored
The pl320 IPC allows for interprocessor communication between the highbank A9 and the EnergyCore Management Engine. The pl320 implements a straightforward mailbox protocol. Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
-
Mark Langsdorf authored
The highbank clock will glitch with the current code if the clock rate is reset without relocking the PLL. Program the PLL correctly to prevent glitches. Signed-off-by:
-
Rob Herring authored
Move clk setup to twd_local_timer_common_register and rely on twd_timer_rate being 0 to force calibration if there is no clock. Remove common_setup_called as it is no longer needed. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Borislav Petkov authored
Move function prototypes to a place where they logically fit better. Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
-
Borislav Petkov authored
Make it hotplug-safe and cleanup formatting. Signed-off-by:
-
Borislav Petkov authored
Check whether we've actually already loaded acpi-cpufreq before requesting it. Signed-off-by:
-
Borislav Petkov authored
Add a helper function to return cpufreq_driver->name. Signed-off-by:
-
Borislav Petkov authored
Now that the majority of x86 CPUs out there are supported by acpi-cpufreq, we want it to load first and, in the AMD case, drop to powernow-k8 only on K8s. If, however, both powernow-k8 and acpi-cpufreq are built-in, the link order matters. Correct that. Signed-off-by:
-
Matthew Garrett authored
de3ed81d ("[CPUFREQ] Change link order of x86 cpufreq modules") changed cpufreq drivers link order so that powernow-k8 gets loaded first due to earlier K8s having BIOS bugs. However, now that acpi-cpufreq supports both AMD and Intel CPUs with HW P-states, we want to load it first, so that cases where acpi-cpufreq and powernow-k8 are both built-in and powernow-k8 initializing first, can be addressed. So, make sure that even if acpi-cpufreq gets loaded first, it errors out on K8s and powernow-k8 can be loaded then successfully. Signed-off-by:
Matthew Garrett <mjg59@srcf.ucam.org> References: http://lkml.kernel.org/r/20130118162347.GA31499@srcf.ucam.orgSigned-off-by:
-
