From 217886d3f3191f1f052e987740ee2bb32a4fd316 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 13 Jun 2014 10:40:32 +0200 Subject: [PATCH 1/4] cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") was a little too quick in completely removing the dependency on the THERMAL driver. The problem is that while there are inline wrappers to turn the thermal API calls into empty functions, those do not help if the cpu-thermal driver is a loadable module and cpufreq-cpu0 is builtin. Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu code is built into the thermal module or not, we have to use a dependency on the thermal driver itself. However, if CPU_THERMAL is disabled, we don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL' construct. Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") Signed-off-by: Arnd Bergmann Tested-by: Viresh Kumar Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index e473d6555f96d..ffe350f86bca5 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -186,6 +186,8 @@ config CPU_FREQ_GOV_CONSERVATIVE config GENERIC_CPUFREQ_CPU0 tristate "Generic CPU0 cpufreq driver" depends on HAVE_CLK && OF + # if CPU_THERMAL is on and THERMAL=m, CPU0 cannot be =y: + depends on !CPU_THERMAL || THERMAL select PM_OPP help This adds a generic cpufreq driver for CPU0 frequency management. From 51d211e9c334b9eca3505f4052afa660c3e0606b Mon Sep 17 00:00:00 2001 From: Doug Smythies Date: Tue, 17 Jun 2014 13:36:10 -0700 Subject: [PATCH 2/4] intel_pstate: Correct rounding in busy calculation There was a mistake in the actual rounding portion this previous patch: f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation) such that the rounding was asymetric and incorrect. Severity: Not very serious, but can increase target pstate by one extra value. For real world work flows the issue should self correct (but I have no proof). It is the equivalent of different PID gains for positive and negative numbers. Examples: -3.000000 used to round to -4, rounds to -3 with this patch. -3.503906 used to round to -5, rounds to -4 with this patch. Fixes: f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation) Signed-off-by: Doug Smythies Cc: 3.14+ # 3.14+ Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 4e7f492ad5839..924bb2d42b1c8 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -196,10 +196,7 @@ static signed int pid_calc(struct _pid *pid, int32_t busy) pid->last_err = fp_error; result = pterm + mul_fp(pid->integral, pid->i_gain) + dterm; - if (result >= 0) - result = result + (1 << (FRAC_BITS-1)); - else - result = result - (1 << (FRAC_BITS-1)); + result = result + (1 << (FRAC_BITS-1)); return (signed int)fp_toint(result); } From fefa8ff810c5ab4c4206aed9d159c4d6fe8d4f1c Mon Sep 17 00:00:00 2001 From: Aaron Plattner Date: Wed, 18 Jun 2014 11:27:32 -0700 Subject: [PATCH 3/4] cpufreq: unlock when failing cpufreq_update_policy() Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy' label, which exits without unlocking any of the locks the function acquired earlier. This causes later calls into cpufreq to hang. Fix this by creating a new 'unlock' label and jumping to that instead. Fixes: bd0fa9bb455d ("cpufreq: Return error if ->get() failed in cpufreq_update_policy()") Link: https://devtalk.nvidia.com/default/topic/751903/kernel-3-15-and-nv-drivers-337-340-failed-to-initialize-the-nvidia-kernel-module-gtx-550-ti-/ Signed-off-by: Aaron Plattner Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index aed2b0cb83dc1..62259d27f03e6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2242,10 +2242,8 @@ int cpufreq_update_policy(unsigned int cpu) struct cpufreq_policy new_policy; int ret; - if (!policy) { - ret = -ENODEV; - goto no_policy; - } + if (!policy) + return -ENODEV; down_write(&policy->rwsem); @@ -2264,7 +2262,7 @@ int cpufreq_update_policy(unsigned int cpu) new_policy.cur = cpufreq_driver->get(cpu); if (WARN_ON(!new_policy.cur)) { ret = -EIO; - goto no_policy; + goto unlock; } if (!policy->cur) { @@ -2279,10 +2277,10 @@ int cpufreq_update_policy(unsigned int cpu) ret = cpufreq_set_policy(policy, &new_policy); +unlock: up_write(&policy->rwsem); cpufreq_cpu_put(policy); -no_policy: return ret; } EXPORT_SYMBOL(cpufreq_update_policy); From dc559aabe2d4d1c176a9b05a96519897a8197177 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Wed, 18 Jun 2014 14:37:43 +0200 Subject: [PATCH 4/4] cpuidle: mvebu: Fix the name of the states The length name of the states 2 was too long to fit in the allocated string (limited to 16 bytes). This lead to improper string displayed through sysfs. This patch shorten the name by removing the reference to Marvell and to the CPU as both are implicit. For coherency the same change have been done for the states 1. Signed-off-by: Gregory CLEMENT Signed-off-by: Rafael J. Wysocki --- drivers/cpuidle/cpuidle-armada-370-xp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpuidle/cpuidle-armada-370-xp.c b/drivers/cpuidle/cpuidle-armada-370-xp.c index 28587d0f3947d..a5fba0287bfb4 100644 --- a/drivers/cpuidle/cpuidle-armada-370-xp.c +++ b/drivers/cpuidle/cpuidle-armada-370-xp.c @@ -55,7 +55,7 @@ static struct cpuidle_driver armada_370_xp_idle_driver = { .power_usage = 50, .target_residency = 100, .flags = CPUIDLE_FLAG_TIME_VALID, - .name = "MV CPU IDLE", + .name = "Idle", .desc = "CPU power down", }, .states[2] = { @@ -65,7 +65,7 @@ static struct cpuidle_driver armada_370_xp_idle_driver = { .target_residency = 1000, .flags = CPUIDLE_FLAG_TIME_VALID | ARMADA_370_XP_FLAG_DEEP_IDLE, - .name = "MV CPU DEEP IDLE", + .name = "Deep idle", .desc = "CPU and L2 Fabric power down", }, .state_count = ARMADA_370_XP_MAX_STATES,