cpufreq: intel_pstate: Request P-states control from SMM if needed
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>
Thu, 17 Nov 2016 21:47:47 +0000 (22:47 +0100)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Thu, 17 Nov 2016 21:47:47 +0000 (22:47 +0100)
commitd0ea59e188941417a9fb5898d894b3106a8ad313
treea5fdde28c81123f3221ca699914e8917441e6cd6
parentf0da898b464953157911913cd93eaedcb2c92407
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>
drivers/acpi/processor_perflib.c
drivers/cpufreq/intel_pstate.c
include/acpi/processor.h