linux-toradex.git/drivers/cpufreq, branch v3.13.9

intel_pstate: Add support for Baytrail turbo P states

2014-03-24T04:44:19+00:00

commit 61d8d2abc15e9232c3914c55502b73e559366583 upstream.

A documentation update exposed the existance of the turbo ratio
register. Update baytrail support to use the turbo range.

Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Add setting voltage value for baytrail P states.

2014-03-24T04:44:19+00:00

commit 007bea098b869945a462420a1f9d442ff169f722 upstream.

Baytrail requires setting P state and voltage pairs when adjusting the
requested P state.  Add function for retrieving the valid voltage
values and modify *_set_pstate() functions to caluclate the
appropriate voltage for the requested P state.

Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Skip current frequency initialization for ->setpolicy drivers

2014-03-24T04:44:12+00:00

commit 2ed99e39cb9392312c100d9da591c20641c64d12 upstream.

After commit da60ce9f2fac (cpufreq: call cpufreq_driver->get() after
calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
by intel_pstate, because that driver may return 0 from its ->get()
callback if it has not run long enough to collect enough samples on the
given CPU.  That didn't happen before commit da60ce9f2fac which added
policy->cur initialization to __cpufreq_add_dev() to help reduce code
duplication in other cpufreq drivers.

However, the code added by commit da60ce9f2fac need not be executed
for cpufreq drivers having the ->setpolicy callback defined, because
the subsequent invocation of cpufreq_set_policy() will use that
callback to initialize the policy anyway and it doesn't need
policy->cur to be initialized upfront.  The analogous code in
cpufreq_update_policy() is also unnecessary for cpufreq drivers
having ->setpolicy set and may be skipped for them as well.

Since intel_pstate provides ->setpolicy, skipping the upfront
policy->cur initialization for cpufreq drivers with that callback
set will cover intel_pstate and the problem it's been having after
commit da60ce9f2fac will be addressed.

Fixes: da60ce9f2fac (cpufreq: call cpufreq_driver->get() after calling ->init())
References: https://bugzilla.kernel.org/show_bug.cgi?id=71931
Reported-and-tested-by: Patrik Lundquist 
Acked-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions

2014-03-24T04:44:12+00:00

commit 999976e0f6233322a878b0b7148c810544d6c8a8 upstream.

If a module calls cpufreq_get while cpufreq is initializing, it's
possible for it to be called after cpufreq_driver is set but before
cpufreq_cpu_data is written during subsys_interface_register.  This
happens because cpufreq_get doesn't take the cpufreq_driver_lock
around its use of cpufreq_cpu_data.

Fix this by using cpufreq_cpu_get(cpu) to look up the policy rather
than reading it out of cpufreq_cpu_data directly.  cpufreq_cpu_get()
takes the appropriate locks to prevent this race from happening.

Since it's possible for policy to be NULL if the caller passes in an
invalid CPU number or calls the function before cpufreq is initialized,
delete the BUG_ON(!policy) and simply return 0.  Don't try to return
-ENOENT because that's negative and the function returns an unsigned
integer.

References: https://bbs.archlinux.org/viewtopic.php?id=177934
Signed-off-by: Aaron Plattner 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Use LFM bus ratio as min ratio/P state

2014-03-07T06:06:23+00:00

commit 4042e7570cff740460b75c6fc604c629621d3dd2 upstream.

LFM (max efficiency ratio) is the max frequency at minimum voltage
supported by the processor.  Using LFM as the minimum P state
increases performmance without affecting power. By not using P states
below LFM we avoid using P states that are less power efficient.

Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: powernow-k8: Initialize per-cpu data-structures properly

2014-03-07T06:06:22+00:00

commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e upstream.

The powernow-k8 driver maintains a per-cpu data-structure called
powernow_data that is used to perform the frequency transitions.
It initializes this data structure only for the policy->cpu. So,
accesses to this data structure by other CPUs results in various
problems because they would have been uninitialized.

Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get()
function, it returns 0 as the KHz value, since its per-cpu memory
doesn't point to anything valid. This causes problems during
suspend/resume since cpufreq_update_policy() tries to enforce this
(0 KHz) as the current frequency of the CPU, and this madness gets
propagated to adjust_jiffies() as well. Eventually, lots of things
start breaking down, including the r8169 ethernet card, in one
particularly interesting case reported by Pierre Ossman.

Fix this by initializing the per-cpu data-structures of all the CPUs
in the policy appropriately.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70311
Reported-by: Pierre Ossman 
Signed-off-by: Srivatsa S. Bhat 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.

2014-01-06T21:16:14+00:00

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 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

intel_pstate: Fail initialization if P-state information is missing

2013-12-31T12:37:46+00:00

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:[]  [] 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:
 
 [] call_timer_fn+0x8a/0x310
 [] ? call_timer_fn+0x5/0x310
 [] ? pid_param_set+0x130/0x130
 [] run_timer_softirq+0x234/0x380
 [] __do_softirq+0x104/0x430
 [] irq_exit+0xcd/0xe0
 [] smp_apic_timer_interrupt+0x45/0x60
 [] apic_timer_interrupt+0x72/0x80
 
 [] ? vprintk_emit+0x1dd/0x5e0
 [] printk+0x67/0x69
 [] __cpufreq_add_dev.isra.13+0x883/0x8d0
 [] cpufreq_add_dev+0x10/0x20
 [] subsys_interface_register+0xb1/0xf0
 [] cpufreq_register_driver+0x9f/0x210
 [] intel_pstate_init+0x27d/0x3be
 [] ? mutex_unlock+0xe/0x10
 [] ? cpufreq_gov_dbs_init+0x12/0x12
 [] do_one_initcall+0xfa/0x1b0
 [] ? parse_args+0x225/0x3f0
 [] kernel_init_freeable+0x1fc/0x287
 [] ? do_early_param+0x88/0x88
 [] ? rest_init+0x150/0x150
 [] kernel_init+0xe/0x130
 [] ret_from_fork+0x7c/0xb0
 [] ? 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  [] intel_pstate_timer_func+0x11d/0x2b0
 RSP 
---[ end trace f166110ed22cc37a ]---
Kernel panic - not syncing: Fatal exception in interrupt

Reported-and-tested-by: Kashyap Chamarthy 
Cc: Josh Boyer 
Signed-off-by: Rafael J. Wysocki 
Cc: All applicable

cpufreq: preserve user_policy across suspend/resume

2013-12-29T14:31:21+00:00

Prevent __cpufreq_add_dev() from overwriting the existing values of
user_policy.{min|max|policy|governor} with defaults during resume
from system suspend.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
Cc: 3.12+  # 3.12+
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

cpufreq: Clean up after a failing light-weight initialization

2013-12-29T14:30:36+00:00

If cpufreq_policy_restore() returns NULL during system resume,
__cpufreq_add_dev() should just fall back to the full initialization
instead of returning an error, because that may actually make things
work.  Moreover, it should not leave stale fallback data behind after
it has failed to restore a previously existing policy.

This change is based on Viresh Kumar's work.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Cc: 3.12+  # 3.12+