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

cpufreq: unicore32: fix typo issue for 'clk'

2014-05-13T11:32:57+00:00

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 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: at32ap: don't declare local variable as static

2014-05-13T11:32:57+00:00

commit 0ca97886fece9e1acd71ade4ca3a250945c8fc8b upstream.

Earlier commit:
	commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
	Author: Viresh Kumar 
	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 
Signed-off-by: Viresh Kumar 
Acked-by: Hans-Christian Egtvedt 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: loongson2_cpufreq: don't declare local variable as static

2014-05-13T11:32:57+00:00

commit 05ed672292dc9d37db4fafdd49baa782158cd795 upstream.

Earlier commit:
	commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
	Author: Viresh Kumar 
	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 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Skip current frequency initialization for ->setpolicy drivers

2014-03-12T23:37:16+00:00

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 
Cc: 3.13+  # 3.13+
Signed-off-by: Rafael J. Wysocki

cpufreq: Initialize governor for a new policy under policy->rwsem

2014-03-06T12:25:30+00:00

policy->rwsem is used to lock access to all parts of code modifying
struct cpufreq_policy, but it's not used on a new policy created by
__cpufreq_add_dev().

Because of that, if cpufreq_update_policy() is called in a tight loop
on one CPU in parallel with offline/online of another CPU, then the
following crash can be triggered:

Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = c0003000
[00000020] *pgd=80000000004003, *pmd=00000000
Internal error: Oops: 206 [#1] PREEMPT SMP ARM

PC is at __cpufreq_governor+0x10/0x1ac
LR is at cpufreq_update_policy+0x114/0x150

---[ end trace f23a8defea6cd706 ]---
Kernel panic - not syncing: Fatal exception
CPU0: stopping
CPU: 0 PID: 7136 Comm: mpdecision Tainted: G      D W    3.10.0-gd727407-00074-g979ede8 #396

[] (notifier_call_chain+0x40/0x68) from [] (__blocking_notifier_call_chain+0x40/0x58)
[] (__blocking_notifier_call_chain+0x40/0x58) from [] (blocking_notifier_call_chain+0x14/0x1c)
[] (blocking_notifier_call_chain+0x14/0x1c) from [] (cpufreq_set_policy+0xd4/0x2b8)
[] (cpufreq_set_policy+0xd4/0x2b8) from [] (cpufreq_init_policy+0x30/0x98)
[] (cpufreq_init_policy+0x30/0x98) from [] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4)
[] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from [] (cpufreq_cpu_callback+0x58/0x84)
[] (cpufreq_cpu_callback+0x58/0x84) from [] (notifier_call_chain+0x40/0x68)
[] (notifier_call_chain+0x40/0x68) from [] (__cpu_notify+0x28/0x44)
[] (__cpu_notify+0x28/0x44) from [] (_cpu_up+0xf4/0x1dc)
[] (_cpu_up+0xf4/0x1dc) from [] (cpu_up+0x5c/0x78)
[] (cpu_up+0x5c/0x78) from [] (store_online+0x44/0x74)
[] (store_online+0x44/0x74) from [] (sysfs_write_file+0x108/0x14c)
[] (sysfs_write_file+0x108/0x14c) from [] (vfs_write+0xd0/0x180)
[] (vfs_write+0xd0/0x180) from [] (SyS_write+0x38/0x68)
[] (SyS_write+0x38/0x68) from [] (ret_fast_syscall+0x0/0x30)

Fix that by taking locks at appropriate places in __cpufreq_add_dev()
as well.

Reported-by: Saravana Kannan 
Suggested-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

cpufreq: Initialize policy before making it available for others to use

2014-03-06T12:25:29+00:00

Policy must be fully initialized before it is being made available
for use by others. Otherwise cpufreq_cpu_get() would be able to grab
a half initialized policy structure that might not have affected_cpus
(for example) populated. Then, anybody accessing those fields will get
a wrong value and that will lead to unpredictable results.

In order to fix this, do all the necessary initialization before we
make the policy structure available via cpufreq_cpu_get(). That will
guarantee that any code accessing fields of the policy will get
correct data from them.

Reported-by: Saravana Kannan 
Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

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

2014-03-06T12:25:16+00:00

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 
Cc: 3.13+  # 3.13+
Signed-off-by: Rafael J. Wysocki

intel_pstate: Change busy calculation to use fixed point math.

2014-02-25T23:56:49+00:00

Commit fcb6a15c2e (intel_pstate: Take core C0 time into account for
core busy calculation) introduced a regression on some processor SKUs
supported by intel_pstate. This was due to the truncation caused by
using integer math to calculate core busy and C0 percentages.

On a i7-4770K processor operating at 800Mhz going to 100% utilization
the percent busy of the CPU using integer math is 22%, but it actually
is 22.85%.  This value scaled to the current frequency returned 97
which the PID interpreted as no error and did not adjust the P state.

Tested on i7-4770K, i7-2600, i5-3230M.

Fixes: fcb6a15c2e7e (intel_pstate: Take core C0 time into account for core busy calculation)
References: https://lkml.org/lkml/2014/2/19/626
References: https://bugzilla.kernel.org/show_bug.cgi?id=70941
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki

intel_pstate: Add support for Baytrail turbo P states

2014-02-21T00:22:40+00:00

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

Signed-off-by: Dirk Brandewie 
Cc: 3.13+  # 3.13+
Signed-off-by: Rafael J. Wysocki

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

2014-02-21T00:22:40+00:00

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 
Cc: 3.13+  # 3.13+
Signed-off-by: Rafael J. Wysocki