summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2014-04-29cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost errorTim Gardner
bfa709bc823fc32ee8dd5220d1711b46078235d8 (cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs) introduced a modpost error: ERROR: "__udivdi3" [drivers/cpufreq/ppc-corenet-cpufreq.ko] undefined! make[1]: *** [__modpost] Error 1 Fix this by avoiding 64 bit integer division. gcc version 4.8.2 Fixes: bfa709bc823f (cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat
During frequency transitions, the cpufreq core takes the responsibility of invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end() for those cpufreq drivers that define the ->target_index callback but don't set the ASYNC_NOTIFICATION flag. The powernow-k7 cpufreq driver falls under this category, but this driver was invoking the _begin() and _end() APIs itself around frequency transitions, which led to double invocation of the _begin() API. The _begin API makes contending callers wait until the previous invocation is complete. Hence, the powernow-k7 driver ended up waiting on itself, leading to system hangs during boot. Fix this by removing the calls to the _begin() and _end() APIs from the powernow-k7 driver, since they rightly belong to the cpufreq core. Fixes: 12478cf0c55e (cpufreq: Make sure frequency transitions are serialized) Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29cpufreq: powernow-k6: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat
During frequency transitions, the cpufreq core takes the responsibility of invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end() for those cpufreq drivers that define the ->target_index callback but don't set the ASYNC_NOTIFICATION flag. The powernow-k6 cpufreq driver falls under this category, but this driver was invoking the _begin() and _end() APIs itself around frequency transitions, which led to double invocation of the _begin() API. The _begin API makes contending callers wait until the previous invocation is complete. Hence, the powernow-k6 driver ended up waiting on itself, leading to system hangs during boot. Fix this by removing the calls to the _begin() and _end() APIs from the powernow-k6 driver, since they rightly belong to the cpufreq core. (Note that during ->exit(), the powernow-k6 driver sets the frequency without any help from the cpufreq core. So add explicit calls to the _begin() and _end() APIs around that frequency transition alone, to take care of that special case. Also, add a missing 'break' statement there.) Fixes: 12478cf0c55e (cpufreq: Make sure frequency transitions are serialized) Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29cpufreq: powernow-k6: Fix incorrect comparison with max_multiplerSrivatsa S. Bhat
The value of 'max_multiplier' is meant to be used for comparison with clock_ratio[index].driver_data, not the index itself! Fix the code in powernow_k6_cpu_exit() that has this bug. Also, while at it, make the for-loop condition look for CPUFREQ_TABLE_END, instead of hard-coding the loop count to 8. Reported-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat
During frequency transitions, the cpufreq core takes the responsibility of invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end() for those cpufreq drivers that define the ->target_index callback but don't set the ASYNC_NOTIFICATION flag. The longhaul cpufreq driver falls under this category, but this driver was invoking the _begin() and _end() APIs itself around frequency transitions, which led to double invocation of the _begin() API. The _begin API makes contending callers wait until the previous invocation is complete. Hence, the longhaul driver ended up waiting on itself, leading to system hangs during boot. Fix this by removing the calls to the _begin() and _end() APIs from the longhaul driver, since they rightly belong to the cpufreq core. (Note that during module_exit(), the longhaul driver sets the frequency without any help from the cpufreq core. So add explicit calls to the _begin() and _end() APIs around that frequency transition alone, to take care of that special case.) Fixes: 12478cf0c55e (cpufreq: Make sure frequency transitions are serialized) Reported-and-tested-by: Meelis Roos <mroos@linux.ee> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-22cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warningKefeng Wang
When make ARCH=arm multi_v7_defconfig, we get the following warnings: warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL) To fix this, make ARM_HIGHBANK_CPUFREQ depend on ARCH_HAS_CPUFREQ and REGULATOR instead of selecting them, PM_OPP will be selected by ARCH_HAS_CPUFREQ. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21cpufreq: ppc: Fix integer overflow in expressionGeert Uytterhoeven
On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long" (NSEC_PER_SEC is a "long" constant), causing an integer overflow: drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init': drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow] Force the intermediate to be 64-bit by adding an "ULL" suffix to the constant multiplier to fix this. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21cpufreq, powernv: Fix build failure on UPSrivatsa S. Bhat
Paul Gortmaker reported the following build failure of the powernv cpufreq driver on UP configs: drivers/cpufreq/powernv-cpufreq.c:241:2: error: implicit declaration of function 'cpu_sibling_mask' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [drivers/cpufreq/powernv-cpufreq.o] Error 1 make[2]: *** [drivers/cpufreq] Error 2 make[1]: *** [drivers] Error 2 make: *** [sub-make] Error 2 The trouble here is that cpu_sibling_mask is defined only in <asm/smp.h>, and <linux/smp.h> includes <asm/smp.h> only in SMP builds. So fix this build failure by explicitly including <asm/smp.h> in the driver, so that we get the definition of cpu_sibling_mask even in UP configurations. Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERODuan Jiong
This patch fixes coccinelle error regarding usage of IS_ERR and PTR_ERR instead of PTR_ERR_OR_ZERO. Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-08Merge branch 'pm-cpufreq'Rafael J. Wysocki
* pm-cpufreq: cpufreq: ppc: Remove duplicate inclusion of fsl_soc.h cpufreq: create another field .flags in cpufreq_frequency_table cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_table cpufreq: don't print value of .driver_data from core cpufreq: ia64: don't set .driver_data to index cpufreq: powernv: Select CPUFreq related Kconfig options for powernv cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate ids cpufreq: powernv: cpufreq driver for powernv platform cpufreq: at32ap: don't declare local variable as static cpufreq: loongson2_cpufreq: don't declare local variable as static cpufreq: unicore32: fix typo issue for 'clk' cpufreq: exynos: Disable on multiplatform build
2014-04-08cpufreq: ppc: Remove duplicate inclusion of fsl_soc.hSachin Kamat
fsl_soc.h was included twice. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07Merge tag 'cpu-hotplug-3.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull CPU hotplug notifiers registration fixes from Rafael Wysocki: "The purpose of this single series of commits from Srivatsa S Bhat (with a small piece from Gautham R Shenoy) touching multiple subsystems that use CPU hotplug notifiers is to provide a way to register them that will not lead to deadlocks with CPU online/offline operations as described in the changelog of commit 93ae4f978ca7f ("CPU hotplug: Provide lockless versions of callback registration functions"). The first three commits in the series introduce the API and document it and the rest simply goes through the users of CPU hotplug notifiers and converts them to using the new method" * tag 'cpu-hotplug-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (52 commits) net/iucv/iucv.c: Fix CPU hotplug callback registration net/core/flow.c: Fix CPU hotplug callback registration mm, zswap: Fix CPU hotplug callback registration mm, vmstat: Fix CPU hotplug callback registration profile: Fix CPU hotplug callback registration trace, ring-buffer: Fix CPU hotplug callback registration xen, balloon: Fix CPU hotplug callback registration hwmon, via-cputemp: Fix CPU hotplug callback registration hwmon, coretemp: Fix CPU hotplug callback registration thermal, x86-pkg-temp: Fix CPU hotplug callback registration octeon, watchdog: Fix CPU hotplug callback registration oprofile, nmi-timer: Fix CPU hotplug callback registration intel-idle: Fix CPU hotplug callback registration clocksource, dummy-timer: Fix CPU hotplug callback registration drivers/base/topology.c: Fix CPU hotplug callback registration acpi-cpufreq: Fix CPU hotplug callback registration zsmalloc: Fix CPU hotplug callback registration scsi, fcoe: Fix CPU hotplug callback registration scsi, bnx2fc: Fix CPU hotplug callback registration scsi, bnx2i: Fix CPU hotplug callback registration ...
2014-04-07cpufreq: create another field .flags in cpufreq_frequency_tableViresh Kumar
Currently cpufreq frequency table has two fields: frequency and driver_data. driver_data is only for drivers' internal use and cpufreq core shouldn't use it at all. But with the introduction of BOOST frequencies, this assumption was broken and we started using it as a flag instead. There are two problems due to this: - It is against the description of this field, as driver's data is used by the core now. - if drivers fill it with -3 for any frequency, then those frequencies are never considered by cpufreq core as it is exactly same as value of CPUFREQ_BOOST_FREQ, i.e. ~2. The best way to get this fixed is by creating another field flags which will be used for such flags. This patch does that. Along with that various drivers need modifications due to the change of struct cpufreq_frequency_table. Reviewed-by: Gautham R Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_tableViresh Kumar
Few drivers are using kmalloc() to allocate memory for frequency tables and since we will have an additional field '.flags' in 'struct cpufreq_frequency_table', these might become unstable. Better get these fixed by replacing kmalloc() by kzalloc() instead. Along with that we also remove use of .driver_data from SPEAr driver as it doesn't use it at all. Also, writing zero to .driver_data is not required for powernow-k8 as it is already zero. Reported-and-reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: don't print value of .driver_data from coreViresh Kumar
CPUFreq core doesn't control value of .driver_data and this field is completely driver specific. This can contain any value and not only indexes. For most of the drivers, which aren't using this field, its value is zero. So, printing this from core doesn't make any sense. Don't print it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: ia64: don't set .driver_data to indexViresh Kumar
.driver_data field is only required to be filled if drivers want to preserve some data in there which they can use according to the value of .frequency. But this driver isn't using this field at all, but just setting it equal to the index value. Which isn't required. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate idsGautham R. Shenoy
The .driver_data field in the cpufreq_frequency_table was supposed to be private to the drivers. However at some later point, it was being used to indicate if the particular frequency in the table is the BOOST_FREQUENCY. After patches [1] and [2], the .driver_data is once again private to the driver. Thus we can safely use cpufreq_frequency_table.driver_data to store pstate_ids instead of having to maintain a separate array powernv_pstate_ids[] for this purpose. [1]: Subject: cpufreq: don't print value of .driver_data from core From : Viresh Kumar <viresh.kumar@ linaro.org> url : http://marc.info/?l=linux-pm&m=139601421504709&w=2 [2]: Subject: cpufreq: create another field .flags in cpufreq_frequency_table From : Viresh Kumar <viresh.kumar@linaro.org> url : http://marc.info/?l=linux-pm&m=139601416804702&w=2 Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: powernv: cpufreq driver for powernv platformVaidyanathan Srinivasan
Backend driver to dynamically set voltage and frequency on IBM POWER non-virtualized platforms. Power management SPRs are used to set the required PState. This driver works in conjunction with cpufreq governors like 'ondemand' to provide a demand based frequency and voltage setting on IBM POWER non-virtualized platforms. PState table is obtained from OPAL v3 firmware through device tree. powernv_cpufreq back-end driver would parse the relevant device-tree nodes and initialise the cpufreq subsystem on powernv platform. The code was originally written by svaidy@linux.vnet.ibm.com. Over time it was modified to accomodate bug-fixes as well as updates to the the cpu-freq core. Relevant portions of the change logs corresponding to those modifications are noted below: * The policy->cpus needs to be populated in a hotplug-invariant manner instead of using cpu_sibling_mask() which varies with cpu-hotplug. This is because the cpufreq core code copies this content into policy->related_cpus mask which should not vary on cpu-hotplug. [Authored by srivatsa.bhat@linux.vnet.ibm.com] * Create a helper routine that can return the cpu-frequency for the corresponding pstate_id. Also, cache the values of the pstate_max, pstate_min and pstate_nominal and nr_pstates in a static structure so that they can be reused in the future to perform any validations. [Authored by ego@linux.vnet.ibm.com] * Create a driver attribute named cpuinfo_nominal_freq which creates a sysfs read-only file named cpuinfo_nominal_freq. Export the frequency corresponding to the nominal_pstate through this interface. Nominal frequency is the highest non-turbo frequency for the platform. This is generally used for setting governor policies from user space for optimal energy efficiency. [Authored by ego@linux.vnet.ibm.com] * Implement a powernv_cpufreq_get(unsigned int cpu) method which will return the current operating frequency. Export this via the sysfs interface cpuinfo_cur_freq by setting powernv_cpufreq_driver.get to powernv_cpufreq_get(). [Authored by ego@linux.vnet.ibm.com] [Change log updated by ego@linux.vnet.ibm.com] Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: at32ap: don't declare local variable as staticViresh Kumar
Earlier commit: commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Thu Jan 9 20:38:43 2014 +0530 cpufreq: introduce cpufreq_generic_get() routine did some changes to driver and by mistake made cpuclk as a 'static' local variable, which wasn't actually required. Fix it. Fixes: 652ed95d5fa6 (cpufreq: introduce cpufreq_generic_get() routine) Reported-by: Alexandre Oliva <lxoliva@fsfla.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: loongson2_cpufreq: don't declare local variable as staticViresh Kumar
Earlier commit: commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Thu Jan 9 20:38:43 2014 +0530 cpufreq: introduce cpufreq_generic_get() routine did some changes to driver and by mistake made cpuclk as a 'static' local variable, which wasn't actually required. Fix it. Fixes: 652ed95d5fa6 (cpufreq: introduce cpufreq_generic_get() routine) Reported-by: Alexandre Oliva <lxoliva@fsfla.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: unicore32: fix typo issue for 'clk'Chen Gang
Need use 'clk' instead of 'mclk', which is the original removed local variable. The related original commit: "652ed95 cpufreq: introduce cpufreq_generic_get() routine" The related error with allmodconfig for unicore32: CC drivers/cpufreq/unicore2-cpufreq.o drivers/cpufreq/unicore2-cpufreq.c: In function ‘ucv2_target’: drivers/cpufreq/unicore2-cpufreq.c:48: error: ‘struct cpufreq_policy’ has no member named ‘mclk’ make[2]: *** [drivers/cpufreq/unicore2-cpufreq.o] Error 1 make[1]: *** [drivers/cpufreq] Error 2 make: *** [drivers] Error 2 Fixes: 652ed95d5fa6 (cpufreq: introduce cpufreq_generic_get() routine) Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: exynos: Disable on multiplatform buildSachin Kamat
The current exynos cpufreq drivers are not multiplatform compliant and give build errors as they refer to header files from machine directory. Work to migrate them to generic cpufreq framework is under way. Till such time disable the build on multiplatform so that other multiplatform ready features get tested. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-05Merge tag 'drivers-3.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver changes from Arnd Bergmann: "These changes are mostly for ARM specific device drivers that either don't have an upstream maintainer, or that had the maintainer ask us to pick up the changes to avoid conflicts. A large chunk of this are clock drivers (bcm281xx, exynos, versatile, shmobile), aside from that, reset controllers for STi as well as a large rework of the Marvell Orion/EBU watchdog driver are notable" * tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits) Revert "dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac." Revert "net: stmmac: Add SOCFPGA glue driver" ARM: shmobile: r8a7791: Fix SCIFA3-5 clocks ARM: STi: Add reset controller support to mach-sti Kconfig drivers: reset: stih416: add softreset controller drivers: reset: stih415: add softreset controller drivers: reset: Reset controller driver for STiH416 drivers: reset: Reset controller driver for STiH415 drivers: reset: STi SoC system configuration reset controller support dts: socfpga: Add sysmgr node so the gmac can use to reference dts: socfpga: Add support for SD/MMC on the SOCFPGA platform reset: Add optional resets and stubs ARM: shmobile: r7s72100: fix bus clock calculation Power: Reset: Generalize qnap-poweroff to work on Synology devices. dts: socfpga: Update clock entry to support multiple parents ARM: socfpga: Update socfpga_defconfig dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac. net: stmmac: Add SOCFPGA glue driver watchdog: orion_wdt: Use %pa to print 'phys_addr_t' drivers: cci: Export CCI PMU revision ...
2014-04-02Merge tag 'pm+acpi-3.15-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI and power management updates from Rafael Wysocki: "These are commits that were not quite ready when I sent the original pull request for 3.15-rc1 several days ago, but they have spent some time in linux-next since then and appear to be good to go. All of them are fixes and cleanups. Specifics: - Remaining changes from upstream ACPICA release 20140214 that introduce code to automatically serialize the execution of methods creating any named objects which really cannot be executed in parallel with each other anyway (previously ACPICA attempted to address that by aborting methods upon conflict detection, but that wasn't reliable enough and led to other issues). From Bob Moore and Lv Zheng. - intel_pstate fix to use del_timer_sync() instead of del_timer() in the exit path before freeing the timer structure from Dirk Brandewie (original patch from Thomas Gleixner). - cpufreq fix related to system resume from Viresh Kumar. - Serialization of frequency transitions in cpufreq that involve PRECHANGE and POSTCHANGE notifications to avoid ordering issues resulting from race conditions. From Srivatsa S Bhat and Viresh Kumar. - Revert of an ACPI processor driver change that was based on a specific interpretation of the ACPI spec which may not be correct (the relevant part of the spec appears to be incomplete). From Hanjun Guo. - Runtime PM core cleanups and documentation updates from Geert Uytterhoeven. - PNP core cleanup from Michael Opdenacker" * tag 'pm+acpi-3.15-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition static cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end} cpufreq: Make sure frequency transitions are serialized intel_pstate: Use del_timer_sync in intel_pstate_cpu_stop cpufreq: resume drivers before enabling governors PM / Runtime: Spelling s/competing/completing/ PM / Runtime: s/foo_process_requests/foo_process_next_request/ PM / Runtime: GENERIC_SUBSYS_PM_OPS is gone PM / Runtime: Correct documented return values for generic PM callbacks PM / Runtime: Split line longer than 80 characters PM / Runtime: dev_pm_info.runtime_error is signed Revert "ACPI / processor: Make it possible to get APIC ID via GIC" ACPICA: Enable auto-serialization as a default kernel behavior. ACPICA: Ignore sync_level for methods that have been auto-serialized. ACPICA: Add additional named objects for the auto-serialize method scan. ACPICA: Add auto-serialization support for ill-behaved control methods. ACPICA: Remove global option to serialize all control methods. PNP: remove deprecated IRQF_DISABLED
2014-04-01Merge tag 'pm+acpi-3.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management updates from Rafael Wysocki: "The majority of this material spent some time in linux-next, some of it even several weeks. There are a few relatively fresh commits in it, but they are mostly fixes and simple cleanups. ACPI took the lead this time, both in terms of the number of commits and the number of modified lines of code, cpufreq follows and there are a few changes in the PM core and in cpuidle too. A new feature that already got some LWN.net's attention is the device PM QoS extension allowing latency tolerance requirements to be propagated from leaf devices to their ancestors with hardware interfaces for specifying latency tolerance. That should help systems with hardware-driven power management to avoid going too far with it in cases when there are latency tolerance constraints. There also are some significant changes in the ACPI core related to the way in which hotplug notifications are handled. They affect PCI hotplug (ACPIPHP) and the ACPI dock station code too. The bottom line is that all those notification now go through the root notify handler and are propagated to the interested subsystems by means of callbacks instead of having to install a notify handler for each device object that we can potentially get hotplug notifications for. In addition to that ACPICA will now advertise "Windows 2013" compatibility for _OSI, because some systems out there don't work correctly if that is not done (some of them don't even boot). On the system suspend side of things, all of the device suspend and resume callbacks, except for ->prepare() and ->complete(), are now going to be executed asynchronously as that turns out to speed up system suspend and resume on some platforms quite significantly and we have a few more optimizations in that area. Apart from that, there are some new device IDs and fixes and cleanups all over. In particular, the system suspend and resume handling by cpufreq should be improved and the cpuidle menu governor should be a bit more robust now. Specifics: - Device PM QoS support for latency tolerance constraints on systems with hardware interfaces allowing such constraints to be specified. That is necessary to prevent hardware-driven power management from becoming overly aggressive on some systems and to prevent power management features leading to excessive latencies from being used in some cases. - Consolidation of the handling of ACPI hotplug notifications for device objects. This causes all device hotplug notifications to go through the root notify handler (that was executed for all of them anyway before) that propagates them to individual subsystems, if necessary, by executing callbacks provided by those subsystems (those callbacks are associated with struct acpi_device objects during device enumeration). As a result, the code in question becomes both smaller in size and more straightforward and all of those changes should not affect users. - ACPICA update, including fixes related to the handling of _PRT in cases when it is broken and the addition of "Windows 2013" to the list of supported "features" for _OSI (which is necessary to support systems that work incorrectly or don't even boot without it). Changes from Bob Moore and Lv Zheng. - Consolidation of ACPI _OST handling from Jiang Liu. - ACPI battery and AC fixes allowing unusual system configurations to be handled by that code from Alexander Mezin. - New device IDs for the ACPI LPSS driver from Chiau Ee Chew. - ACPI fan and thermal optimizations related to system suspend and resume from Aaron Lu. - Cleanups related to ACPI video from Jean Delvare. - Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan Tianyu, Paul Bolle, Tomasz Nowicki. - Intel RAPL (Running Average Power Limits) driver cleanups from Jacob Pan. - intel_pstate fixes and cleanups from Dirk Brandewie. - cpufreq fixes related to system suspend/resume handling from Viresh Kumar. - cpufreq core fixes and cleanups from Viresh Kumar, Stratos Karafotis, Saravana Kannan, Rashika Kheria, Joe Perches. - cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob Herring. - cpuidle fixes related to the menu governor from Tuukka Tikkanen. - cpuidle fix related to coupled CPUs handling from Paul Burton. - Asynchronous execution of all device suspend and resume callbacks, except for ->prepare and ->complete, during system suspend and resume from Chuansheng Liu. - Delayed resuming of runtime-suspended devices during system suspend for the PCI bus type and ACPI PM domain. - New set of PM helper routines to allow device runtime PM callbacks to be used during system suspend and resume more easily from Ulf Hansson. - Assorted fixes and cleanups in the PM core from Geert Uytterhoeven, Prabhakar Lad, Philipp Zabel, Rashika Kheria, Sebastian Capella. - devfreq fix from Saravana Kannan" * tag 'pm+acpi-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits) PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs PM / sleep: Correct whitespace errors in <linux/pm.h> intel_pstate: Set core to min P state during core offline cpufreq: Add stop CPU callback to cpufreq_driver interface cpufreq: Remove unnecessary braces cpufreq: Fix checkpatch errors and warnings cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs MAINTAINERS: Reorder maintainer addresses for PM and ACPI PM / Runtime: Update runtime_idle() documentation for return value meaning video / output: Drop display output class support fujitsu-laptop: Drop unneeded include acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL ACPI / gpu / drm: Stop selecting VIDEO_OUTPUT_CONTROL ACPI / video: fix ACPI_VIDEO dependencies cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE} cpufreq: Do not allow ->setpolicy drivers to provide ->target cpufreq: arm_big_little: set 'physical_cluster' for each CPU cpufreq: arm_big_little: make vexpress driver depend on bL core driver ACPI / button: Add ACPI Button event via netlink routine ACPI: Remove duplicate definitions of PREFIX ...
2014-04-01Merge branch 'timers-nohz-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer updates from Ingo Molnar: "The main purpose is to fix a full dynticks bug related to virtualization, where steal time accounting appears to be zero in /proc/stat even after a few seconds of competing guests running busy loops in a same host CPU. It's not a regression though as it was there since the beginning. The other commits are preparatory work to fix the bug and various cleanups" * 'timers-nohz-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: arch: Remove stub cputime.h headers sched: Remove needless round trip nsecs <-> tick conversion of steal time cputime: Fix jiffies based cputime assumption on steal accounting cputime: Bring cputime -> nsecs conversion cputime: Default implementation of nsecs -> cputime conversion cputime: Fix nsecs_to_cputime() return type cast
2014-03-31Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull ARM64 updates from Catalin Marinas: - KGDB support for arm64 - PCI I/O space extended to 16M (in preparation of PCIe support patches) - Dropping ZONE_DMA32 in favour of ZONE_DMA (we only need one for the time being), together with swiotlb late initialisation to correctly setup the bounce buffer - DMA API cache maintenance support (not all ARMv8 platforms have hardware cache coherency) - Crypto extensions advertising via ELF_HWCAP2 for compat user space - Perf support for dwarf unwinding in compat mode - asm/tlb.h converted to the generic mmu_gather code - asm-generic rwsem implementation - Code clean-up * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (42 commits) arm64: Remove pgprot_dmacoherent() arm64: Support DMA_ATTR_WRITE_COMBINE arm64: Implement custom mmap functions for dma mapping arm64: Fix __range_ok macro arm64: Fix duplicated Kconfig entries arm64: mm: Route pmd thp functions through pte equivalents arm64: rwsem: use asm-generic rwsem implementation asm-generic: rwsem: de-PPCify rwsem.h arm64: enable generic CPU feature modalias matching for this architecture arm64: smp: make local symbol static arm64: debug: make local symbols static ARM64: perf: support dwarf unwinding in compat mode ARM64: perf: add support for frame pointer unwinding in compat mode ARM64: perf: add support for perf registers API arm64: Add boot time configuration of Intermediate Physical Address size arm64: Do not synchronise I and D caches for special ptes arm64: Make DMA coherent and strongly ordered mappings not executable arm64: barriers: add dmb barrier arm64: topology: Implement basic CPU topology support arm64: advertise ARMv8 extensions to 32-bit compat ELF binaries ...
2014-03-26cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition staticViresh Kumar
cpufreq_notify_transition() and cpufreq_notify_post_transition() shouldn't be called directly by cpufreq drivers anymore and so these should be marked static. Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}Viresh Kumar
CPUFreq core has new infrastructure that would guarantee serialized calls to target() or target_index() callbacks. These are called cpufreq_freq_transition_begin() and cpufreq_freq_transition_end(). This patch converts existing drivers to use these new set of routines. Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: Make sure frequency transitions are serializedSrivatsa S. Bhat
Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers should strictly alternate, thereby preventing two different sets of PRECHANGE or POSTCHANGE notifiers from interleaving arbitrarily. The following examples illustrate why this is important: Scenario 1: ----------- A thread reading the value of cpuinfo_cur_freq, will call __cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition() The ondemand governor can decide to change the frequency of the CPU at the same time and hence it can end up sending the notifications via ->target(). If the notifiers are not serialized, the following sequence can occur: - PRECHANGE Notification for freq A (from cpuinfo_cur_freq) - PRECHANGE Notification for freq B (from target()) - Freq changed by target() to B - POSTCHANGE Notification for freq B - POSTCHANGE Notification for freq A We can see from the above that the last POSTCHANGE Notification happens for freq A but the hardware is set to run at freq B. Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback() in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the loops_per_jiffy calculations will get messed up. Scenario 2: ----------- The governor calls __cpufreq_driver_target() to change the frequency. At the same time, if we change scaling_{min|max}_freq from sysfs, it will end up calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call __cpufreq_driver_target(). And hence we end up issuing concurrent calls to ->target(). Typically, platforms have the following logic in their ->target() routines: (Eg: cpufreq-cpu0, omap, exynos, etc) A. If new freq is more than old: Increase voltage B. Change freq C. If new freq is less than old: decrease voltage Now, if the two concurrent calls to ->target() are X and Y, where X is trying to increase the freq and Y is trying to decrease it, we get the following race condition: X.A: voltage gets increased for larger freq Y.A: nothing happens Y.B: freq gets decreased Y.C: voltage gets decreased X.B: freq gets increased X.C: nothing happens Thus we can end up setting a freq which is not supported by the voltage we have set. That will probably make the clock to the CPU unstable and the system might not work properly anymore. This patch introduces a set of synchronization primitives to serialize frequency transitions, which are to be used as shown below: cpufreq_freq_transition_begin(); //Perform the frequency change cpufreq_freq_transition_end(); The _begin() call sends the PRECHANGE notification whereas the _end() call sends the POSTCHANGE notification. Also, all the necessary synchronization is handled within these calls. In particular, even drivers which set the ASYNC_NOTIFICATION flag can also use these APIs for performing frequency transitions (ie., you can call _begin() from one task, and call the corresponding _end() from a different task). The actual synchronization underneath is not that complicated: The key challenge is to allow drivers to begin the transition from one thread and end it in a completely different thread (this is to enable drivers that do asynchronous POSTCHANGE notification from bottom-halves, to also use the same interface). To achieve this, a 'transition_ongoing' flag, a 'transition_lock' spinlock and a wait-queue are added per-policy. The flag and the wait-queue are used in conjunction to create an "uninterrupted flow" from _begin() to _end(). The spinlock is used to ensure that only one such "flow" is in flight at any given time. Put together, this provides us all the necessary synchronization. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26intel_pstate: Use del_timer_sync in intel_pstate_cpu_stopDirk Brandewie
Ensure that no timer callback is running since we are about to free the timer structure. We cannot guarantee that the call back is called on the CPU where the timer is running. Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: resume drivers before enabling governorsViresh Kumar
During suspend, we first stop governors and then suspend cpufreq drivers and resume must be exactly opposite of that. i.e. resume drivers first and then start governors. But the current code in resume enables governors first and then resume drivers. Fix it be changing code sequence there. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20acpi-cpufreq: Fix CPU hotplug callback registrationSrivatsa S. Bhat
Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(&foobar_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Instead, the correct and race-free way of performing the callback registration is: cpu_notifier_register_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* Note the use of the double underscored version of the API */ __register_cpu_notifier(&foobar_cpu_notifier); cpu_notifier_register_done(); Fix the acpi-cpufreq code by using this latter form of callback registration. Cc: Ingo Molnar <mingo@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20intel_pstate: Set core to min P state during core offlineDirk Brandewie
Change to use the new ->stop_cpu() callback to do clean up during CPU hotplug. The requested P state for an offline core will be used by the hardware coordination function to select the package P state. If the core is under load when it is offlined it will fix the package P state floor to the requested P state of offline core. Reported-by: Patrick Marlier <patrick.marlier@gmail.com> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20cpufreq: Add stop CPU callback to cpufreq_driver interfaceDirk Brandewie
This callback allows the driver to do clean up before the CPU is completely down and its state cannot be modified. This is used by the intel_pstate driver to reduce the requested P state prior to the core going away. This is required because the requested P state of the offline core is used to select the package P state. This effectively sets the floor package P state to the requested P state on the offline core. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> [rjw: Minor modifications] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20cpufreq: Remove unnecessary bracesStratos Karafotis
Remove unnecessary braces from a single statement. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20cpufreq: Fix checkpatch errors and warningsStratos Karafotis
Fix 2 checkpatch errors about using assignment in if condition, 1 checkpatch error about a required space after comma and 3 warnings about line over 80 characters. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCsZhuoyu Zhang
According to the data provided by HW Team, at least 12 internal platform clock cycles are required to stabilize a DFS clock switch on FSL e500mc Socs. This patch replaces the CPUFREQ_ETERNAL with appropriate HW clock transition latency to make DFS governors work normally on Freescale e500mc boards. Signed-off-by: Zhuoyu Zhang <Zhuoyu.Zhang@freescale.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-19cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}Viresh Kumar
Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have not been used for some time, so remove them to clean up code a bit. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-19cpufreq: Do not allow ->setpolicy drivers to provide ->targetRafael J. Wysocki
cpufreq drivers that provide the ->setpolicy() callback are supposed to have integrated governors, so they don't need to set ->target() or ->target_index() and may confuse the core if any of these callbacks is present. For this reason, add a check preventing ->setpolicy cpufreq drivers from registering if they have non-NULL ->target or ->target_index. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2014-03-19cpufreq: arm_big_little: set 'physical_cluster' for each CPUviresh kumar
We have a per-CPU variable for managing which cluster a CPU belongs to. Currently, physical_cluster is set for policy->cpu only which leads to the following on some SoC's: - There are two clusters: - Cluster 0 has four ARM Cortex A7 CPUs (slower ones): 0,1,2,3 - Cluster 1 has four ARM Cortex A15 CPUs (faster ones): 4,5,6,7 - CPUs are booted in order 0,1..7 and so initially policy->cpu for A7 cluster would be 0 and for A15 cluster would be 4. - Now CPU4 (i.e. A15_0) is hotplugged out and so policy->cpu for A15 cluster becomes 5 (i.e. A15_1). - But physical cluster is only set for CPU0 and CPU4 in ARM big LITTLE driver and isn't updated. - Now freq change request comes for A15 cluster and we would try to update freq of physical_cluster of CPU5, i.e. A15_1. And it is currently set to zero (default value of uninitialized global variables). - And so we actually try to change freq of A7 cluster instead of A15. - This also results in kernel crash as sometimes we might request freq above A7's limit and CPU may behave badly.. Fix this by initializing physical_cluster for all CPUs of a policy. Based on previous work by Xin Wang. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-19cpufreq: arm_big_little: make vexpress driver depend on bL core driverviresh kumar
Currently vexpress big LITTLE driver selects ARM_BIG_LITTLE_CPUFREQ, so if CONFIG_BIG_LITTLE isn't enabled and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ is enabled, we get the following build warnings: warning: (ARM_VEXPRESS_SPC_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && (ARM || ARM64) && ARM && BIG_LITTLE && ARM_CPU_TOPOLOGY && HAVE_CLK) To fix this, make ARM_VEXPRESS_SPC_CPUFREQ depend on ARM_BIG_LITTLE_CPUFREQ instead of selecting it. This also moves the entry for ARM_VEXPRESS_SPC_CPUFREQ along with other big LITTLE config entries. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-17Merge back earlier 'pm-cpufreq' material.Rafael J. Wysocki
2014-03-17Merge tag 'mvebu-drivers-3.15-2' of git://git.infradead.org/linux-mvebu into ↵Arnd Bergmann
next/drivers Merge "mvebu drivers for v3.15" from Jason Cooper: pull request #1: - mvebu mbus - use of_find_matching_node_and_match - rtc - use PTR_ERR_OR_ZERO in isl12057 - work around issue in mv where date returned is 2038 - kirkwood -> mach-mvebu - various Kconfig oneliners to allow building kirkwood in -mvebu/ pull request #2: - reset - re-use qnap-poweroff driver for Synology NASs * tag 'mvebu-drivers-3.15-2' of git://git.infradead.org/linux-mvebu: Power: Reset: Generalize qnap-poweroff to work on Synology devices. drivers: Enable building of Kirkwood drivers for mach-mvebu rtc: mv: reset date if after year 2038 rtc: isl12057: use PTR_ERR_OR_ZERO to fix coccinelle warnings bus: mvebu-mbus: make use of of_find_matching_node_and_match Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-13cputime: Default implementation of nsecs -> cputime conversionFrederic Weisbecker
The architectures that override cputime_t (s390, ppc) don't provide any version of nsecs_to_cputime(). Indeed this cputime_t implementation by backend only happens when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y under which the core code doesn't make any use of nsecs_to_cputime(). At least for now. We are going to make a broader use of it so lets provide a default version with a per usecs granularity. It should be good enough for most usecases. Cc: Ingo Molnar <mingo@kernel.org> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
2014-03-13cpufreq: Skip current frequency initialization for ->setpolicy driversRafael J. Wysocki
After commit da60ce9f2fac (cpufreq: call cpufreq_driver->get() after calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled by intel_pstate, because that driver may return 0 from its ->get() callback if it has not run long enough to collect enough samples on the given CPU. That didn't happen before commit da60ce9f2fac which added policy->cur initialization to __cpufreq_add_dev() to help reduce code duplication in other cpufreq drivers. However, the code added by commit da60ce9f2fac need not be executed for cpufreq drivers having the ->setpolicy callback defined, because the subsequent invocation of cpufreq_set_policy() will use that callback to initialize the policy anyway and it doesn't need policy->cur to be initialized upfront. The analogous code in cpufreq_update_policy() is also unnecessary for cpufreq drivers having ->setpolicy set and may be skipped for them as well. Since intel_pstate provides ->setpolicy, skipping the upfront policy->cur initialization for cpufreq drivers with that callback set will cover intel_pstate and the problem it's been having after commit da60ce9f2fac will be addressed. Fixes: da60ce9f2fac (cpufreq: call cpufreq_driver->get() after calling ->init()) References: https://bugzilla.kernel.org/show_bug.cgi?id=71931 Reported-and-tested-by: Patrik Lundquist <patrik.lundquist@gmail.com> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-12cpufreq: SPEAr: Instantiate as platform_driverViresh Kumar
As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when SPEAr cpufreq driver is enabled on a kernel booted on a non-SPEAr board, we will get following boot time error: spear_cpufreq: Invalid cpufreq_tbl To eliminate this undesired the effect, the patch changes SPEAr driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "spear-cpufreq". This patch also creates platform node for SPEAr13xx boards. Reported-by: Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-12cpufreq: Remove unnecessary variable/parameter 'frozen'Viresh Kumar
We have used 'frozen' variable/function parameter at many places to distinguish between CPU offline/online on suspend/resume vs sysfs removals. We now have another variable cpufreq_suspended which can be used in these cases, so we can get rid of all those variables or function parameters. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-12cpufreq: Remove cpufreq_generic_exit()Viresh Kumar
cpufreq_generic_exit() is empty now and can be deleted. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-12cpufreq: add 'freq_table' in struct cpufreq_policyViresh Kumar
freq table is not per CPU but per policy, so it makes more sense to keep it within struct cpufreq_policy instead of a per-cpu variable. This patch does it. Over that, there is no need to set policy->freq_table to NULL in ->exit(), as policy structure is going to be freed soon. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>