kernel.git/drivers/cpufreq/intel_pstate.c, branch linux-3.15.y

intel_pstate: Set CPU number before accessing MSRs

2014-07-17T23:23:15Z

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:23:15Z

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:23:14Z

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

intel_pstate: Correct rounding in busy calculation

2014-07-09T18:21:28Z

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-02T10:46:01Z

This change makes the busy calculation using 64 bit math which prevents overflow for large values of aperf/mperf. Cc: 3.14+ # 3.14+ Signed-off-by: Doug Smythies Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

intel_pstate: add sample time scaling

2014-06-02T10:45:05Z

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

intel_pstate: Correct rounding in busy calculation

2014-06-02T10:44:59Z

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

intel_pstate: Remove C0 tracking

2014-06-02T10:44:48Z

Commit fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) introduced a regression referenced below. The issue with "lockup" after suspend that this commit was addressing is now dealt with in the suspend path. Fixes: fcb6a15c2e7e (intel_pstate: Take core C0 time into account for core busy calculation) Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581 Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121 Reported-by: Doug Smythies Cc: 3.14+ # 3.14+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

intel_pstate: remove setting P state to MAX on init

2014-05-13T15:39:13Z

Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: Patrick Marlier Signed-off-by: Dirk Brandewie Cc: 3.14+ # 3.14+ Signed-off-by: Rafael J. Wysocki

intel_pstate: Set turbo VID for BayTrail

2014-05-11T23:58:58Z

A documentation update exposed that there is a separate set of VID values that must be used in the turbo/boost P state range. Add enumerating and setting the correct VID for P states in the turbo range. Cc: v3.13+ # v3.13+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki