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

cpufreq: release policy->rwsem on error

2014-10-05T21:52:22+00:00

commit 7106e02baed4a72fb23de56b02ad4d31daa74d95 upstream.

While debugging a cpufreq-related hardware failure on a system I saw the
following lockdep warning:

 =========================
 [ BUG: held lock freed! ] 3.17.0-rc4+ #1 Tainted: G            E
 -------------------------
 insmod/2247 is freeing memory ffff88006e1b1400-ffff88006e1b17ff, with a lock still held there!
  (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80
 3 locks held by insmod/2247:
  #0:  (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x69/0x120
  #1:  (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.21+0x73/0xb80
  #2:  (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80

 stack backtrace:
 CPU: 0 PID: 2247 Comm: insmod Tainted: G            E  3.17.0-rc4+ #1
 Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 08/24/2013
  0000000000000000 000000008f3063c4 ffff88006f87bb30 ffffffff8171b358
  ffff88006bcf3750 ffff88006f87bb68 ffffffff810e09e1 ffff88006e1b1400
  ffffea0001b86c00 ffffffff8156d327 ffff880073003500 0000000000000246
 Call Trace:
  [] dump_stack+0x4d/0x66
  [] debug_check_no_locks_freed+0x171/0x180
  [] ? __cpufreq_add_dev.isra.21+0x427/0xb80
  [] kfree+0xab/0x2b0
  [] __cpufreq_add_dev.isra.21+0x427/0xb80
  [] ? _raw_spin_unlock+0x27/0x40
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] cpufreq_add_dev+0xe/0x10
  [] subsys_interface_register+0xc1/0x120
  [] cpufreq_register_driver+0x112/0x340
  [] ? kfree+0xda/0x2b0
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] pcc_cpufreq_init+0x4af/0xe81 [pcc_cpufreq]
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] do_one_initcall+0xd4/0x210
  [] ? __vunmap+0xd2/0x120
  [] load_module+0x1315/0x1b70
  [] ? store_uevent+0x70/0x70
  [] ? copy_module_from_fd.isra.44+0x129/0x180
  [] SyS_finit_module+0xa6/0xd0
  [] system_call_fastpath+0x16/0x1b
 cpufreq: __cpufreq_add_dev: ->get() failed
insmod: ERROR: could not insert module pcc-cpufreq.ko: No such device

The warning occurs in the __cpufreq_add_dev() code which does

        down_write(&policy->rwsem);
	...
        if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
                policy->cur = cpufreq_driver->get(policy->cpu);
                if (!policy->cur) {
                        pr_err("%s: ->get() failed\n", __func__);
                        goto err_get_freq;
                }

If cpufreq_driver->get(policy->cpu) returns an error we execute the
code at err_get_freq, which does not up the policy->rwsem.  This causes
the lockdep warning.

Trivial patch to up the policy->rwsem in the error path.

After the patch has been applied, and an error occurs in the
cpufreq_driver->get(policy->cpu) call we will now see

cpufreq: __cpufreq_add_dev: ->get() failed
cpufreq: __cpufreq_add_dev: ->get() failed
modprobe: ERROR: could not insert 'pcc_cpufreq': No such device

Fixes: 4e97b631f24c (cpufreq: Initialize governor for a new policy under policy->rwsem)
Signed-off-by: Prarit Bhargava 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: move policy kobj to policy->cpu at resume

2014-08-07T21:52:38+00:00

commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream.

This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.

Consider a dual cluster platform with 2 cores per cluster. During suspend we
start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj
would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its
kobj as we want to retain permissions/values/etc.

Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
We will recover the old policy and update policy->cpu from 3 to 2 from
update_policy_cpu().

But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a
link for CPU2, but would try that for CPU3 while bringing it online. Which will
report errors as CPU3 already has kobj assigned to it.

This bug got introduced with commit 42f921a, which overlooked this scenario.

To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here
only for the first CPU of a non-boot cluster. And we can't recover from this
situation, if kobject_move() fails.

Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume)
Cc:  3.13+  # 3.13+
Reported-and-tested-by: Bu Yitian 
Reported-by: Saravana Kannan 
Reviewed-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Set CPU number before accessing MSRs

2014-07-17T23:21:05+00:00

commit 179e8471673ce0249cd4ecda796008f7757e5bad upstream.

Ensure that cpu->cpu is set before writing MSR_IA32_PERF_CTL during CPU
initialization. Otherwise only cpu0 has its P-state set and all other
cores are left with their values unchanged.

In most cases, this is not too serious because the P-states will be set
correctly when the timer function is run.  But when the default governor
is set to performance, the per-CPU current_pstate stays the same forever
and no attempts are made to write the MSRs again.

Signed-off-by: Vincent Minet 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: don't touch turbo bit if turbo disabled or unavailable.

2014-07-17T23:21:05+00:00

commit dd5fbf70f96dbfd7ee432096a1f979b2b3267856 upstream.

If turbo is disabled in the BIOS bit 38 should be set in
MSR_IA32_MISC_ENABLE register per section 14.3.2.1 of the SDM Vol 3
document 325384-050US Feb 2014.  If this bit is set do *not* attempt
to disable trubo via the MSR_IA32_PERF_CTL register.  On some systems
trying to disable turbo via MSR_IA32_PERF_CTL will cause subsequent
writes to MSR_IA32_PERF_CTL not take affect, in fact reading
MSR_IA32_PERF_CTL will not show the IDA/Turbo DISENGAGE bit(32) as
set. A write of bit 32 to zero returns to normal operation.

Also deal with the case where the processor does not support
turbo and the BIOS does not report the fact in MSR_IA32_MISC_ENABLE
but does report the max and turbo P states as the same value.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Fix setting VID

2014-07-17T23:21:05+00:00

commit c16ed06024a6e699c332831dd50d8276744e3de8 upstream.

Commit 21855ff5 (intel_pstate: Set turbo VID for BayTrail) introduced
setting the turbo VID which is required to prevent a machine check on
some Baytrail SKUs under heavy graphics based workloads.  The
docmumentation update that brought the requirement to light also
changed the bit mask used for enumerating P state and VID values from
0x7f to 0x3f.

This change returns the mask value to 0x7f.

Tested with the Intel NUC DN2820FYK,
BIOS version FYBYT10H.86A.0034.2014.0513.1413 with v3.16-rc1 and
v3.14.8 kernel versions.

Fixes: 21855ff5 (intel_pstate: Set turbo VID for BayTrail)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77951
Reported-and-tested-by: Rune Reterson 
Reported-and-tested-by: Eric Eickmeyer 
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Makefile: fix compilation for davinci platform

2014-07-17T23:21:04+00:00

commit 5a90af67c2126fe1d04ebccc1f8177e6ca70d3a9 upstream.

Since commtit 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to
drivers/cpufreq) this added dependancy only for CONFIG_ARCH_DAVINCI_DA850
where as davinci_cpufreq_init() call is used by all davinci platform.

This patch fixes following build error:

arch/arm/mach-davinci/built-in.o: In function `davinci_init_late':
:(.init.text+0x928): undefined reference to `davinci_cpufreq_init'
make: *** [vmlinux] Error 1

Fixes: 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq)
Signed-off-by: Lad, Prabhakar 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Correct rounding in busy calculation

2014-07-09T18:18:26+00:00

commit 51d211e9c334b9eca3505f4052afa660c3e0606b upstream.

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

intel_pstate: Improve initial busy calculation

2014-06-11T18:54:13+00:00

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 
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: add sample time scaling

2014-06-11T18:54:13+00:00

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

intel_pstate: Correct rounding in busy calculation

2014-06-11T18:54:13+00:00

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 
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman