aboutsummaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2014-06-18intel_pstate: Improve initial busy calculationDoug Smythies
commit bf8102228a8bf053051f311e5486042fe0542894 upstream. This change makes the busy calculation using 64 bit math which prevents overflow for large values of aperf/mperf. Signed-off-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: add sample time scalingDirk Brandewie
commit c4ee841f602e5eef8eab673295c49c5b49d7732b upstream. The PID assumes that samples are of equal time, which for a deferable timers this is not true when the system goes idle. This causes the PID to take a long time to converge to the min P state and depending on the pattern of the idle load can make the P state appear stuck. The hold-off value of three sample times before using the scaling is to give a grace period for applications that have high performance requirements and spend a lot of time idle, The poster child for this behavior is the ffmpeg benchmark in the Phoronix test suite. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: Correct rounding in busy calculationDirk Brandewie
commit f0fe3cd7e12d8290c82284b5c8aee723cbd0371a upstream. Changing to fixed point math throughout the busy calculation in commit e66c1768 (Change busy calculation to use fixed point math.) Introduced some inaccuracies by rounding the busy value at two points in the calculation. This change removes roundings and moves the rounding to the output of the PID where the calculations are complete and the value returned as an integer. Fixes: e66c17683746 (intel_pstate: Change busy calculation to use fixed point math.) Reported-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: Remove C0 trackingDirk Brandewie
commit adacdf3f2b8e65aa441613cf61c4f598e9042690 upstream. 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> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: remove unneeded sample buffersDirk Brandewie
commit d37e2b764499e092ebc493d6f980827feb952e23 upstream. Remove unneeded sample buffers, intel_pstate operates on the most recent sample only. This save some memory and make the code more readable. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18cpufreq: remove race while accessing cur_policyBibek Basu
commit c5450db85b828d0c46ac8fc570fb8a51bf07ac40 upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18cpufreq: cpu0: drop wrong devm usageLucas Stach
commit e3beb0ac521d50d158a9d253373eae8421ac3998 upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: remove setting P state to MAX on initDirk Brandewie
commit d40a63c45b506b0681918d7c62a15cc9d48c8681 upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18intel_pstate: Set turbo VID for BayTrailDirk Brandewie
commit 21855ff5bcbdd075e1c99772827a84912ab083dd upstream. 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. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18MIPS/loongson2_cpufreq: Fix CPU clock rate settingAaro Koskinen
commit 8e8acb32960f42c81b1d50deac56a2c07bb6a18a upstream. 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: 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18cpufreq: Enable big.LITTLE cpufreq driver on arm64Mark Brown
There are arm64 big.LITTLE systems so enable the big.LITTLE cpufreq driver. While IKS is not available for these systems the driver is still useful since it manages clusters with shared frequencies which is the common case for these systems. Long term combining the cpufreq-cpu0 and big.LITTLE drivers may be a more sensible option but that is substantially more complex especially in the case of IKS. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 4920ab84979d8cd2eb7e3c4fefcc924efabf1cb2) Signed-off-by: Alex Shi <alex.shi@linaro.org>
2014-06-18cpufreq: unicore32: fix typo issue for 'clk'Chen Gang
commit b4ddad95020e65cfbbf9aee63d3bcdf682794ade upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18cpufreq: at32ap: don't declare local variable as staticViresh Kumar
commit 0ca97886fece9e1acd71ade4ca3a250945c8fc8b upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-18cpufreq: loongson2_cpufreq: don't declare local variable as staticViresh Kumar
commit 05ed672292dc9d37db4fafdd49baa782158cd795 upstream. 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-16exynos: driver raw read and write endian fixVictor Kamensky
Need to use endian neutral functions to read/write LE h/w registers. I.e instead of __raw_read[lw] and _raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first just read/write register with memory barrier, the second will byteswap it if host operates in BE mode. This patch covers drivers used by arndale board where all changes are trivial, sed like replacement of __raw_xxx functions with xxx_relaxed variant. Literally this sed program was used to make the change: s|__raw_readl|readl_relaxed|g s|__raw_writel|writel_relaxed|g s|__raw_readw|readw_relaxed|g s|__raw_writew|writew_relaxed|g Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
2014-04-16[CPUFREQ] EXYNOS: Add reboot notifier in cpufreq driverInderpal Singh
Because of the mismatch between frequencies set by u-boot and the kernel, the soft reboot used to hang. With reboot notifier, before rebooting, this patch switches to same frequency set by the uboot at boot time. Signed-off-by: Inderpal Singh <inderpal.singh@linaro.org> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
2014-04-15Merge branch 'tracking-armlt-juno' into integration-linaro-vexpressJon Medhurst
Conflicts: arch/arm64/kernel/debug-monitors.c
2014-04-04Merge tag 'arm64-upstream' of ↵Jon Medhurst
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux into HEAD - 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
2014-03-31cpufreq: interactive: Use generic get_cpu_idle_time() from cpufreq.cViresh Kumar
Generic version of get_cpu_idle_time() is present in cpufreq.c file. We must not replicate that for Interactive governor, rather use the same one. Lets do it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org>
2014-03-28config: Set CPU_FREQ_GOV_INTERACTIVE default nJohn Stultz
The CPU_FREQ_GOV_INTERACTIVE text states: "If in doubt, say N." however the option defaults to Y. Make this consistent by defaulting to n. Change-Id: I9625aa6b083c8ca0a99deb81c1e91b720fc76943 Reported-by: Jon Medhurst (Tixy) <tixy@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org>
2014-03-19cpufreq: interactive: fix NULL pointer dereference at sysfs opsMinsung Kim
sysfs ops for target_loads and above_hispeed_delay can be called before initializing tunables at CPUFREQ_GOV_POLICY_INIT. Create sysfs entries after initialization. Change-Id: I50356198d7629731c0d32a3066d61fe8354e0001 Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
2014-03-19cpufreq: interactive: fix compiling warningsChih-Wei Huang
The gcc warns like: cpufreq_interactive.c:745:6: warning: operation on 'ret' may be undefined [-Wsequence-point] It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf. Since sprintf(...) just return 1 (one character) in this case, ret should not changed. Just discarding the result of sprintf(...) leads to the result that the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants. Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57 Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
2014-03-19cpufreq: interactive: delete timers for GOV_STARTShridhar Rasal
Make sure that timers cpu_timer and cpu_slack_timer deactivated before addition of new. Change-Id: If31c4049606871df6f00efdc24b1d713c86a6f69 Signed-off-by: Shridhar Rasal <srasal@nvidia.com> Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
2014-03-19cpufreq: Interactive: Implement per policy instances of governorViresh Kumar
If we have a multi-package system, where we have multiple instances of struct policy (per package), currently we can't have multiple instances of same governor. i.e. We can't have multiple instances of Interactive governor for multiple packages. This is a bottleneck for multicluster system, where we want different packages to use Interactive governor, but with different tunables. This patch uses the infrastructure provided by earlier patches pushed in Mainline in v3.10-rc1/rc2 and implements per policy instances of Interactive governor. Change-Id: I70436d4a5a45c6cb6edf37f3e46d0b9fbc930982 [toddpoynor@google.com: merge with later code, minor changes] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2014-03-19cpufreq: interactive: Move definition of cpufreq_gov_interactive downwardsViresh Kumar
This moves definition of cpufreq_gov_interactive towards the bottom of file, so that we don't have to add prototype of cpufreq_governor_interactive() in the beginning of file. Change-Id: I04bd1004954eb36502c5cd7e35d3d7274cddaf95 Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2014-03-19cpufreq: interactive: Remove unnecessary cpu_online() checkViresh Kumar
Cpufreq no longer calls governor callback for offlined cpus. i.e. All policy->cpus are guaranteed to be online. Hence we don't need explicit check to see if cpu is online or not. Change-Id: I9ad85ea4addd5b4a40952e59ed730dd15e328690 Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2014-03-19cpufreq: interactive: fix show_target_loads and show_above_hispeed_delayMinsung Kim
Remove a trailing whitespace from target_loads and above_hispeed_delay. Problem happens when user-space program tried to restore parameters that saved before changing parameters. In this case was returned error(EINVAL). Change-Id: I5a74e3824602cd6f2b74651adda5ec1b627e61e9 Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
2014-03-19cpufreq: interactive: resched timer if max freq raisedLianwei Wang
When the policy max freq is raised, and before the timer is rescheduled in idle callback, the cpu freq may stuck at a lower freq. The target_freq shall be updated too, else on a high load situation, the new_freq is always equal to target_freq and which will cause freq stuck at a lower freq too. Reschedule the timer on gov limits callback. Change-Id: I6c187001ab43e859731429b64f75a74eebc37a24 Signed-off-by: Lianwei Wang <a22439@motorola.com>
2014-03-19cpufreq: interactive: fix race on cpufreq TRANSITION notifierLianwei Wang
The cpufreq TRANSTION notifier callback does not check the governor_enabled state on affected CPUS, which will case kernel panic in update_load because the policy object maybe NULL or invalid when governor_enabled is false. Change-Id: Ie0f1718124f61e2f9b5da57abc6981ada5b83908 Signed-off-by: Lianwei Wang <a22439@motorola.com>
2014-03-19cpufreq: interactive: avoid underflow on active time calculationMinsung Kim
Check for idle time delta less than elapsed time delta, avoid underflow computing active time. Change-Id: I3e4c6ef1ad794eec49ed379c0c50fa727fd6ad28 Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
2014-03-19cpufreq: interactive: reduce chance of zero time delta on load evalTodd Poynor
Reschedule load sampling timer after timestamp of sample start taken, hold spinlock across entire sequence to avoid preemption. Avoid the WARN for zero time delta in the load sampling timer function. Change-Id: Idc10a756f09141decb6df92669521a1ebf0dbc10 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: handle errors from cpufreq_frequency_table_targetTodd Poynor
Add checks for error return from cpufreq_frequency_table_target, and be less noisy on the existing call with an error check. CPU hotplug and system shutdown may cause this call to return -EINVAL. Bug: 8613560 Change-Id: Id78d8829920462c0db1c7e14e717d91740d6cb44 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: fix uninitialized spinlockMinsung Kim
Add missing spinlock init Backtrace: [<c0011ce4>] (dump_backtrace+0x0/0x10c) from [<c0662a68>] (dump_stack+0x18/0x1c) r6:00000032 r5:c0bd09ec r4:e6848000 r3:00000000 [<c0662a50>] (dump_stack+0x0/0x1c) from [<c06670b0>] (spin_dump+0x80/0x94) [<c0667030>] (spin_dump+0x0/0x94) from [<c06670f0>] (spin_bug+0x2c/0x30) r5:c08f91fc r4:c0bd09ec [<c06670c4>] (spin_bug+0x0/0x30) from [<c0245f74>] (do_raw_spin_unlock+0x88/0xcc) r5:e547bac0 r4:c0bd09ec [<c0245eec>] (do_raw_spin_unlock+0x0/0xcc) from [<c066c9cc>] (_raw_spin_unlock_irqrestore+0x14/0x40) r5:e547bac0 r4:60000013 [<c066c9b8>] (_raw_spin_unlock_irqrestore+0x0/0x40) from [<c044b884>] (store_above_hispeed_delay+0x6c/0x80) r4:c0b4cf78 r3:00000007 [<c044b818>] (store_above_hispeed_delay+0x0/0x80) from [<c0235d24>] (kobj_attr_store+0x1c/0x28) r7:e68ff000 r6:00000032 r5:e58137c0 r4:e61cde80 [<c0235d08>] (kobj_attr_store+0x0/0x28) from [<c0156b78>] (sysfs_write_file+0x104/0x184) [<c0156a74>] (sysfs_write_file+0x0/0x184) from [<c0100680>] (vfs_write+0xb0/0x140) [<c01005d0>] (vfs_write+0x0/0x140) from [<c0100900>] (sys_write+0x44/0x70) r8:00000000 r7:00000004 r6:00000032 r5:bee43c90 r4:e5600300 [<c01008bc>] (sys_write+0x0/0x70) from [<c000e400>] (ret_fast_syscall+0x0/0x30) r9:e6842000 r8:c000e584 r6:00000032 r5:bee43c90 r4:00000009 Change-Id: I80a1e0b3fecb24adba501ff44f568479deeff7fa Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
2014-03-19cpufreq: interactive: base above_hispeed_delay on target freq, not currentTodd Poynor
Time to wait should be based on the intended target speed, not the actual speed (which may be held high by another CPU). Change-Id: Ifc5bb55d06adddb9a02af90af05398a78f282272 Reported-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: fix crash on error paths in get_tokenized_dataTodd Poynor
Use separate variable for error code, free proper pointer. Change-Id: Ia83cccb195997789ac6afbf5b8761f7b278196d6 Reported-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: add io_is_busy interfaceLianwei Wang
Previously the idle time returned from get_cpu_idle_time_us included the iowait time. So the iowait time was always calculated as idle time. But now the idle time returned from get_cpu_idle_time_us does not include the iowait time anymore because of below commit which cause the iowait time always calculated as busy time: 6beea0c nohz: Fix update_ts_time_stat idle accounting Add the io_is_busy interface, as does the ondemand governor, and let the user configure the iowait time as busy or idle through the io_is_busy sysfs interface. By default, io_is_busy is disabled. [toddpoynor@google.com: minor updates] Change-Id: If7d70ff864c43bc9c8d7fd7cfc66f930d339f9b4 Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com> Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: allow arbitrary speed / delay mappingsMinsung Kim
Accept a string of delays and speeds at which to apply the delay before raising each step above hispeed. For example, "80000 1300000:200000 1500000:40000" means that the delay at or above 1GHz, until 1.3GHz is 80 msecs, the delay until 1.5GHz is 200 msecs and the delay at or above 1.5GHz is 40 msecs when hispeed_freq is 1GHz. [toddpoynor@google.com: add documentation] Change-Id: Ifeebede8b1acbdd0a53e5c6916bccbf764dc854f Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
2014-03-19cpufreq: interactive: fix race on governor start/stopLianwei Wang
There is race condition when both two cpu do CPUFREQ_GOV_STOP and one cpu do CPUFREQ_GOV_START soon. The sysfs_remove_group is not done yet on one cpu, but sysfs_create_group is called on another cpu, which cause governor start failed and then kernel panic in timer callback because the policy and cpu mask are all kfree in cpufreq driver. Replace atomic with mutex to lock the whole START/STOP sequence. Change-Id: I3762b3d44315ae021b8275aca84f5ea9147cc540 Signed-off-by: Lianwei Wang <a22439@motorola.com>
2014-03-19cpufreq: interactive: fix deadlock on spinlock in timerTodd Poynor
Need to use irqsave/restore spinlock calls to avoid a deadlock in calls from the timer. Change-Id: I15b6b590045ba1447e34ca7b5ff342723e53a605 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: don't handle transition notification if not enabledTodd Poynor
If multiple governors are in use then avoid processing frequency transition notifications for CPUs on which the interactive governor is not enabled. Change-Id: Ibd75255b921d887501a64774a8c4f62302f2d4e4 Reported-by: Francisco Franco <francisco.franco@cloudcar.com> Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: init default values at compile timeTodd Poynor
Change-Id: Ia4966e949a6c24c34fdbd4a6e522cd7c37e4108e Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: default go_hispeed_load 99%, doc updatesTodd Poynor
Update default go_hispeed_load from 85% to 99%. Recent changes to the governor now use a default target_load of 90%. go_hispeed_load should not be lower than the target load for hispeed_freq, which could lead to oscillating speed decisions. Other recent changes reduce the need to dampen speed jumps on load spikes, while input event boosts from userspace are the preferred method for anticipating load spikes with UI impacts. General update to the documentation to reflect recent changes. Change-Id: I1b92f3091f42c04b10503cd1169a943b5dfd6faf Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: fix race on timer restart on governor startTodd Poynor
Starting the governor, or restarting on a hotplugged-in CPU, can race with the timer start in idle, triggering a BUG on timer already pending. Start the timer before setting the enable flag, and use enable_sem to protect the sequence (and ensure correct order of the update to the enable flag). Delete any existing timer for safety. Change-Id: Ife77cf9fe099e8fd8543224cbf148c6722c2ffb0 Reported-by: Francisco Franco <francisco.franco@cloudcar.com> Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: fix racy timer stoppingTodd Poynor
When stopping the governor, del_timer_sync() can race against an invocation of the idle notifier callback, which has the potential to reactivate the timer. To fix this issue, a read-write semaphore is used. Multiple readers are allowed as long as pcpu->governor_enabled is true. However it can be moved to false only after taking a write semaphore which would wait for any on-going asynchronous activities to complete and prevent any more of those activities to be initiated. [toddpoynor@google.com: cosmetic and commit text changes] Change-Id: Ib51165a735d73dcf964a06754c48bdc1913e13d0 Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
2014-03-19cpufreq: interactive: fix boosting logicTodd Poynor
35a84de cpufreq: interactive: apply above_hispeed_delay to each step above hispeed caused the speed choice logic to osciallate between boosting and not boosting. Add back code to ensure speed does not drop below boost frequency while boosting. Change-Id: Id420068480fcc7f5c4989ff523e2a8d22e2f4db2 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: add timer slack to limit idle at speed > minTodd Poynor
Always use deferrable timer for load sampling. Set a non-deferrable timer to an additional slack time to allow prior to waking up from idle to drop speed when not at minimum speed. Slack value -1 avoids wakeups to drop speed. Default is 80ms. Remove the governidle module param and its timer management in idle. For platforms on which holding speed above mimum in idle costs power, use the new timer slack to select how long to wait before waking up to drop speed. Change-Id: I270b3980667e2c70a68e5bff534124b4411dbad5 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: specify duration of CPU speed boost pulseTodd Poynor
Sysfs attribute boostpulse_duration specifies the duration of boosting CPU speed in response to bootpulse events. Duration is specified in usecs, default 80ms. Change-Id: Ifd41625574891a44f1787a4e85d1e7b4f2afb52b Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: adjust load for changes in speedTodd Poynor
Add notifier for speed transitions. Keep a count of CPU active microseconds times current frequency, converted to a percentage relative to the current frequency when load is evaluated. Change-Id: I5c27adb11081c50490219784ca57cc46e97fc28c Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: remove load since last speed changeTodd Poynor
The longer-term load since last speed change isn't terribly useful, may delay recognition of dropping load, and would need forthcoming changes to adjust load for changing CPU speeds. Drop it. Change-Id: Ic3cbb0542cc3484617031787e03ed9bdd632dec1 Signed-off-by: Todd Poynor <toddpoynor@google.com>
2014-03-19cpufreq: interactive: allow arbitrary speed / target load mappingsTodd Poynor
Accept a string of target loads and speeds at which to apply the target loads, per the documentation update in this patch. For example, "85 1000000:90 1700000:99" targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. Attempt to avoid oscillations by evaluating the current speed weighted by current load against each new choice of speed, choosing a higher speed if the current load requires a higher speed. Change-Id: Ie3300206047c84eca5a26b0b63ea512e5207550e Signed-off-by: Todd Poynor <toddpoynor@google.com>