summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | intel_pstate: Remove C0 trackingDirk Brandewie2014-06-021-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) introduced a regression referenced below. The issue with "lockup" after suspend that this commit was addressing is now dealt with in the suspend path. Fixes: fcb6a15c2e7e (intel_pstate: Take core C0 time into account for core busy calculation) Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581 Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121 Reported-by: Doug Smythies <dsmythies@telus.net> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | Merge tag 'drivers-for-3.16' of ↵Linus Torvalds2014-06-026-41/+119
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into next Pull ARM SoC driver changes from Olof Johansson: "SoC-near driver changes that we're merging through our tree. Mostly because they depend on other changes we have staged, but in some cases because the driver maintainers preferred that we did it this way. This contains a largeish cleanup series of the omap_l3_noc bus driver, cpuidle rework for Exynos, some reset driver conversions and a long branch of TI EDMA fixes and cleanups, with more to come next release. The TI EDMA cleanups is a shared branch with the dmaengine tree, with a handful of Davinci-specific fixes on top. After discussion at last year's KS (and some more on the mailing lists), we are here adding a drivers/soc directory. The purpose of this is to keep per-vendor shared code that's needed by different drivers but that doesn't fit into the MFD (nor drivers/platform) model. We expect to keep merging contents for this hierarchy through arm-soc so we can keep an eye on what the vendors keep adding here and not making it a free-for-all to shove in crazy stuff" * tag 'drivers-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (101 commits) cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM tty: serial: msm: Remove direct access to GSBI power: reset: keystone-reset: introduce keystone reset driver Documentation: dt: add bindings for keystone pll control controller Documentation: dt: add bindings for keystone reset driver soc: qcom: fix of_device_id table ARM: EXYNOS: Fix kernel panic when unplugging CPU1 on exynos ARM: EXYNOS: Move the driver to drivers/cpuidle directory ARM: EXYNOS: Cleanup all unneeded headers from cpuidle.c ARM: EXYNOS: Pass the AFTR callback to the platform_data ARM: EXYNOS: Move S5P_CHECK_SLEEP into pm.c ARM: EXYNOS: Move the power sequence call in the cpu_pm notifier ARM: EXYNOS: Move the AFTR state function into pm.c ARM: EXYNOS: Encapsulate the AFTR code into a function ARM: EXYNOS: Disable cpuidle for exynos5440 ARM: EXYNOS: Encapsulate boot vector code into a function for cpuidle ARM: EXYNOS: Pass wakeup mask parameter to function for cpuidle ARM: EXYNOS: Remove ifdef for scu_enable in pm ARM: EXYNOS: Move scu_enable in the cpu_pm notifier ARM: EXYNOS: Use the cpu_pm notifier for pm ...
| * | | | cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORMTomasz Figa2014-05-316-41/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently Exynos cpufreq drivers rely on globally mapped clock controller registers to configure frequency of CPU cores. This is obviously wrong and will be removed in near future, but to enable support for multi-platform builds without introducing a regression it needs to be worked around. This patch hacks the code to look for clock controller node in device tree and map its registers using of_iomap(), instead of relying on global mapping, so dependencies on platform headers are removed and the driver can compile again with multiplatform support. Signed-off-by: Tomasz Figa <t.figa@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* | | | | Merge tag 'cleanup-for-3.16' of ↵Linus Torvalds2014-06-024-12/+27
|\ \ \ \ \ | |/ / / / | | / / / | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into next Pull ARM SoC cleanups from Olof Johansson: "Cleanups for 3.16. Among these are: - a bunch of misc cleanups for Broadcom platforms, mostly housekeeping - enabling Common Clock Framework on the older s3c24xx Samsung chipsets - cleanup of the Versatile Express system controller code, moving it to syscon - power management cleanups for OMAP platforms plus a handful of other cleanups across the place" * tag 'cleanup-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (87 commits) ARM: kconfig: allow PCI support to be selected with ARCH_MULTIPLATFORM clk: samsung: fix build error ARM: vexpress: refine dependencies for new code clk: samsung: clk-s3c2410-dlck: do not use PNAME macro as it declares __initdata cpufreq: exynos: Fix the compile error ARM: S3C24XX: move debug-macro.S into the common space ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro ARM: S3C24XX: trim down debug uart handling ARM: compressed/head.S: remove s3c24xx special case ARM: EXYNOS: Remove unnecessary inclusion of cpu.h ARM: EXYNOS: Migrate Exynos specific macros from plat to mach ARM: EXYNOS: Remove exynos_subsys registration ARM: EXYNOS: Remove duplicate lines in Makefile ARM: EXYNOS: use v7_exit_coherency_flush macro for cache disabling ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core files ARM: OMAP3/4: PRM: add support of late_init call to prm_ll_ops ARM: OMAP3/OMAP4: PRM: add prm_features flags and add IO wakeup under it ARM: OMAP3/4: PRM: provide io chain reconfig function through irq setup ARM: OMAP2+: PRM: remove unnecessary cpu_is_XXX calls from prm_init / exit ARM: OMAP2+: PRCM: cleanup some header includes ...
| * | | cpufreq: exynos: Fix the compile errorJonghwan Choi2014-05-263-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to mach") which lands in samsung tree causes build breakage for cpufreq-exynos like following: drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe': drivers/cpufreq/exynos-cpufreq.c:166:2: error: implicit declaration of function 'soc_is_exynos4210' [-Werror=implicit-function-declaration] drivers/cpufreq/exynos-cpufreq.c:168:2: error: implicit declaration of function 'soc_is_exynos4212' [-Werror=implicit-function-declaration] drivers/cpufreq/exynos-cpufreq.c:168:2: error: implicit declaration of function 'soc_is_exynos4412' [-Werror=implicit-function-declaration] drivers/cpufreq/exynos-cpufreq.c:170:2: error: implicit declaration of function 'soc_is_exynos5250' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 make[2]: *** Waiting for unfinished jobs.... drivers/cpufreq/exynos4x12-cpufreq.c: In function 'exynos4x12_set_clkdiv': drivers/cpufreq/exynos4x12-cpufreq.c:118:2: error: implicit declaration of function 'soc_is_exynos4212' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [drivers/cpufreq/exynos4x12-cpufreq.o] Error 1 make[1]: *** [drivers/cpufreq] Error 2 This fixes above error with getting SoC information via of_machine_is_compatible() instead of soc_is_exynosXXXX(). Suggested-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> [kgene.kim@samsung.com: fixed typo and modified as per Viresh's suggestion] [kgene.kim@samsung.com: Rafael agreed] Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
| * | | Merge branch 'v3.16-next/clk-s3c24xx-3' into v3.16-next/cleanup-samsungKukjin Kim2014-05-261-0/+1
| |\ \ \ | | |/ / | |/| |
| | * | ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccfHeiko Stuebner2014-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The s3c24xx cpufreq driver needs to change the mpll speed and was doing this by writing raw values from a translation table into the MPLLCON register. Change this to use a regular clk_set_rate call when using the common clock framework and only write the raw value in the samsung_clock case. The s3c cpufreq driver does already aquire the mpll, so simply add a reference to struct s3c_cpufreq_config to let set_fvco access it. While struct clk is opaque the differenciation between samsung clock and common clock is kept, as the samsung-clock mpll clk does not implement a real set_rate. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* | | | Merge branches 'pm-cpufreq' and 'acpi-thermal'Rafael J. Wysocki2014-05-262-5/+17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-cpufreq: cpufreq: cpu0: drop wrong devm usage cpufreq: remove race while accessing cur_policy * acpi-thermal: ACPI / thermal: fix workqueue destroy order
| * | | | cpufreq: cpu0: drop wrong devm usageLucas Stach2014-05-201-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver is using devres managed calls incorrectly, giving the cpu0 device as first parameter instead of the cpufreq platform device. This results in resources not being freed if the cpufreq platform device is unbound, for example if probing has to be deferred for a missing regulator. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | cpufreq: remove race while accessing cur_policyBibek Basu2014-05-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While accessing cur_policy during executing events CPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS, same mutex lock is not taken, dbs_data->mutex, which leads to race and data corruption while running continious suspend resume test. This is seen with ondemand governor with suspend resume test using rtcwake. Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = ed610000 [00000028] *pgd=adf11831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: nvhost_vi CPU: 1 PID: 3243 Comm: rtcwake Not tainted 3.10.24-gf5cf9e5 #1 task: ee708040 ti: ed61c000 task.ti: ed61c000 PC is at cpufreq_governor_dbs+0x400/0x634 LR is at cpufreq_governor_dbs+0x3f8/0x634 pc : [<c05652b8>] lr : [<c05652b0>] psr: 600f0013 sp : ed61dcb0 ip : 000493e0 fp : c1cc14f0 r10: 00000000 r9 : 00000000 r8 : 00000000 r7 : eb725280 r6 : c1cc1560 r5 : eb575200 r4 : ebad7740 r3 : ee708040 r2 : ed61dca8 r1 : 001ebd24 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: ad61006a DAC: 00000015 [<c05652b8>] (cpufreq_governor_dbs+0x400/0x634) from [<c055f700>] (__cpufreq_governor+0x98/0x1b4) [<c055f700>] (__cpufreq_governor+0x98/0x1b4) from [<c0560770>] (__cpufreq_set_policy+0x250/0x320) [<c0560770>] (__cpufreq_set_policy+0x250/0x320) from [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) from [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) from [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) from [<c004b4b8>] (tegra_pm_notify+0x114/0x134) [<c004b4b8>] (tegra_pm_notify+0x114/0x134) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) from [<c00ad38c>] (enter_state+0xec/0x128) [<c00ad38c>] (enter_state+0xec/0x128) from [<c00ad400>] (pm_suspend+0x38/0xa4) [<c00ad400>] (pm_suspend+0x38/0xa4) from [<c00ac114>] (state_store+0x70/0xc0) [<c00ac114>] (state_store+0x70/0xc0) from [<c027b1e8>] (kobj_attr_store+0x14/0x20) [<c027b1e8>] (kobj_attr_store+0x14/0x20) from [<c019cd9c>] (sysfs_write_file+0x104/0x184) [<c019cd9c>] (sysfs_write_file+0x104/0x184) from [<c0143038>] (vfs_write+0xd0/0x19c) [<c0143038>] (vfs_write+0xd0/0x19c) from [<c0143414>] (SyS_write+0x4c/0x78) [<c0143414>] (SyS_write+0x4c/0x78) from [<c000f080>] (ret_fast_syscall+0x0/0x30) Code: e1a00006 eb084346 e59b0020 e5951024 (e5903028) ---[ end trace 0488523c8f6b0f9d ]--- Signed-off-by: Bibek Basu <bbasu@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | | Merge tag 'pm+acpi-3.15-rc6' of ↵Linus Torvalds2014-05-211-18/+16
|\ \ \ \ \ | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael Wysocki: "Still fixing regressions (partly by reverting commits that broke things for people), fixing other stable-candidate bugs and adding some blacklist entries for ACPI video and _OSI. Two ACPICA regression fixes (one recent and one for a 3.14 commit), a fix for an ACPI-related regression in TPM (introduced in 3.14), a revert of the ACPI AC driver conversion in 3.13 that went wrong for an unknown reason, two reverts of commits that attempted to remove an old user space interface in /proc and broke some utilities, in 3.13 too, a fix for a CPU hotplug bug in the ACPI processor driver (stable material), two (stable candidate) fixes for intel_pstate and a few new blacklist entries, mostly for systems that shipped with Windows 8. Specifics: - ACPICA fix for a stale pointer access introduced by a recent commit in the XSDT validation code from Lv Zheng. - ACPICA fix for the default value of the command line switch to favor 32-bit FADT addresses (in case there's a conflict between a 64-bit and a 32-bit address). The previous default was that the 32-bit version would take precedence and we tried to change it to the other way around and it didn't work. From Lv Zheng. - A TPM commit related to ACPI _DSM in 3.14 caused the driver to refuse to load if a specific _DSM was missing and that broke resume from system suspend on Chromebooks that require the TPM hardware to be restored to a working state during resume by the OS. Restore the old behavior to load the driver if the _DSM in question is not present, but prevent it from using the feature the _DSM is for. - ACPI AC driver conversion in 3.13 broke thermal management on at least one machine and has to be reverted. From Guenter Roeck. - Two reverts of 3.13 commits that attempted to remove the old ACPI battery interface in /proc, but turned out to break some utilities still using that interface. From Lan Tianyu. - ACPI processor driver fix to prevent acpi_processor_add() from modifying the CPU device's .offline field which leads to breakage if the initial online of the CPU fails. From Igor Mammedov. - Two intel_pstate fixes, one to take a BayTrail documentation update into account and one to avoid forcing the maximum P-state on init which causes CPU PM trouble on systems with P-states coordination when one of the CPU cores is initialized after an offline/online cycle triggered by user space. Both stable candidates, from Dirk Brandewie. - Fix for the ACPI video DMI blacklist entry for Dell Inspiron 7520 from Aaron Lu. - Two new ACPI video blacklist entries for machines shipping with Win8 that need to use native backlight so that it can be controlled in a usual way (which doesn't work otherwise due bugs in the ACPI tables) from Hans de Goede. - Two ACPI _OSI quirks for systems that need them to work correctly with Linux from Edward Lin and Hans de Goede" * tag 'pm+acpi-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / video: Revert native brightness quirk for ThinkPad T530 intel_pstate: remove setting P state to MAX on init ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. ACPI / video: correct DMI tag for Dell Inspiron 7520 intel_pstate: Set turbo VID for BayTrail ACPI / TPM: Fix resume regression on Chromebooks ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig ACPI / processor: do not mark present at boot but not onlined CPU as onlined ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus" ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX ACPI: blacklist win8 OSI for Dell Inspiron 7737 ACPI / video: Add use_native_backlight quirks for more systems ACPI: Revert "ACPI / Battery: Remove battery's proc directory" ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
| * | | | intel_pstate: remove setting P state to MAX on initDirk Brandewie2014-05-131-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: Patrick Marlier <patrick.marlier@gmail.com> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | intel_pstate: Set turbo VID for BayTrailDirk Brandewie2014-05-121-6/+15
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A documentation update exposed that there is a separate set of VID values that must be used in the turbo/boost P state range. Add enumerating and setting the correct VID for P states in the turbo range. Cc: v3.13+ <stable@vger.kernel.org> # v3.13+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | MIPS/loongson2_cpufreq: Fix CPU clock rate settingAaro Koskinen2014-05-131-2/+2
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has been unnoticed, as loongson2_cpufreq was the only place where the rate was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656 (cpufreq: introduce cpufreq_generic_get() routine) things however broke, and now loops_per_jiffy adjustments are incorrect (1000 times too long). The patch fixes this by changing cpu_clk rate to Hz. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: stable@vger.kernel.org Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: cpufreq@vger.kernel.org Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Patchwork: https://patchwork.linux-mips.org/patch/6678/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* | | cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost errorTim Gardner2014-04-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat2014-04-291-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: powernow-k6: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat2014-04-291-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: powernow-k6: Fix incorrect comparison with max_multiplerSrivatsa S. Bhat2014-04-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/endSrivatsa S. Bhat2014-04-291-12/+24
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warningKefeng Wang2014-04-221-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | cpufreq: ppc: Fix integer overflow in expressionGeert Uytterhoeven2014-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | cpufreq, powernv: Fix build failure on UPSrivatsa S. Bhat2014-04-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERODuan Jiong2014-04-211-3/+1
|/ | | | | | | | | 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>
* Merge branch 'pm-cpufreq'Rafael J. Wysocki2014-04-0835-164/+507
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * cpufreq: ppc: Remove duplicate inclusion of fsl_soc.hSachin Kamat2014-04-081-1/+0
| | | | | | | | | | | | | | | | 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>
| * cpufreq: create another field .flags in cpufreq_frequency_tableViresh Kumar2014-04-0721-139/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_tableViresh Kumar2014-04-076-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: don't print value of .driver_data from coreViresh Kumar2014-04-071-4/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: ia64: don't set .driver_data to indexViresh Kumar2014-04-071-1/+0
| | | | | | | | | | | | | | | | | | | | .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>
| * cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate idsGautham R. Shenoy2014-04-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: powernv: cpufreq driver for powernv platformVaidyanathan Srinivasan2014-04-073-0/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: at32ap: don't declare local variable as staticViresh Kumar2014-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: loongson2_cpufreq: don't declare local variable as staticViresh Kumar2014-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: unicore32: fix typo issue for 'clk'Chen Gang2014-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * cpufreq: exynos: Disable on multiplatform buildSachin Kamat2014-04-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'cpu-hotplug-3.15-rc1' of ↵Linus Torvalds2014-04-071-3/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | acpi-cpufreq: Fix CPU hotplug callback registrationSrivatsa S. Bhat2014-03-201-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge tag 'drivers-3.15' of ↵Linus Torvalds2014-04-051-1/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | Merge tag 'mvebu-drivers-3.15-2' of git://git.infradead.org/linux-mvebu into ↵Arnd Bergmann2014-03-171-1/+1
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | drivers: Enable building of Kirkwood drivers for mach-mvebuAndrew Lunn2014-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the move of kirkwood into mach-mvebu, drivers Kconfig need tweeking to allow the kirkwood specific drivers to be built. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@linaro.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Bryan Wu <cooloney@gmail.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <eduardo.valentin@ti.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* | | | Merge tag 'pm+acpi-3.15-rc1-2' of ↵Linus Torvalds2014-04-0214-39/+72
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition staticViresh Kumar2014-03-261-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}Viresh Kumar2014-03-2613-29/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | cpufreq: Make sure frequency transitions are serializedSrivatsa S. Bhat2014-03-261-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | intel_pstate: Use del_timer_sync in intel_pstate_cpu_stopDirk Brandewie2014-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | cpufreq: resume drivers before enabling governorsViresh Kumar2014-03-261-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | Merge tag 'pm+acpi-3.15-rc1' of ↵Linus Torvalds2014-04-0141-534/+315
|\ \ \ \ \ | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | | | intel_pstate: Set core to min P state during core offlineDirk Brandewie2014-03-201-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | cpufreq: Add stop CPU callback to cpufreq_driver interfaceDirk Brandewie2014-03-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | cpufreq: Remove unnecessary bracesStratos Karafotis2014-03-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud