Commit 67990608 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'pm+acpi-4.5-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull oower management and ACPI updates from Rafael Wysocki:
 "As far as the number of commits goes, ACPICA takes the lead this time,
  followed by cpufreq and the device properties framework changes.

  The most significant new feature is the debugfs-based interface to the
  ACPICA's AML debugger added in the previous cycle and a new user space
  tool for accessing it.

  On the cpufreq front, the core is updated to handle governors more
  efficiently, particularly on systems where a single cpufreq policy
  object is shared between multiple CPUs, and there are quite a few
  changes in drivers (intel_pstate, cpufreq-dt etc).

  The device properties framework is updated to handle built-in (ie
  included in the kernel itself) device properties better, among other
  things by adding a fallback mechanism that will allow drivers to
  provide default properties to be used in case the plaform firmware
  doesn't provide the properties expected by them.

  The Operating Performance Points (OPP) framework gets new DT bindings
  and debugfs support.

  A new cpufreq driver for ST platforms is added and the ACPI driver for
  AMD SoCs will now support the APM X-Gene ACPI I2C device.

  The rest is mostly fixes and cleanups all over.

  Specifics:

   - Add a debugfs-based interface for interacting with the ACPICA's AML
     debugger introduced in the previous cycle and a new user space tool
     for that, fix some bugs related to the AML debugger and clean up
     the code in question (Lv Zheng, Dan Carpenter, Colin Ian King,
     Markus Elfring).

   - Update ACPICA to upstream revision 20151218 including a number of
     fixes and cleanups in the ACPICA core (Bob Moore, Lv Zheng, Labbe
     Corentin, Prarit Bhargava, Colin Ian King, David E Box, Rafael
     Wysocki).

     In particular, the previously added erroneous support for the _SUB
     object is dropped, the concatenate operator will support all ACPI
     objects now, the Debug Object handling is improved, the SuperName
     handling of parameters being control methods is fixed, the
     ObjectType operator handling is updated to follow ACPI 5.0A and the
     handling of CondRefOf and RefOf is updated accordingly, module-
     level code will be executed after loading each ACPI table now
     (instead of being run once after all tables containing AML have
     been loaded), the Operation Region handlers management is updated
     to fix some reported problems and a the ACPICA code in the kernel
     is more in line with the upstream now.

   - Update the ACPI backlight driver to provide information on whether
     or not it will generate key-presses for brightness change hotkeys
     and update some platform drivers (dell-wmi, thinkpad_acpi) to use
     that information to avoid sending double key-events to users pace
     for these, add new ACPI backlight quirks (Hans de Goede, Aaron Lu,
     Adrien Schildknecht).

   - Improve the ACPI handling of interrupt GPIOs (Christophe Ricard).

   - Fix the handling of the list of device IDs of device objects found
     in the ACPI namespace and add a helper for checking if there is a
     device object for a given device ID (Lukas Wunner).

   - Change the logic in the ACPI namespace scanning code to create
     struct acpi_device objects for all ACPI device objects found in the
     namespace even if _STA fails for them which helps to avoid device
     enumeration problems on Microsoft Surface 3 (Aaron Lu).

   - Add support for the APM X-Gene ACPI I2C device to the ACPI driver
     for AMD SoCs (Loc Ho).

   - Fix the long-standing issue with the DMA controller on Intel SoCs
     where ACPI tables have no power management support for the DMA
     controller itself, but it can be powered off automatically when the
     last (other) device on the SoC is powered off via ACPI and clean up
     the ACPI driver for Intel SoCs (acpi-lpss) after previous attempts
     to fix that problem (Andy Shevchenko).

   - Assorted ACPI fixes and cleanups (Andy Lutomirski, Colin Ian King,
     Javier Martinez Canillas, Ken Xue, Mathias Krause, Rafael Wysocki,
     Sinan Kaya).

   - Update the device properties framework for better handling of
     built-in properties, add support for built-in properties to the
     platform bus type, update the MFD subsystem's handling of device
     properties and add support for passing default configuration data
     as device properties to the intel-lpss MFD drivers, convert the
     designware I2C driver to use the unified device properties API and
     add a fallback mechanism for using default built-in properties if
     the platform firmware fails to provide the properties as expected
     by drivers (Andy Shevchenko, Mika Westerberg, Heikki Krogerus,
     Andrew Morton).

   - Add new Device Tree bindings to the Operating Performance Points
     (OPP) framework and update the exynos4412 DT binding accordingly,
     introduce debugfs support for the OPP framework (Viresh Kumar,
     Bartlomiej Zolnierkiewicz).

   - Migrate the mt8173 cpufreq driver to the new OPP bindings (Pi-Cheng
     Chen).

   - Update the cpufreq core to make the handling of governors more
     efficient, especially on systems where policy objects are shared
     between multiple CPUs (Viresh Kumar, Rafael Wysocki).

   - Fix cpufreq governor handling on configurations with
     CONFIG_HZ_PERIODIC set (Chen Yu).

   - Clean up the cpufreq core code related to the boost sysfs knob
     support and update the ACPI cpufreq driver accordingly (Rafael
     Wysocki).

   - Add a new cpufreq driver for ST platforms and corresponding Device
     Tree bindings (Lee Jones).

   - Update the intel_pstate driver to allow the P-state selection
     algorithm used by it to depend on the CPU ID of the processor it is
     running on, make it use a special P-state selection algorithm (with
     an IO wait time compensation tweak) on Atom CPUs based on the
     Airmont and Silvermont cores so as to reduce their energy
     consumption and improve intel_pstate documentation (Philippe
     Longepe, Srinivas Pandruvada).

   - Update the cpufreq-dt driver to support registering cooling devices
     that use the (P * V^2 * f) dynamic power draw formula where V is
     the voltage, f is the frequency and P is a constant coefficient
     provided by Device Tree and update the arm_big_little cpufreq
     driver to use that support (Punit Agrawal).

   - Assorted cpufreq driver (cpufreq-dt, qoriq, pcc-cpufreq,
     blackfin-cpufreq) updates (Andrzej Hajda, Hongtao Jia, Jacob
     Tanenbaum, Markus Elfring).

   - cpuidle core tweaks related to polling and measured_us calculation
     (Rik van Riel).

   - Removal of modularity from a few cpuidle drivers (clps711x, ux500,
     exynos) that cannot be built as modules in practice (Paul
     Gortmaker).

   - PM core update to prevent devices from being probed during system
     suspend/resume which is generally problematic and may lead to
     inconsistent behavior (Grygorii Strashko).

   - Assorted updates of the PM core and related code (Julia Lawall,
     Manuel Pégourié-Gonnard, Maruthi Bayyavarapu, Rafael Wysocki, Ulf
     Hansson).

   - PNP bus type updates (Christophe Le Roy, Heiner Kallweit).

   - PCI PM code cleanups (Jarkko Nikula, Julia Lawall).

   - cpupower tool updates (Jacob Tanenbaum, Thomas Renninger)"

* tag 'pm+acpi-4.5-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (177 commits)
  PM / clk: don't leave clocks enabled when driver not bound
  i2c: dw: Add APM X-Gene ACPI I2C device support
  ACPI / APD: Add APM X-Gene ACPI I2C device support
  ACPI / LPSS: change 'does not have' to 'has' in comment
  Revert "dmaengine: dw: platform: provide platform data for Intel"
  dmaengine: dw: return immediately from IRQ when DMA isn't in use
  dmaengine: dw: platform: power on device on shutdown
  ACPI / LPSS: override power state for LPSS DMA device
  PM / OPP: Use snprintf() instead of sprintf()
  Documentation: cpufreq: intel_pstate: enhance documentation
  ACPI, PCI, irq: remove redundant check for null string pointer
  ACPI / video: driver must be registered before checking for keypresses
  cpufreq-dt: fix handling regulator_get_voltage() result
  cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC
  PM / sleep: Add support for read-only sysfs attributes
  ACPI: Fix white space in a structure definition
  ACPI / SBS: fix inconsistent indenting inside if statement
  PNP: respect PNP_DRIVER_RES_DO_NOT_CHANGE when detaching
  ACPI / PNP: constify device IDs
  ACPI / PCI: Simplify acpi_penalize_isa_irq()
  ...
parents c17488d0 a889f766
This diff is collapsed.
......@@ -159,8 +159,8 @@ to be strictly associated with a P-state.
2.2 cpuinfo_transition_latency:
-------------------------------
The cpuinfo_transition_latency field is 0. The PCC specification does
not include a field to expose this value currently.
The cpuinfo_transition_latency field is CPUFREQ_ETERNAL. The PCC specification
does not include a field to expose this value currently.
2.3 cpuinfo_cur_freq:
---------------------
......
......@@ -242,6 +242,23 @@ nodes to be present and contain the properties described below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
- dynamic-power-coefficient
Usage: optional
Value type: <prop-encoded-array>
Definition: A u32 value that represents the running time dynamic
power coefficient in units of mW/MHz/uVolt^2. The
coefficient can either be calculated from power
measurements or derived by analysis.
The dynamic power consumption of the CPU is
proportional to the square of the Voltage (V) and
the clock frequency (f). The coefficient is used to
calculate the dynamic power as below -
Pdyn = dynamic-power-coefficient * V^2 * f
where voltage is in uV, frequency is in MHz.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
......
Binding for ST's CPUFreq driver
===============================
ST's CPUFreq driver attempts to read 'process' and 'version' attributes
from the SoC, then supplies the OPP framework with 'prop' and 'supported
hardware' information respectively. The framework is then able to read
the DT and operate in the usual way.
For more information about the expected DT format [See: ../opp/opp.txt].
Frequency Scaling only
----------------------
No vendor specific driver required for this.
Located in CPU's node:
- operating-points : [See: ../power/opp.txt]
Example [safe]
--------------
cpus {
cpu@0 {
/* kHz uV */
operating-points = <1500000 0
1200000 0
800000 0
500000 0>;
};
};
Dynamic Voltage and Frequency Scaling (DVFS)
--------------------------------------------
This requires the ST CPUFreq driver to supply 'process' and 'version' info.
Located in CPU's node:
- operating-points-v2 : [See ../power/opp.txt]
Example [unsafe]
----------------
cpus {
cpu@0 {
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table {
compatible = "operating-points-v2";
/* ############################################################### */
/* # WARNING: Do not attempt to copy/replicate these nodes, # */
/* # they are only to be supplied by the bootloader !!! # */
/* ############################################################### */
opp0 {
/* Major Minor Substrate */
/* 2 all all */
opp-supported-hw = <0x00000004 0xffffffff 0xffffffff>;
opp-hz = /bits/ 64 <1500000000>;
clock-latency-ns = <10000000>;
opp-microvolt-pcode0 = <1200000>;
opp-microvolt-pcode1 = <1200000>;
opp-microvolt-pcode2 = <1200000>;
opp-microvolt-pcode3 = <1200000>;
opp-microvolt-pcode4 = <1170000>;
opp-microvolt-pcode5 = <1140000>;
opp-microvolt-pcode6 = <1100000>;
opp-microvolt-pcode7 = <1070000>;
};
opp1 {
/* Major Minor Substrate */
/* all all all */
opp-supported-hw = <0xffffffff 0xffffffff 0xffffffff>;
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <10000000>;
opp-microvolt-pcode0 = <1110000>;
opp-microvolt-pcode1 = <1150000>;
opp-microvolt-pcode2 = <1100000>;
opp-microvolt-pcode3 = <1080000>;
opp-microvolt-pcode4 = <1040000>;
opp-microvolt-pcode5 = <1020000>;
opp-microvolt-pcode6 = <980000>;
opp-microvolt-pcode7 = <930000>;
};
};
......@@ -45,21 +45,10 @@ Devices supporting OPPs must set their "operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
Devices may want to choose OPP tables at runtime and so can provide a list of
phandles here. But only *one* of them should be chosen at runtime. This must be
accompanied by a corresponding "operating-points-names" property, to uniquely
identify the OPP tables.
If required, this can be extended for SoC vendor specfic bindings. Such bindings
should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
and should have a compatible description like: "operating-points-v2-<vendor>".
Optional properties:
- operating-points-names: Names of OPP tables (required if multiple OPP
tables are present), to uniquely identify them. The same list must be present
for all the CPUs which are sharing clock/voltage rails and hence the OPP
tables.
* OPP Table Node
This describes the OPPs belonging to a device. This node can have following
......@@ -100,6 +89,14 @@ Optional properties:
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.
- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
the above opp-microvolt property, but allows multiple voltage ranges to be
provided for the same OPP. At runtime, the platform can pick a <name> and
matching opp-microvolt-<name> property will be enabled for all OPPs. If the
platform doesn't pick a specific <name> or the <name> doesn't match with any
opp-microvolt-<name> properties, then opp-microvolt property shall be used, if
present.
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
......@@ -112,6 +109,9 @@ Optional properties:
for few regulators, then this should be marked as zero for them. If it isn't
required for any regulator, then this property need not be present.
- opp-microamp-<name>: Named opp-microamp property. Similar to
opp-microvolt-<name> property, but for microamp instead.
- clock-latency-ns: Specifies the maximum possible transition latency (in
nanoseconds) for switching to this OPP from any other OPP.
......@@ -123,6 +123,26 @@ Optional properties:
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
- opp-supported-hw: This enables us to select only a subset of OPPs from the
larger OPP table, based on what version of the hardware we are running on. We
still can't have multiple nodes with the same opp-hz value in OPP table.
It's an user defined array containing a hierarchy of hardware version numbers,
supported by the OPP. For example: a platform with hierarchy of three levels
of versions (A, B and C), this field should be like <X Y Z>, where X
corresponds to Version hierarchy A, Y corresponds to version hierarchy B and Z
corresponds to version hierarchy C.
Each level of hierarchy is represented by a 32 bit value, and so there can be
only 32 different supported version per hierarchy. i.e. 1 bit per version. A
value of 0xFFFFFFFF will enable the OPP for all versions for that hierarchy
level. And a value of 0x00000000 will disable the OPP completely, and so we
never want that to happen.
If 32 values aren't sufficient for a version hierarchy, than that version
hierarchy can be contained in multiple 32 bit values. i.e. <X Y Z1 Z2> in the
above example, Z1 & Z2 refer to the version hierarchy Z.
- status: Marks the node enabled/disabled.
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
......@@ -157,20 +177,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp@1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
......@@ -236,20 +256,20 @@ independently.
* independently.
*/
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp@1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
......@@ -312,20 +332,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp@1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
......@@ -338,20 +358,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
opp10 {
opp@1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1045000 1050000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
opp11 {
opp@1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
opp12 {
opp@1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1010000 1100000 1110000>;
opp-microamp = <95000>;
......@@ -378,7 +398,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
......@@ -391,7 +411,7 @@ Example 4: Handling multiple regulators
/* OR */
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
......@@ -404,7 +424,7 @@ Example 4: Handling multiple regulators
/* OR */
opp00 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
......@@ -417,7 +437,8 @@ Example 4: Handling multiple regulators
};
};
Example 5: Multiple OPP tables
Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process)
/ {
cpus {
......@@ -426,40 +447,73 @@ Example 5: Multiple OPP tables
...
cpu-supply = <&cpu_supply>
operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;
operating-points-names = "slow", "fast";
operating-points-v2 = <&cpu0_opp_table_slow>;
};
};
cpu0_opp_table_slow: opp_table_slow {
opp_table {
compatible = "operating-points-v2";
status = "okay";
opp-shared;
opp00 {
opp@600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
*/
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000 915000 925000>;
...
};
opp01 {
opp@800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
* - substrate: supports 16 different substrate versions
* - process: supports 9 different process versions
*/
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <900000 915000 925000>;
...
};
};
};
Example 6: opp-microvolt-<name>, opp-microamp-<name>:
(example: device with two possible microvolt ranges: slow and fast)
cpu0_opp_table_fast: opp_table_fast {
/ {
cpus {
cpu@0 {
compatible = "arm,cortex-a7";
...
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
status = "okay";
opp-shared;
opp10 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
...
opp-microvolt-slow = <900000 915000 925000>;
opp-microvolt-fast = <970000 975000 985000>;
opp-microamp-slow = <70000>;
opp-microamp-fast = <71000>;
};
opp11 {
opp-hz = /bits/ 64 <1100000000>;
...
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <900000 915000 925000>, /* Supply vcc0 */
<910000 925000 935000>; /* Supply vcc1 */
opp-microvolt-fast = <970000 975000 985000>, /* Supply vcc0 */
<960000 965000 975000>; /* Supply vcc1 */
opp-microamp = <70000>; /* Will be used for both slow/fast */
};
};
};
......@@ -999,7 +999,7 @@ from its probe routine to make runtime PM work for the device.
It is important to remember that the driver's runtime_suspend() callback
may be executed right after the usage counter has been decremented, because
user space may already have cuased the pm_runtime_allow() helper function
user space may already have caused the pm_runtime_allow() helper function
unblocking the runtime PM of the device to run via sysfs, so the driver must
be prepared to cope with that.
......
......@@ -371,6 +371,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
- increment the device's usage counter, run pm_runtime_resume(dev) and
return its result
int pm_runtime_get_if_in_use(struct device *dev);
- return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
runtime PM status is RPM_ACTIVE and the runtime PM usage counter is
nonzero, increment the counter and return 1; otherwise return 0 without
changing the counter
void pm_runtime_put_noidle(struct device *dev);
- decrement the device's usage counter
......
......@@ -8466,6 +8466,17 @@ F: fs/timerfd.c
F: include/linux/timer*
F: kernel/time/*timer*
POWER MANAGEMENT CORE
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
L: linux-pm@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
S: Supported
F: drivers/base/power/
F: include/linux/pm.h
F: include/linux/pm_*
F: include/linux/powercap.h
F: drivers/powercap/
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
M: Sebastian Reichel <sre@kernel.org>
M: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
......
......@@ -64,73 +64,73 @@
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp@200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
opp01 {
opp@300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
opp02 {
opp@400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <925000>;
clock-latency-ns = <200000>;
};
opp03 {
opp@500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
opp04 {
opp@600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <975000>;
clock-latency-ns = <200000>;
};
opp05 {
opp@700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <987500>;
clock-latency-ns = <200000>;
};
opp06 {
opp@800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <200000>;
opp-suspend;
};
opp07 {
opp@900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <200000>;
};
opp08 {
opp@1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1087500>;
clock-latency-ns = <200000>;
};
opp09 {
opp@1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <200000>;
};
opp10 {
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1187500>;
clock-latency-ns = <200000>;
};
opp11 {
opp@1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <200000>;
};
opp12 {
opp@1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
opp13 {
opp@1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
......
......@@ -534,9 +534,10 @@ config X86_INTEL_QUARK
config X86_INTEL_LPSS
bool "Intel Low Power Subsystem Support"
depends on ACPI
depends on X86 && ACPI
select COMMON_CLK
select PINCTRL
select IOSF_MBI
---help---
Select to build support for Intel Low Power Subsystem such as
found on Intel Lynxpoint PCH. Selecting this option enables
......
/*
* iosf_mbi.h: Intel OnChip System Fabric MailBox access support
* Intel OnChip System Fabric MailBox access support
*/
#ifndef IOSF_MBI_SYMS_H
......@@ -16,6 +16,18 @@
#define MBI_MASK_LO 0x000000FF
#define MBI_ENABLE 0xF0
/* IOSF SB read/write opcodes */
#define MBI_MMIO_READ 0x00
#define MBI_MMIO_WRITE 0x01
#define MBI_CFG_READ 0x04
#define MBI_CFG_WRITE 0x05
#define MBI_CR_READ 0x06
#define MBI_CR_WRITE 0x07
#define MBI_REG_READ 0x10
#define MBI_REG_WRITE 0x11
#define MBI_ESRAM_READ 0x12
#define MBI_ESRAM_WRITE 0x13
/* Baytrail available units */
#define BT_MBI_UNIT_AUNIT 0x00
#define BT_MBI_UNIT_SMC 0x01
......@@ -28,50 +40,13 @@
#define BT_MBI_UNIT_SATA 0xA3
#define BT_MBI_UNIT_PCIE 0xA6
/* Baytrail read/write opcodes */
#define BT_MBI_AUNIT_READ 0x10
#define BT_MBI_AUNIT_WRITE 0x11
#define BT_MBI_SMC_READ 0x10
#define BT_MBI_SMC_WRITE 0x11
#define BT_MBI_CPU_READ 0x10
#define BT_MBI_CPU_WRITE 0x11
#define BT_MBI_BUNIT_READ 0x10
#define BT_MBI_BUNIT_WRITE 0x11
#define BT_MBI_PMC_READ 0x06
#define BT_MBI_PMC_WRITE 0x07
#define BT_MBI_GFX_READ 0x00
#define BT_MBI_GFX_WRITE 0x01
#define BT_MBI_SMIO_READ 0x06
#define BT_MBI_SMIO_WRITE 0x07
#define BT_MBI_USB_READ 0x06
#define BT_MBI_USB_WRITE 0x07
#define BT_MBI_SATA_READ 0x00
#define BT_MBI_SATA_WRITE 0x01
#define BT_MBI_PCIE_READ 0x00
#define BT_MBI_PCIE_WRITE 0x01
/* Quark available units */
#define QRK_MBI_UNIT_HBA 0x00
#define QRK_MBI_UNIT_HB 0x03
#define QRK_MBI_UNIT_RMU 0x04
#define QRK_MBI_UNIT_MM 0x05
#define QRK_MBI_UNIT_MMESRAM 0x05
#define QRK_MBI_UNIT_SOC 0x31
/* Quark read/write opcodes */
#define QRK_MBI_HBA_READ 0x10
#define QRK_MBI_HBA_WRITE 0x11
#define QRK_MBI_HB_READ 0x10
#define QRK_MBI_HB_WRITE 0x11
#define QRK_MBI_RMU_READ 0x10