summaryrefslogtreecommitdiffstats
path: root/drivers/hwmon/tmp102.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-10-24 23:20:25 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-10-24 23:20:25 +0200
commit2f1d407adab026b34a105ed27b1d4d7e910c4448 (patch)
tree1c5f14db4f9417a9d709d065a7bc2bf057a8053e /drivers/hwmon/tmp102.c
parentcpufreq: intel_pstate: Set P-state upfront in performance mode (diff)
downloadlinux-2f1d407adab026b34a105ed27b1d4d7e910c4448.tar.xz
linux-2f1d407adab026b34a105ed27b1d4d7e910c4448.zip
cpufreq: intel_pstate: Always set max P-state in performance mode
The only times at which intel_pstate checks the policy set for a given CPU is the initialization of that CPU and updates of its policy settings from cpufreq when intel_pstate_set_policy() is invoked. That is insufficient, however, because intel_pstate uses the same P-state selection function for all CPUs regardless of the policy setting for each of them and the P-state limits are shared between them. Thus if the policy is set to "performance" for a particular CPU, it may not behave as expected if the cpufreq settings are changed subsequently for another CPU. That can be easily demonstrated by writing "performance" to scaling_governor for all CPUs and then switching it to "powersave" for one of them in which case all of the CPUs will behave as though their scaling_governor were all "powersave" (even though the policy still appears to be "performance" for the remaining CPUs). Fix this problem by modifying intel_pstate_adjust_busy_pstate() to always set the P-state to the maximum allowed by the current limits for all CPUs whose policy is set to "performance". Note that it still is recommended to always change the policy setting in the same way for all CPUs even with this fix applied to avoid confusion. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/hwmon/tmp102.c')
0 files changed, 0 insertions, 0 deletions