linux-toradex.git/drivers/cpufreq/intel_pstate.c, branch v4.4.119

cpufreq: intel_pstate: Fix unsafe HWP MSR access

2016-10-28T07:01:26+00:00

commit f9f4872df6e1801572949f8a370c886122d4b6da upstream.

This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before
reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is
scheduled on a CPU which is not same as policy->cpu or migrates to a
different CPU before calling msr read for MSR_HWP_CAPABILITIES, it
is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU.
This will cause GP fault. So like other places in this path
rdmsrl_on_cpu should be used instead of rdmsrl.

Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it
should be read from the same CPU, for which MSR MSR_HWP_REQUEST is
getting set.

dmesg dump or warning:

[   22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014492] unchecked MSR access error: RDMSR from 0x771
[   22.014493] Modules linked in:
[   22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1
...
...
[   22.014516] Call Trace:
[   22.014542]  [] dump_stack+0x63/0x82
[   22.014558]  [] __warn+0xcb/0xf0
[   22.014561]  [] warn_slowpath_fmt+0x4f/0x60
[   22.014563]  [] ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014564]  [] fixup_exception+0x39/0x50
[   22.014604]  [] do_general_protection+0x80/0x150
[   22.014610]  [] general_protection+0x28/0x30
[   22.014635]  [] ? get_target_pstate_use_performance+0xb0/0xb0
[   22.014642]  [] ? native_read_msr+0x7/0x40
[   22.014657]  [] intel_pstate_hwp_set+0x23/0x130
[   22.014660]  [] intel_pstate_set_policy+0x1b6/0x340
[   22.014662]  [] cpufreq_set_policy+0xeb/0x2c0
[   22.014664]  [] cpufreq_init_policy+0x79/0xe0
[   22.014666]  [] ? cpufreq_update_policy+0x120/0x120
[   22.014669]  [] cpufreq_online+0x406/0x820
[   22.014671]  [] cpufreq_add_dev+0x5f/0x90
[   22.014717]  [] subsys_interface_register+0xb8/0x100
[   22.014719]  [] cpufreq_register_driver+0x14c/0x210
[   22.014749]  [] intel_pstate_init+0x39d/0x4d5
[   22.014751]  [] ? cpufreq_gov_dbs_init+0x12/0x12

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

intel_pstate: Fix MSR_CONFIG_TDP_x addressing in core_get_max_pstate()

2016-08-20T16:09:18+00:00

commit 5fc8f707a2aa40c767c3a338738b9b6fcd151ac1 upstream.

If MSR_CONFIG_TDP_CONTROL is locked, we currently try to address some
MSR 0x80000648 or so. Mask out the relevant level bits 0 and 1.

Found while running over the Jailhouse hypervisor which became upset
about this strange MSR index.

Signed-off-by: Jan Kiszka 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: intel_pstate: Fix processing for turbo activation ratio

2016-05-04T21:48:44+00:00

commit 1becf03545a0859ceaaf9e8c2d9861882a71cb01 upstream.

When the config TDP level is not nominal (level = 0), the MSR values for
reading level 1 and level 2 ratios contain power in low 14 bits and actual
ratio bits are at bits [23:16]. The current processing for level 1 and
level 2 is wrong as there is no shift done to get actual ratio.

Fixes: 6a35fc2d6c22 (cpufreq: intel_pstate: get P1 from TAR when available)
Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: intel_pstate: Minor cleanup for FRAC_BITS

2015-12-12T01:28:19+00:00

785ee27 ("cpufreq: intel_pstate: Fix limits->max_perf rounding error")
hardcodes the value of FRAC_BITS.  This patch fixes that minor issue.

Fixes: 785ee2788141 (cpufreq: intel_pstate: Fix limits->max_perf rounding error)
Signed-off-by: Prarit Bhargava 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

intel_pstate: Fix "performance" mode behavior with HWP enabled

2015-11-25T22:37:44+00:00

If hardware-driven P-state selection (HWP) is enabled, the
"performance" mode of intel_pstate should only allow the processor
to use the highest-performance P-state available.  That is not
the case currently, so make it actually happen.

Acked-by: Srinivas Pandruvada 
Signed-off-by: Alexandra Yates 
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Fix limits->max_perf rounding error

2015-11-23T22:15:34+00:00

A rounding error was found in the calculation of limits->max_perf
in intel_pstate_set_policy(), which is used to calculate the max and min
pstate values in intel_pstate_get_min_max().  In that code,
limits->max_perf is truncated to 2 hex digits such that, for example,
0x169 was incorrectly calculated to 0x16 instead of 0x17.  This resulted in
the pstate being set one level too low.  This patch rounds the value of
limits->max_perf up instead of down so that the correct max pstate can
be reached.

Signed-off-by: Prarit Bhargava 
Acked-by: Srinivas Pandruvada 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Fix limits->max_policy_pct rounding error

2015-11-23T22:14:10+00:00

I have a Intel (6,63) processor with a "marketing" frequency (from
/proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz.  I
can execute

cpupower frequency-set -g powersave --min 1200MHz --max 2100MHz

and the max_freq_pct is set to 80.  When adding load to the system I noticed
that the cpu frequency only reached 2000MHZ and not 2100MHz as expected.

This is because limits->max_policy_pct is calculated as 2100 * 100 /2600 = 80.7
and is rounded down to 80 when it should be rounded up to 81.  This patch
adds a DIV_ROUND_UP() which will return the correct value.

Signed-off-by: Prarit Bhargava 
Acked-by: Srinivas Pandruvada 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Add separate support for Airmont cores

2015-11-18T23:21:46+00:00

There are two flavors of Atom cores to be supported by intel_pstate,
Silvermont and Airmont, so make the driver distinguish between them by
adding separate frequency tables.

Separate the CPU defaults params for each of them and match the CPU IDs
against them as appropriate.

Signed-off-by: Philippe Longepe 
Signed-off-by: Stephane Gasparini 
Acked-by: Srinivas Pandruvada 
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Replace BYT with ATOM

2015-11-18T23:21:46+00:00

Rename symbol and function names starting with "BYT" or "byt" to
start with "ATOM" or "atom", respectively, so as to make it clear
that they may apply to Atom in general and not just to Baytrail
(the goal is to support several Atoms architectures eventually).

This should not lead to any functional changes.

Signed-off-by: Philippe Longepe 
Signed-off-by: Stephane Gasparini 
Acked-by: Srinivas Pandruvada 
[ rjw : Changelog ]
Signed-off-by: Rafael J. Wysocki

Revert "cpufreq: intel_pstate: Use ACPI perf configuration"

2015-11-18T23:20:42+00:00

Revert commit 37afb0003242 (cpufreq: intel_pstate: Use ACPI perf
configuration) that is reported to cause a regression to happen
on a system where invalid data are returned by the ACPI _PSS object.

Since that commit makes assumptions regarding the _PSS output
correctness that may turn out to be overly optimistic in general,
there is a concern that it may introduce regression on more
systems, so it's better to revert it now and we'll revisit the
underlying issue in the next cycle with a more robust solution.

Conflicts:
        drivers/cpufreq/intel_pstate.c

Fixes: 37afb0003242 (cpufreq: intel_pstate: Use ACPI perf configuration)
Reported-by: Borislav Petkov 
Signed-off-by: Rafael J. Wysocki