summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/pmac32-cpufreq.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-11-17 22:47:47 +0100
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-11-17 22:47:47 +0100
commitd0ea59e188941417a9fb5898d894b3106a8ad313 (patch)
treea5fdde28c81123f3221ca699914e8917441e6cd6 /drivers/cpufreq/pmac32-cpufreq.c
parentf0da898b464953157911913cd93eaedcb2c92407 (diff)
cpufreq: intel_pstate: Request P-states control from SMM if needed
Currently, intel_pstate is unable to control P-states on my IvyBridge-based Acer Aspire S5, because they are controlled by SMM on that machine by default and it is necessary to request OS control of P-states from it via the SMI Command register exposed in the ACPI FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other cpufreq drivers for x86 platforms do. Address this problem by making intel_pstate use the ACPI-defined mechanism as well. However, intel_pstate is not modular and it doesn't need the module refcount tricks played by acpi_processor_notify_smm(), so export the core of this function to it as acpi_processor_pstate_control() and make it call that. [The changes in processor_perflib.c related to this should not make any functional difference for the acpi_processor_notify_smm() users]. To be safe, only call acpi_processor_notify_smm() from intel_pstate if ACPI _PPC support is enabled in it. Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Diffstat (limited to 'drivers/cpufreq/pmac32-cpufreq.c')
0 files changed, 0 insertions, 0 deletions