aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
Commit message (Collapse)AuthorAge
* ENGR00320349 cpufreq: imx6: increase SOC/PU voltage for VPU352MHzAnson Huang2014-06-30
| | | | | | | | | For VPU352MHz enabled, SOC/PU voltage can NOT be lower than 1250mV, as only 396M and 792M setpoint's SOC/PU voltage is lower than 1250mV and we already disable 396M setpoint, so here we just increase SOC/PU voltage for 792M setpoint when VPU352M is enabled. Signed-off-by: Anson Huang <b20788@freescale.com>
* ENGR00311992-2 cpufreq: imx6: remove pu regulator dependencyAnson Huang2014-05-08
| | | | | | | | PU regulator is not a necessary regulator for cpufreq, not all i.MX6 SoCs have PU regulator, so remove the dependency to support i.MX6SX which has NO PU regulator. Signed-off-by: Anson Huang <b20788@freescale.com>
* ENGR00279545 [MX6x:Cpufreq] Initialize mutex before driver registrationRanjani Vaidyanathan2014-04-16
| | | | | | | | | The mutex, set_cpufreq_lock, should be initialized before the driver is registered. Else if the default governor is set to performance or ondemand, the cpufreq driver will try to set the freq to the max freq supported and this will cause a crash during boot. Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
* cpufreq: imx6q: Fix clock enable balanceSascha Hauer2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | For changing the cpu frequency the i.MX6q has to be switched to some intermediate clock during the PLL reprogramming. The driver tries to be clever to keep the enable count correct but gets it wrong. If the cpufreq is increased it calls clk_disable_unprepare twice on pll2_pfd2_396m. This puts all other devices which get their clock from pll2_pfd2_396m into a nonworking state. Fix this by removing the clk enabling/disabling altogether since the clk core will do this automatically during a reparent. [shawn.guo: The driver assumes that cpu always boots with 800MHz, and the first transition on 400MHz must be entering 400MHz setpoint. But it turns out that's not always the case. In some system, cpu boots up at 400MHz and then the first transition on 400MHz will be leaving 400MHz setpoint rather than entering. In this case, the use count of pll2_pfd2_396m will be wrong. Anyway, since clock framework has been nicely handling the clk enabling during reparent, we should not need to worry about it.] Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
* ENGR00277697 cpufreq: imx: increase cpufreq during suspend/resumeAnson Huang2014-04-16
| | | | | | | | | | | | | | | During suspend/resume, when cpufreq driver try to increase voltage/freq, it needs to control I2C/SPI to communicate with external PMIC to adjust voltage, but these I2C/SPI devices may be already suspended, to avoid such scenario, we just increase cpufreq to highest setpoint before suspend. As this pm notification's updating cpu policy may work together with cpufreq governor, both of them may call set_target at same time, so we need to add mutex lock to prevent this scenario, otherwise, the clock use count will be wrong. Signed-off-by: Anson Huang <b20788@freescale.com>
* ENGR00276593-1 [iMX6x:Cpufreq]- Rename references to iMX6qRanjani Vaidyanathan2014-04-16
| | | | | | | | Change references to iMX6q to iMX6 as the CPUFREQ driver is common to all iMX6x chips. Reanme imx6q-cpufreq.c to cpufreq-imx6.c. Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
* ENGR00275974-3 [iMX6x] Add busfreq support to the driversRanjani Vaidyanathan2014-04-16
| | | | | | | | Add request_bus_freq() and release_bus_freq() calls to the various drivers to ensure that the DDR and AHB are the requested frequency before the driver starts its task. Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
* ENGR00273792-1 Cpufreq:iMX6x:Improve CPUFREQ driver.Ranjani Vaidyanathan2014-04-16
| | | | | | | | | | Add support for VDDSOC/VDDPU operating points that track the VDDARM cap to the device tree. Add the description for soc-operating-points that need to be added to the device tree files. Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
* ENGR00273073-2 cpufreq: add interactive governor for cpufreqAnson Huang2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq: interactive: New 'interactive' governor This governor is designed for latency-sensitive workloads, such as interactive user interfaces. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins. Existing governors sample CPU load at a particular rate, typically every X ms. This can lead to under-powering UI threads for the period of time during which the user begins interacting with a previously-idle system until the next sample period happens. The 'interactive' governor uses a different approach. Instead of sampling the CPU at a specified rate, the governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy from exiting idle to when the timer fires then we assume the CPU is underpowered and ramp to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed, then the governor evaluates the CPU load since the last speed adjustment, choosing the highest value between that longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to. A realtime thread is used for scaling up, giving the remaining tasks the CPU performance benefit, unlike existing governors which are more likely to schedule rampup work to occur after your performance starved tasks have completed. The tuneables for this governor are: /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic CPU load data to determine the appropriate workload. /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load The CPU load at which to ramp to max speed. Signed-off-by: Mike Chan <mike at android.com> Signed-off-by: Todd Poynor <toddpoynor at google.com> Signed-off-by: Allen Martin <amartin at nvidia.com> (submitted improvements) Signed-off-by: Axel Haslam <axelhaslam at ti.com> (submitted improvements) Signed-off-by: Anton Vorontsov <anton.vorontsov at linaro.org> Signed-off-by: Anson Huang <b20788@freescale.com>
* intel_pstate: Correct calculation of min pstate valueDirk Brandewie2014-02-13
| | | | | | | | | | | | | commit 7244cb62d96e735847dc9d08f870550df896898c upstream. The minimum pstate is supposed to be a percentage of the maximum P state available. Calculate min using max pstate and not the current max which may have been limited by the user 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>
* intel_pstate: Improve accuracy by not truncating until final resultBrennan Shacklett2014-02-13
| | | | | | | | | | | | | | | | | | | | commit d253d2a52676cfa3d89b8f0737a08ce7db665207 upstream. This patch addresses Bug 60727 (https://bugzilla.kernel.org/show_bug.cgi?id=60727) which was due to the truncation of intermediate values in the calculations, which causes the code to consistently underestimate the current cpu frequency, specifically 100% cpu utilization was truncated down to the setpoint of 97%. This patch fixes the problem by keeping the results of all intermediate calculations as fixed point numbers rather scaling them back and forth between integers and fixed point. References: https://bugzilla.kernel.org/show_bug.cgi?id=60727 Signed-off-by: Brennan Shacklett <bpshacklett@gmail.com> Acked-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>
* intel_pstate: fix no_turboSrinivas Pandruvada2014-02-13
| | | | | | | | | | | | | | commit 1ccf7a1cdafadd02e33e8f3d74370685a0600ec6 upstream. When sysfs for no_turbo is set, then also some p states in turbo regions are observed. This patch will set IDA Engage bit when no_turbo is set to explicitly disengage turbo. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-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>
* intel_pstate: Add Haswell CPU modelsNell Hardcastle2014-02-13
| | | | | | | | | | | | | | | commit 6cdcdb793791f776ea9408581b1242b636d43b37 upstream. Enable the intel_pstate driver for Haswell CPUs. One missing Ivy Bridge model (0x3E) is also included. Models referenced from tools/power/x86/turbostat/turbostat.c:has_nehalem_turbo_ratio_limit Signed-off-by: Nell Hardcastle <nell@spicious.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-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>
* intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.Dirk Brandewie2014-01-15
| | | | | | | | | | | | | | | | commit 6cbd7ee10e2842a3d1f9b60abede1c8f3d1f1130 upstream. KVM environments do not support APERF/MPERF MSRs. intel_pstate cannot operate without these registers. The previous validity checks in intel_pstate_msrs_not_valid() are insufficent in nested KVMs. References: https://bugzilla.redhat.com/show_bug.cgi?id=1046317 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>
* intel_pstate: Fail initialization if P-state information is missingRafael J. Wysocki2014-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 98a947abdd54e5de909bebadfced1696ccad30cf upstream. If pstate.current_pstate is 0 after the initial intel_pstate_get_cpu_pstates(), this means that we were unable to obtain any useful P-state information and there is no reason to continue, so free memory and return an error in that case. This fixes the following divide error occuring in a nested KVM guest: Intel P-state driver initializing. Intel pstate controlling: cpu 0 cpufreq: __cpufreq_add_dev: ->get() failed divide error: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000 RIP: 0010:[<ffffffff815c551d>] [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0 RSP: 0000:ffff88001ee03e18 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000 R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348 FS: 0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0 Stack: fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100 ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40 ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000 Call Trace: <IRQ> [<ffffffff81083e9a>] call_timer_fn+0x8a/0x310 [<ffffffff81083e15>] ? call_timer_fn+0x5/0x310 [<ffffffff815c5400>] ? pid_param_set+0x130/0x130 [<ffffffff81084354>] run_timer_softirq+0x234/0x380 [<ffffffff8107aee4>] __do_softirq+0x104/0x430 [<ffffffff8107b5fd>] irq_exit+0xcd/0xe0 [<ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60 [<ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80 <EOI> [<ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0 [<ffffffff81757719>] printk+0x67/0x69 [<ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0 [<ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20 [<ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0 [<ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210 [<ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be [<ffffffff81761e3e>] ? mutex_unlock+0xe/0x10 [<ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12 [<ffffffff8100214a>] do_one_initcall+0xfa/0x1b0 [<ffffffff8109dbf5>] ? parse_args+0x225/0x3f0 [<ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287 [<ffffffff81f638d0>] ? do_early_param+0x88/0x88 [<ffffffff8174b530>] ? rest_init+0x150/0x150 [<ffffffff8174b53e>] kernel_init+0xe/0x130 [<ffffffff8176e27c>] ret_from_fork+0x7c/0xb0 [<ffffffff8174b530>] ? rest_init+0x150/0x150 Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89 RIP [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0 RSP <ffff88001ee03e18> ---[ end trace f166110ed22cc37a ]--- Kernel panic - not syncing: Fatal exception in interrupt Reported-and-tested-by: Kashyap Chamarthy <kchamart@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: highbank-cpufreq: Enable Midway/ECX-2000Mark Langsdorf2013-12-04
| | | | | | | | | | | | | | | | commit fbbc5bfb44a22e7a8ef753a1c8dfb448d7ac8b85 upstream. Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank, so add it to the driver's compatibility list. This is a minor change that can safely be applied to the 3.10 and 3.11 stable trees. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.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>
* cpufreq / intel_pstate: Fix max_perf_pct on resumeDirk Brandewie2013-11-12
| | | | | | | | | | | | | | | commit 52e0a509e5d6f902ec26bc2a8bb02b137dc453be upstream. If the system is suspended while max_perf_pct is less than 100 percent or no_turbo set policy->{min,max} will be set incorrectly with scaled values which turn the scaled values into hard limits. References: https://bugzilla.kernel.org/show_bug.cgi?id=61241 Reported-by: Patrick Bartels <petzicus@googlemail.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>
* cpufreq: rename ignore_nice as ignore_nice_loadViresh Kumar2013-08-15
| | | | | | | | | | | | | | | | commit 6c4640c3adfd97ce10efed7c07405f52d002b9a8 upstream. This sysfs file was called ignore_nice_load earlier and commit 4d5dcc4 (cpufreq: governor: Implement per policy instances of governors) changed its name to ignore_nice by mistake. Lets get it renamed back to its original name. Reported-by: Martin von Gagern <Martin.vGagern@gmx.net> 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>
* cpufreq: loongson2: fix regression related to clock managementAaro Koskinen2013-08-15
| | | | | | | | | | | | | | | | | | commit f54fe64d14dff3df6d45a48115d248a82557811f upstream. Commit 42913c799 (MIPS: Loongson2: Use clk API instead of direct dereferences) broke the cpufreq functionality on Loongson2 boards: clk_set_rate() is called before the CPU frequency table is initialized, and therefore will always fail. Fix by moving the clk_set_rate() after the table initialization. Tested on Lemote FuLoong mini-PC. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> 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>
* cpufreq: Fix cpufreq driver module refcount balance after suspend/resumeRafael J. Wysocki2013-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2a99859932281ed6c2ecdd988855f8f6838f6743 upstream. Since cpufreq_cpu_put() called by __cpufreq_remove_dev() drops the driver module refcount, __cpufreq_remove_dev() causes that refcount to become negative for the cpufreq driver after a suspend/resume cycle. This is not the only bad thing that happens there, however, because kobject_put() should only be called for the policy kobject at this point if the CPU is not the last one for that policy. Namely, if the given CPU is the last one for that policy, the policy kobject's refcount should be 1 at this point, as set by cpufreq_add_dev_interface(), and only needs to be dropped once for the kobject to go away. This actually happens under the cpu == 1 check, so it need not be done before by cpufreq_cpu_put(). On the other hand, if the given CPU is not the last one for that policy, this means that cpufreq_add_policy_cpu() has been called at least once for that policy and cpufreq_cpu_get() has been called for it too. To balance that cpufreq_cpu_get(), we need to call cpufreq_cpu_put() in that case. Thus, to fix the described problem and keep the reference counters balanced in both cases, move the cpufreq_cpu_get() call in __cpufreq_remove_dev() to the code path executed only for CPUs that share the policy with other CPUs. Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq / intel_pstate: Change to scale off of max P-stateDirk Brandewie2013-08-04
| | | | | | | | | | | | | | | | | | | | | | | commit 2134ed4d614349b2b4e8d7bb593baa9179b8dd1e upstream. Change to using max P-state instead of max turbo P-state. This change resolves two issues. On a quiet system intel_pstate can fail to respond to a load change. On CPU SKUs that have a limited number of P-states and no turbo range intel_pstate fails to select the highest available P-state. This change is suitable for stable v3.9+ References: https://bugzilla.kernel.org/show_bug.cgi?id=59481 Reported-and-tested-by: Arjan van de Ven <arjan@linux.intel.com> Reported-and-tested-by: dsmythies@telus.net Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Revert commit 2f7021a8 to fix CPU hotplug regressionSrivatsa S. Bhat2013-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e8d05276f236ee6435e78411f62be9714e0b9377 upstream. commit 2f7021a8 "cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work()" caused a regression in CPU hotplug, because it lead to a deadlock between cpufreq governor worker thread and the CPU hotplug writer task. Lockdep splat corresponding to this deadlock is shown below: [ 60.277396] ====================================================== [ 60.277400] [ INFO: possible circular locking dependency detected ] [ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted [ 60.277411] ------------------------------------------------------- [ 60.277417] bash/2225 is trying to acquire lock: [ 60.277422] ((&(&j_cdbs->work)->work)){+.+...}, at: [<ffffffff810621b5>] flush_work+0x5/0x280 [ 60.277444] but task is already holding lock: [ 60.277449] (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60 [ 60.277465] which lock already depends on the new lock. [ 60.277472] the existing dependency chain (in reverse order) is: [ 60.277477] -> #2 (cpu_hotplug.lock){+.+.+.}: [ 60.277490] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200 [ 60.277503] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410 [ 60.277514] [<ffffffff81042cbc>] get_online_cpus+0x3c/0x60 [ 60.277522] [<ffffffff814b842a>] gov_queue_work+0x2a/0xb0 [ 60.277532] [<ffffffff814b7891>] cs_dbs_timer+0xc1/0xe0 [ 60.277543] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0 [ 60.277552] [<ffffffff81063d31>] worker_thread+0x121/0x3a0 [ 60.277560] [<ffffffff8106ae2b>] kthread+0xdb/0xe0 [ 60.277569] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0 [ 60.277580] -> #1 (&j_cdbs->timer_mutex){+.+...}: [ 60.277592] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200 [ 60.277600] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410 [ 60.277608] [<ffffffff814b785d>] cs_dbs_timer+0x8d/0xe0 [ 60.277616] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0 [ 60.277624] [<ffffffff81063d31>] worker_thread+0x121/0x3a0 [ 60.277633] [<ffffffff8106ae2b>] kthread+0xdb/0xe0 [ 60.277640] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0 [ 60.277649] -> #0 ((&(&j_cdbs->work)->work)){+.+...}: [ 60.277661] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30 [ 60.277669] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200 [ 60.277677] [<ffffffff810621ed>] flush_work+0x3d/0x280 [ 60.277685] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120 [ 60.277693] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20 [ 60.277701] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0 [ 60.277709] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20 [ 60.277719] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100 [ 60.277728] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0 [ 60.277737] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c [ 60.277747] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110 [ 60.277759] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10 [ 60.277768] [<ffffffff815a0a68>] _cpu_down+0x88/0x330 [ 60.277779] [<ffffffff815a0d46>] cpu_down+0x36/0x50 [ 60.277788] [<ffffffff815a2748>] store_online+0x98/0xd0 [ 60.277796] [<ffffffff81452a28>] dev_attr_store+0x18/0x30 [ 60.277806] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150 [ 60.277818] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0 [ 60.277826] [<ffffffff811686fc>] SyS_write+0x4c/0xa0 [ 60.277834] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5 [ 60.277842] other info that might help us debug this: [ 60.277848] Chain exists of: (&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock [ 60.277864] Possible unsafe locking scenario: [ 60.277869] CPU0 CPU1 [ 60.277873] ---- ---- [ 60.277877] lock(cpu_hotplug.lock); [ 60.277885] lock(&j_cdbs->timer_mutex); [ 60.277892] lock(cpu_hotplug.lock); [ 60.277900] lock((&(&j_cdbs->work)->work)); [ 60.277907] *** DEADLOCK *** [ 60.277915] 6 locks held by bash/2225: [ 60.277919] #0: (sb_writers#6){.+.+.+}, at: [<ffffffff81168173>] vfs_write+0x1c3/0x1f0 [ 60.277937] #1: (&buffer->mutex){+.+.+.}, at: [<ffffffff811d9e3c>] sysfs_write_file+0x3c/0x150 [ 60.277954] #2: (s_active#61){.+.+.+}, at: [<ffffffff811d9ec3>] sysfs_write_file+0xc3/0x150 [ 60.277972] #3: (x86_cpu_hotplug_driver_mutex){+.+...}, at: [<ffffffff81024cf7>] cpu_hotplug_driver_lock+0x17/0x20 [ 60.277990] #4: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff815a0d32>] cpu_down+0x22/0x50 [ 60.278007] #5: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60 [ 60.278023] stack backtrace: [ 60.278031] CPU: 3 PID: 2225 Comm: bash Not tainted 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 [ 60.278037] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011 [ 60.278042] ffffffff8204e110 ffff88014df6b9f8 ffffffff815b3d90 ffff88014df6ba38 [ 60.278055] ffffffff815b0a8d ffff880150ed3f60 ffff880150ed4770 3871c4002c8980b2 [ 60.278068] ffff880150ed4748 ffff880150ed4770 ffff880150ed3f60 ffff88014df6bb00 [ 60.278081] Call Trace: [ 60.278091] [<ffffffff815b3d90>] dump_stack+0x19/0x1b [ 60.278101] [<ffffffff815b0a8d>] print_circular_bug+0x2b6/0x2c5 [ 60.278111] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30 [ 60.278123] [<ffffffff81067e08>] ? __kernel_text_address+0x58/0x80 [ 60.278134] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200 [ 60.278142] [<ffffffff810621b5>] ? flush_work+0x5/0x280 [ 60.278151] [<ffffffff810621ed>] flush_work+0x3d/0x280 [ 60.278159] [<ffffffff810621b5>] ? flush_work+0x5/0x280 [ 60.278169] [<ffffffff810a9b14>] ? mark_held_locks+0x94/0x140 [ 60.278178] [<ffffffff81062d77>] ? __cancel_work_timer+0x77/0x120 [ 60.278188] [<ffffffff810a9cbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 60.278196] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120 [ 60.278206] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20 [ 60.278214] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0 [ 60.278225] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20 [ 60.278234] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100 [ 60.278244] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0 [ 60.278255] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c [ 60.278265] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110 [ 60.278275] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10 [ 60.278284] [<ffffffff815a0a68>] _cpu_down+0x88/0x330 [ 60.278292] [<ffffffff81024cf7>] ? cpu_hotplug_driver_lock+0x17/0x20 [ 60.278302] [<ffffffff815a0d46>] cpu_down+0x36/0x50 [ 60.278311] [<ffffffff815a2748>] store_online+0x98/0xd0 [ 60.278320] [<ffffffff81452a28>] dev_attr_store+0x18/0x30 [ 60.278329] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150 [ 60.278337] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0 [ 60.278347] [<ffffffff81185950>] ? fget_light+0x320/0x4b0 [ 60.278355] [<ffffffff811686fc>] SyS_write+0x4c/0xa0 [ 60.278364] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5 [ 60.280582] smpboot: CPU 1 is now offline The intention of that commit was to avoid warnings during CPU hotplug, which indicated that offline CPUs were getting IPIs from the cpufreq governor's work items. But the real root-cause of that problem was commit a66b2e5 (cpufreq: Preserve sysfs files across suspend/resume) because it totally skipped all the cpufreq callbacks during CPU hotplug in the suspend/resume path, and hence it never actually shut down the cpufreq governor's worker threads during CPU offline in the suspend/resume path. Reflecting back, the reason why we never suspected that commit as the root-cause earlier, was that the original issue was reported with just the halt command and nobody had brought in suspend/resume to the equation. The reason for _that_ in turn, as it turns out, is that earlier halt/shutdown was being done by disabling non-boot CPUs while tasks were frozen, just like suspend/resume.... but commit cf7df378a (reboot: migrate shutdown/reboot to boot cpu) which came somewhere along that very same time changed that logic: shutdown/halt no longer takes CPUs offline. Thus, the test-cases for reproducing the bug were vastly different and thus we went totally off the trail. Overall, it was one hell of a confusion with so many commits affecting each other and also affecting the symptoms of the problems in subtle ways. Finally, now since the original problematic commit (a66b2e5) has been completely reverted, revert this intermediate fix too (2f7021a8), to fix the CPU hotplug deadlock. Phew! Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Tested-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Revert commit a66b2e to fix suspend/resume regressionSrivatsa S. Bhat2013-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit aae760ed21cd690fe8a6db9f3a177ad55d7e12ab upstream. commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown. Ideally we should have reorganized the code to cleanly separate these two responsibilities, and skipped only the sysfs related parts during suspend/resume. Since we skipped the entire callbacks instead (which also included some CPU and cpufreq-specific critical components), cpufreq subsystem started behaving erratically after suspend/resume. So revert the commit to fix the regression. We'll revisit and address the original goal of that commit separately, since it involves quite a bit of careful code reorganization and appears to be non-trivial. (While reverting the commit, note that another commit f51e1eb (cpufreq: Fix cpufreq regression after suspend/resume) already reverted part of the original set of changes. So revert only the remaining ones). Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Fix cpufreq regression after suspend/resumeSrivatsa S. Bhat2013-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit f51e1eb63d9c28cec188337ee656a13be6980cfd upstream. Toralf Förster reported that the cpufreq ondemand governor behaves erratically (doesn't scale well) after a suspend/resume cycle. The problem was that the cpufreq subsystem's idea of the cpu frequencies differed from the actual frequencies set in the hardware after a suspend/resume cycle. Toralf bisected the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across suspend/resume). Among other (harmless) things, that commit skipped the call to cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays an important role during resume, because it is responsible for checking if the BIOS changed the cpu frequencies behind our back and resynchronize the cpufreq subsystem's knowledge of the cpu frequencies, and update them accordingly. So, restore the call to cpufreq_update_policy() in the resume path to fix the cpufreq regression. Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: fix NULL pointer deference at od_set_powersave_bias()Jacob Shin2013-06-25
| | | | | | | | | When initializing the default powersave_bias value, we need to first make sure that this policy is running the ondemand governor. Reported-and-tested-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate()Guennadi Liakhovetski2013-06-05
| | | | | | | | | | | clk_set_rate() isn't supposed to accept approximate frequencies, instead a supported frequency should be obtained from clk_round_rate() and then used to set the clock. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work()Michael Wang2013-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jiri Kosina <jkosina@suse.cz> and Borislav Petkov <bp@alien8.de> reported the warning: [ 51.616759] ------------[ cut here ]------------ [ 51.621460] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x58/0x60() [ 51.629638] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode [ 51.675581] CPU: 0 PID: 244 Comm: kworker/1:1 Tainted: G W 3.10.0-rc1+ #10 [ 51.683407] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013 [ 51.690901] Workqueue: events od_dbs_timer [ 51.695069] 0000000000000009 ffff88043a2f5b68 ffffffff8161441c ffff88043a2f5ba8 [ 51.702602] ffffffff8103e540 0000000000000033 0000000000000001 ffff88043d5f8000 [ 51.710136] 00000000ffff0ce1 0000000000000001 ffff88044fc4fc08 ffff88043a2f5bb8 [ 51.717691] Call Trace: [ 51.720191] [<ffffffff8161441c>] dump_stack+0x19/0x1b [ 51.725396] [<ffffffff8103e540>] warn_slowpath_common+0x70/0xa0 [ 51.731473] [<ffffffff8103e58a>] warn_slowpath_null+0x1a/0x20 [ 51.737378] [<ffffffff81025628>] native_smp_send_reschedule+0x58/0x60 [ 51.744013] [<ffffffff81072cfd>] wake_up_nohz_cpu+0x2d/0xa0 [ 51.749745] [<ffffffff8104f6bf>] add_timer_on+0x8f/0x110 [ 51.755214] [<ffffffff8105f6fe>] __queue_delayed_work+0x16e/0x1a0 [ 51.761470] [<ffffffff8105f251>] ? try_to_grab_pending+0xd1/0x1a0 [ 51.767724] [<ffffffff8105f78a>] mod_delayed_work_on+0x5a/0xa0 [ 51.773719] [<ffffffff814f6b5d>] gov_queue_work+0x4d/0xc0 [ 51.779271] [<ffffffff814f60cb>] od_dbs_timer+0xcb/0x170 [ 51.784734] [<ffffffff8105e75d>] process_one_work+0x1fd/0x540 [ 51.790634] [<ffffffff8105e6f2>] ? process_one_work+0x192/0x540 [ 51.796711] [<ffffffff8105ef22>] worker_thread+0x122/0x380 [ 51.802350] [<ffffffff8105ee00>] ? rescuer_thread+0x320/0x320 [ 51.808264] [<ffffffff8106634a>] kthread+0xea/0xf0 [ 51.813200] [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150 [ 51.819644] [<ffffffff81623d5c>] ret_from_fork+0x7c/0xb0 [ 51.918165] nouveau E[ DRM] GPU lockup - switching to software fbcon [ 51.930505] [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150 [ 51.936994] ---[ end trace f419538ada83b5c5 ]--- It was caused by the policy->cpus changed during the process of __gov_queue_work(), in other word, cpu offline happened. Use get/put_online_cpus() to prevent the offline from happening while __gov_queue_work() is running. [rjw: The problem has been present since recent commit 031299b (cpufreq: governors: Avoid unnecessary per cpu timer interrupts)] References: https://lkml.org/lkml/2013/6/5/88 Reported-by: Borislav Petkov <bp@alien8.de> Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-cpufreq: set current frequency based on target P-StateRoss Lagerwall2013-06-05
| | | | | | | | | | | | | | | | | | | | | | | | Commit 4b31e774 (Always set P-state on initialization) fixed bug #4634 and caused the driver to always set the target P-State at least once since the initial P-State may not be the desired one. Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur) caused a regression in this behavior. This fixes the regression by setting policy->cur based on the CPU's target frequency rather than the CPU's current reported frequency (which may be different). This means that the P-State will be set initially if the CPU's target frequency is different from the governor's target frequency. This fixes an issue where setting the default governor to performance wouldn't correctly enable turbo mode on all cores. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Reviewed-by: Len Brown <len.brown@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.8+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm+acpi-3.10-rc3' of ↵Linus Torvalds2013-05-25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI fixes from Rafael Wysocki: - Additional CPU ID for the intel_pstate driver from Dirk Brandewie. - More cpufreq fixes related to ARM big.LITTLE support and locking from Viresh Kumar. - VIA C7 cpufreq build fix from Rafał Bilski. - ACPI power management fix making it possible to use device power states regardless of the CONFIG_PM setting from Rafael J Wysocki. - New ACPI video blacklist item from Bastian Triller. * tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist cpufreq: arm_big_little_dt: Instantiate as platform_driver cpufreq: arm_big_little_dt: Register driver only if DT has valid data cpufreq / e_powersaver: Fix linker error when ACPI processor is a module cpufreq / intel_pstate: Add additional supported CPU ID cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT ACPI / PM: Allow device power states to be used for CONFIG_PM unset
| * cpufreq: arm_big_little_dt: Instantiate as platform_driverViresh Kumar2013-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when both arm_big_little_dt and cpufreq-cpu0 drivers are compiled in, arm_big_little_dt driver may try to register even if we had platform device for cpufreq-cpu0 registered. To eliminate this undesired the effect, the patch changes arm_big_little_dt driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "arm-bL-cpufreq-dt". Reported-and-tested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: arm_big_little_dt: Register driver only if DT has valid dataViresh Kumar2013-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If arm_big_little_dt driver is enabled, then it will always try to register with big LITTLE cpufreq core driver. In case DT doesn't have relevant data for cpu nodes, i.e. operating points aren't present, then we should exit early and shouldn't register with big LITTLE cpufreq core driver. Otherwise we will fail continuously from the driver->init() routine. This patch fixes this issue. Reported-and-tested-by: Jon Medhurst <tixy@linaro.org> Reviewed-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq / e_powersaver: Fix linker error when ACPI processor is a moduleRafał Bilski2013-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on i386: CONFIG_ACPI_PROCESSOR=m CONFIG_X86_E_POWERSAVER=y drivers/built-in.o: In function `eps_cpu_init.part.8': e_powersaver.c:(.text.unlikely+0x2243): undefined reference to `acpi_processor_register_performance' e_powersaver.c:(.text.unlikely+0x22a2): undefined reference to `acpi_processor_unregister_performance' e_powersaver.c:(.text.unlikely+0x246b): undefined reference to `acpi_processor_get_bios_limit' X86_E_POWERSAVER should also depend on ACPI_PROCESSOR. Signed-off-by: Rafal Bilski <rafalbilski@interia.pl> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq / intel_pstate: Add additional supported CPU IDDirk Brandewie2013-05-21
| | | | | | | | | | | | | | Add CPU ID for Ivybrigde processor. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXITViresh Kumar2013-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the rwsem lock around __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT), we get circular dependency when we call sysfs_remove_group(). ====================================================== [ INFO: possible circular locking dependency detected ] 3.9.0-rc7+ #15 Not tainted ------------------------------------------------------- cat/2387 is trying to acquire lock: (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}, at: [<c02f6179>] lock_policy_rwsem_read+0x25/0x34 but task is already holding lock: (s_active#41){++++.+}, at: [<c00f9bf7>] sysfs_read_file+0x4f/0xcc which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (s_active#41){++++.+}: [<c0055a79>] lock_acquire+0x61/0xbc [<c00fabf1>] sysfs_addrm_finish+0xc1/0x128 [<c00f9819>] sysfs_hash_and_remove+0x35/0x64 [<c00fbe6f>] remove_files.isra.0+0x1b/0x24 [<c00fbea5>] sysfs_remove_group+0x2d/0xa8 [<c02f9a0b>] cpufreq_governor_interactive+0x13b/0x35c [<c02f61df>] __cpufreq_governor+0x2b/0x8c [<c02f6579>] __cpufreq_set_policy+0xa9/0xf8 [<c02f6b75>] store_scaling_governor+0x61/0x100 [<c02f6f4d>] store+0x39/0x60 [<c00f9b81>] sysfs_write_file+0xed/0x114 [<c00b3fd1>] vfs_write+0x65/0xd8 [<c00b424b>] sys_write+0x2f/0x50 [<c000cdc1>] ret_fast_syscall+0x1/0x52 -> #0 (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}: [<c0055253>] __lock_acquire+0xef3/0x13dc [<c0055a79>] lock_acquire+0x61/0xbc [<c03ee1f5>] down_read+0x25/0x30 [<c02f6179>] lock_policy_rwsem_read+0x25/0x34 [<c02f6edd>] show+0x21/0x58 [<c00f9c0f>] sysfs_read_file+0x67/0xcc [<c00b40a7>] vfs_read+0x63/0xd8 [<c00b41fb>] sys_read+0x2f/0x50 [<c000cdc1>] ret_fast_syscall+0x1/0x52 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(s_active#41); lock(&per_cpu(cpu_policy_rwsem, cpu)); lock(s_active#41); lock(&per_cpu(cpu_policy_rwsem, cpu)); *** DEADLOCK *** 2 locks held by cat/2387: #0: (&buffer->mutex){+.+.+.}, at: [<c00f9bcd>] sysfs_read_file+0x25/0xcc #1: (s_active#41){++++.+}, at: [<c00f9bf7>] sysfs_read_file+0x4f/0xcc stack backtrace: [<c0011d55>] (unwind_backtrace+0x1/0x9c) from [<c03e9a09>] (print_circular_bug+0x19d/0x1e8) [<c03e9a09>] (print_circular_bug+0x19d/0x1e8) from [<c0055253>] (__lock_acquire+0xef3/0x13dc) [<c0055253>] (__lock_acquire+0xef3/0x13dc) from [<c0055a79>] (lock_acquire+0x61/0xbc) [<c0055a79>] (lock_acquire+0x61/0xbc) from [<c03ee1f5>] (down_read+0x25/0x30) [<c03ee1f5>] (down_read+0x25/0x30) from [<c02f6179>] (lock_policy_rwsem_read+0x25/0x34) [<c02f6179>] (lock_policy_rwsem_read+0x25/0x34) from [<c02f6edd>] (show+0x21/0x58) [<c02f6edd>] (show+0x21/0x58) from [<c00f9c0f>] (sysfs_read_file+0x67/0xcc) [<c00f9c0f>] (sysfs_read_file+0x67/0xcc) from [<c00b40a7>] (vfs_read+0x63/0xd8) [<c00b40a7>] (vfs_read+0x63/0xd8) from [<c00b41fb>] (sys_read+0x2f/0x50) [<c00b41fb>] (sys_read+0x2f/0x50) from [<c000cdc1>] (ret_fast_syscall+0x1/0x52) This lock isn't required while calling __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT). Remove it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | MIPS: Idle: Consolidate all declarations in <asm/idle.h>.Ralf Baechle2013-05-21
| | | | | | | | Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* | MIPS: Idle: Re-enable irqs at the end of r3081, au1k and loongson2 cpu_wait.Ralf Baechle2013-05-21
|/ | | | | | | | | | Without this, the WARN_ON_ONCE(irqs_disabled()); in the idle loop will be triggered. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* cpufreq: Preserve sysfs files across suspend/resumeSrivatsa S. Bhat2013-05-15
| | | | | | | | | | | | | | | | | | | | | | The file permissions of cpufreq per-cpu sysfs files are not preserved across suspend/resume because we internally go through the CPU Hotplug path which reinitializes the file permissions on CPU online. But the user is not supposed to know that we are using CPU hotplug internally within suspend/resume (IOW, the kernel should not silently wreck the user-set file permissions across a suspend cycle). Therefore, we need to preserve the file permissions as they are across suspend/resume. The simplest way to achieve that is to just not touch the sysfs files at all - ie., just ignore the CPU hotplug notifications in the suspend/resume path (_FROZEN) in the cpufreq hotplug callback. Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> Reported-by: Durgadoss R <durgadoss.r@intel.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 / intel_pstate: use vzalloc() instead of vmalloc()/memset(0)Wei Yongjun2013-05-13
| | | | | | | | | Use vzalloc() instead of vmalloc() and memset(0). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq, ondemand: Remove leftover debug lineBorislav Petkov2013-05-13
| | | | | | | | | I don't see how the virtual address of the tuners pointer would be of any help to anyone so remove it. Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / kirkwood: don't check resource with devm_ioremap_resourceWolfram Sang2013-05-12
| | | | | | | | devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / intel_pstate: remove #ifdef MODULE compile fenceDirk Brandewie2013-05-12
| | | | | | | | The driver can no longer be built as a module remove the compile fence around cpufreq tracing call. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / intel_pstate: Remove idle mode PIDDirk Brandewie2013-05-12
| | | | | | | Remove dead code from the driver. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / intel_pstate: fix ffmpeg regressionDirk Brandewie2013-05-12
| | | | | | | | | | | | | | | | | | The ffmpeg benchmark in the phoronix test suite has threads on multiple cores that rely on the progress on of threads on other cores and ping pong back and forth fast enough to make the core appear less busy than it "should" be. If the core has been at minimum p-state for a while bump the pstate up to kick the core to see if it is in this ping pong state. If the core is truly idle the p-state will be reduced at the next sample time. If the core makes more progress it will send more work to the thread bringing both threads out of the ping pong scenario and the p-state will be selected normally. This fixes a performance regression of approximately 30% Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / intel_pstate: use lowest requested max performanceDirk Brandewie2013-05-12
| | | | | | | | | | | | | | | | | There are two ways that the maximum p-state can be clamped, via a policy change and via the sysfs file. The acpi-thermal driver adjusts the p-state policy in response to thermal events. These changes override the users settings at the moment. Use the lowest of the two requested values this ensures that we will not exceed the requested pstate from either mechanism. Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq / intel_pstate: remove idle time and duration from sample and ↵Dirk Brandewie2013-05-12
| | | | | | | | | | | | | | | | | calculations Idle time is taken into account in the APERF/MPERF ratio calculation there is no reason for the driver to track it seperately. This reduces the work in the driver and makes the code more readable. Removal of the tracking of sample duration removes the possibility of the divide by zero exception when the duration is sub 1us References: https://bugzilla.kernel.org/show_bug.cgi?id=56691 Reported-by: Mike Lothian <mike@fireburn.co.uk> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Fix incorrect dependecies for ARM SA11xx driversAlexander Shiyan2013-05-12
| | | | | | | | | Kconfig dependecies for ARM SA11xx drivers are incorrect, so fix them. [rjw: Changelog] Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: ARM big LITTLE: Fix Kconfig entriesViresh Kumar2013-05-12
| | | | | | | | | | | | | This fixes usage of "depends on" and "select" options in Kconfig for ARM big LITTLE cpufreq driver. Otherwise we get these warnings: warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpufreq-cpu0: Free parent node for error casesViresh Kumar2013-05-12
| | | | | | | | | We are freeing parent node in success cases but not in failure cases. Let's do it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpufreq-cpu0: defer probe when regulator is not readyNishanth Menon2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With commit 1e4b545, regulator_get will now return -EPROBE_DEFER when the cpu0-supply node is present, but the regulator is not yet registered. It is possible for this to occur when the regulator registration by itself might be defered due to some dependent interface not yet instantiated. For example: an regulator which uses I2C and GPIO might need both systems available before proceeding, in this case, the regulator might defer it's registration. However, the cpufreq-cpu0 driver assumes that any un-successful return result is equivalent of failure. When the regulator_get returns failure other than -EPROBE_DEFER, it makes sense to assume that supply node is not present and proceed with the assumption that only clock control is necessary in the platform. With this change, we can now handle the following conditions: a) cpu0-supply binding is not present, regulator_get will return appropriate error result, resulting in cpufreq-cpu0 driver controlling just the clock. b) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver registering later once the regulator is available. c) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER, however, regulator never registers, we retry until cpufreq-cpu0 driver fails to register pointing at device tree information bug. However, in this case, the fact that cpufreq-cpu0 operates with clock only when the DT binding clearly indicates need of a supply is a bug of it's own. d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver controls both the clock and regulator Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Issue CPUFREQ_GOV_POLICY_EXIT notifier before dropping policy refcountViresh Kumar2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must call __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT) before calling cpufreq_cpu_put(data), so that policy kobject have valid fields. Otherwise, removing last online cpu of policy->cpus causes this crash for ondemand/conservative governor. [<c00fb076>] (sysfs_find_dirent+0xe/0xa8) from [<c00fb1bd>] (sysfs_get_dirent+0x21/0x58) [<c00fb1bd>] (sysfs_get_dirent+0x21/0x58) from [<c00fc259>] (sysfs_remove_group+0x85/0xbc) [<c00fc259>] (sysfs_remove_group+0x85/0xbc) from [<c02faad9>] (cpufreq_governor_dbs+0x369/0x4a0) [<c02faad9>] (cpufreq_governor_dbs+0x369/0x4a0) from [<c02f66d7>] (__cpufreq_governor+0x2b/0x8c) [<c02f66d7>] (__cpufreq_governor+0x2b/0x8c) from [<c02f6893>] (__cpufreq_remove_dev.isra.12+0x15b/0x250) [<c02f6893>] (__cpufreq_remove_dev.isra.12+0x15b/0x250) from [<c03e91c7>] (cpufreq_cpu_callback+0x2f/0x3c) [<c03e91c7>] (cpufreq_cpu_callback+0x2f/0x3c) from [<c0036fe1>] (notifier_call_chain+0x45/0x54) [<c0036fe1>] (notifier_call_chain+0x45/0x54) from [<c001e611>] (__cpu_notify+0x1d/0x34) [<c001e611>] (__cpu_notify+0x1d/0x34) from [<c03e5833>] (_cpu_down+0x63/0x1ac) [<c03e5833>] (_cpu_down+0x63/0x1ac) from [<c03e5997>] (cpu_down+0x1b/0x30) [<c03e5997>] (cpu_down+0x1b/0x30) from [<c03e60eb>] (store_online+0x27/0x54) [<c03e60eb>] (store_online+0x27/0x54) from [<c0295629>] (dev_attr_store+0x11/0x18) [<c0295629>] (dev_attr_store+0x11/0x18) from [<c00f9edd>] (sysfs_write_file+0xed/0x114) [<c00f9edd>] (sysfs_write_file+0xed/0x114) from [<c00b42a9>] (vfs_write+0x65/0xd8) [<c00b42a9>] (vfs_write+0x65/0xd8) from [<c00b4523>] (sys_write+0x2f/0x50) [<c00b4523>] (sys_write+0x2f/0x50) from [<c000cdc1>] (ret_fast_syscall+0x1/0x52) Of course this only impacted drivers which have have_governor_per_policy set to true. i.e. big LITTLE cpufreq driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-03-28 07:40:01 -0400