Merge tag 'pm+acpi-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (43c9fad9) · Commits · e / devices / android_kernel_teracube_2e

Documentation/acpi/enumeration.txt

+54 −3

Original line number	Diff line number	Diff line
		@@ -42,7 +42,7 @@ Adding ACPI support for an existing driver should be pretty
		straightforward. Here is the simplest example:

		#ifdef CONFIG_ACPI
		static struct acpi_device_id mydrv_acpi_match[] = {
		static const struct acpi_device_id mydrv_acpi_match[] = {
		/* ACPI IDs here */
		{ }
		};
		@@ -166,7 +166,7 @@ the platform device drivers. Below is an example where we add ACPI support
		to at25 SPI eeprom driver (this is meant for the above ACPI snippet):

		#ifdef CONFIG_ACPI
		static struct acpi_device_id at25_acpi_match[] = {
		static const struct acpi_device_id at25_acpi_match[] = {
		{ "AT25", 0 },
		{ },
		};
		@@ -230,7 +230,7 @@ Below is an example of how to add ACPI support to the existing mpu3050
		input driver:

		#ifdef CONFIG_ACPI
		static struct acpi_device_id mpu3050_acpi_match[] = {
		static const struct acpi_device_id mpu3050_acpi_match[] = {
		{ "MPU3050", 0 },
		{ },
		};
		@@ -359,3 +359,54 @@ the id should be set like:
		The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
		the MFD device and if found, that ACPI companion device is bound to the
		resulting child platform device.

		Device Tree namespace link device ID
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		The Device Tree protocol uses device indentification based on the "compatible"
		property whose value is a string or an array of strings recognized as device
		identifiers by drivers and the driver core. The set of all those strings may be
		regarded as a device indentification namespace analogous to the ACPI/PNP device
		ID namespace. Consequently, in principle it should not be necessary to allocate
		a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing
		identification string in the Device Tree (DT) namespace, especially if that ID
		is only needed to indicate that a given device is compatible with another one,
		presumably having a matching driver in the kernel already.

		In ACPI, the device identification object called _CID (Compatible ID) is used to
		list the IDs of devices the given one is compatible with, but those IDs must
		belong to one of the namespaces prescribed by the ACPI specification (see
		Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them.
		Moreover, the specification mandates that either a _HID or an _ADR identificaion
		object be present for all ACPI objects representing devices (Section 6.1 of ACPI
		6.0). For non-enumerable bus types that object must be _HID and its value must
		be a device ID from one of the namespaces prescribed by the specification too.

		The special DT namespace link device ID, PRP0001, provides a means to use the
		existing DT-compatible device identification in ACPI and to satisfy the above
		requirements following from the ACPI specification at the same time. Namely,
		if PRP0001 is returned by _HID, the ACPI subsystem will look for the
		"compatible" property in the device object's _DSD and will use the value of that
		property to identify the corresponding device in analogy with the original DT
		device identification algorithm. If the "compatible" property is not present
		or its value is not valid, the device will not be enumerated by the ACPI
		subsystem. Otherwise, it will be enumerated automatically as a platform device
		(except when an I2C or SPI link from the device to its parent is present, in
		which case the ACPI core will leave the device enumeration to the parent's
		driver) and the identification strings from the "compatible" property value will
		be used to find a driver for the device along with the device IDs listed by _CID
		(if present).

		Analogously, if PRP0001 is present in the list of device IDs returned by _CID,
		the identification strings listed by the "compatible" property value (if present
		and valid) will be used to look for a driver matching the device, but in that
		case their relative priority with respect to the other device IDs listed by
		_HID and _CID depends on the position of PRP0001 in the _CID return package.
		Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID
		return package will be checked first. Also in that case the bus type the device
		will be enumerated to depends on the device ID returned by _HID.

		It is valid to define device objects with a _HID returning PRP0001 and without
		the "compatible" property in the _DSD or a _CID as long as one of their
		ancestors provides a _DSD with a valid "compatible" property. Such device
		objects are then simply regarded as additional "blocks" providing hierarchical
		configuration information to the driver of the composite ancestor device.

Documentation/cpu-freq/user-guide.txt

+0 −2

Original line number	Diff line number	Diff line
		@@ -196,8 +196,6 @@ affected_cpus : List of Online CPUs that require software
		related_cpus : List of Online + Offline CPUs that need software
		coordination of frequency.

		scaling_driver : Hardware driver for cpufreq.

		scaling_cur_freq : Current frequency of the CPU as determined by
		the governor and cpufreq core, in KHz. This is
		the frequency the kernel thinks the CPU runs

Documentation/devicetree/bindings/power/opp.txt

+444 −4

Original line number	Diff line number	Diff line
		* Generic OPP Interface
		Generic OPP (Operating Performance Points) Bindings
		----------------------------------------------------

		SoCs have a standard set of tuples consisting of frequency and
		voltage pairs that the device will support per voltage domain. These
		are called Operating Performance Points or OPPs.
		Devices work at voltage-current-frequency combinations and some implementations
		have the liberty of choosing these. These combinations are called Operating
		Performance Points aka OPPs. This document defines bindings for these OPPs
		applicable across wide range of devices. For illustration purpose, this document
		uses CPU as a device.

		This document contain multiple versions of OPP binding and only one of them
		should be used per device.

		Binding 1: operating-points
		============================

		This binding only supports voltage-frequency pairs.

		Properties:
		- operating-points: An array of 2-tuples items, and each item consists
		@@ -23,3 +34,432 @@ cpu@0 {
		198000 850000
		>;
		};


		Binding 2: operating-points-v2
		============================

		* Property: operating-points-v2

		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
		properties:

		Required properties:
		- compatible: Allow OPPs to express their compatibility. It should be:
		"operating-points-v2".

		- OPP nodes: One or more OPP nodes describing voltage-current-frequency
		combinations. Their name isn't significant but their phandle can be used to
		reference an OPP.

		Optional properties:
		- opp-shared: Indicates that device nodes using this OPP Table Node's phandle
		switch their DVFS state together, i.e. they share clock/voltage/current lines.
		Missing property means devices have independent clock/voltage/current lines,
		but they share OPP tables.

		- status: Marks the OPP table enabled/disabled.


		* OPP Node

		This defines voltage-current-frequency combinations along with other related
		properties.

		Required properties:
		- opp-hz: Frequency in Hz

		Optional properties:
		- opp-microvolt: voltage in micro Volts.

		A single regulator's voltage is specified with an array of size one or three.
		Single entry is for target voltage and three entries are for <target min max>
		voltages.

		Entries for multiple regulators must be present in the same order as
		regulators are specified in device's DT node.

		- 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
		set the most efficient regulator operating mode.

		Should only be set if opp-microvolt is set for the OPP.

		Entries for multiple regulators must be present in the same order as
		regulators are specified in device's DT node. If this property isn't required
		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.

		- clock-latency-ns: Specifies the maximum possible transition latency (in
		nanoseconds) for switching to this OPP from any other OPP.

		- turbo-mode: Marks the OPP to be used only for turbo modes. Turbo mode is
		available on some platforms, where the device can run over its operating
		frequency for a short duration of time limited by the device's power, current
		and thermal limits.

		- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
		the table should have this.

		- status: Marks the node enabled/disabled.

		Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.

		/ {
		cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
		compatible = "arm,cortex-a9";
		reg = <0>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 0>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply0>;
		operating-points-v2 = <&cpu0_opp_table>;
		};

		cpu@1 {
		compatible = "arm,cortex-a9";
		reg = <1>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 0>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply0>;
		operating-points-v2 = <&cpu0_opp_table>;
		};
		};

		cpu0_opp_table: opp_table0 {
		compatible = "operating-points-v2";
		opp-shared;

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000 975000 985000>;
		opp-microamp = <70000>;
		clock-latency-ns = <300000>;
		opp-suspend;
		};
		opp01 {
		opp-hz = <1100000000>;
		opp-microvolt = <980000 1000000 1010000>;
		opp-microamp = <80000>;
		clock-latency-ns = <310000>;
		};
		opp02 {
		opp-hz = <1200000000>;
		opp-microvolt = <1025000>;
		clock-latency-ns = <290000>;
		turbo-mode;
		};
		};
		};

		Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
		independently.

		/ {
		cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
		compatible = "qcom,krait";
		reg = <0>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 0>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply0>;
		operating-points-v2 = <&cpu_opp_table>;
		};

		cpu@1 {
		compatible = "qcom,krait";
		reg = <1>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 1>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply1>;
		operating-points-v2 = <&cpu_opp_table>;
		};

		cpu@2 {
		compatible = "qcom,krait";
		reg = <2>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 2>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply2>;
		operating-points-v2 = <&cpu_opp_table>;
		};

		cpu@3 {
		compatible = "qcom,krait";
		reg = <3>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 3>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply3>;
		operating-points-v2 = <&cpu_opp_table>;
		};
		};

		cpu_opp_table: opp_table {
		compatible = "operating-points-v2";

		/*
		* Missing opp-shared property means CPUs switch DVFS states
		* independently.
		*/

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000 975000 985000>;
		opp-microamp = <70000>;
		clock-latency-ns = <300000>;
		opp-suspend;
		};
		opp01 {
		opp-hz = <1100000000>;
		opp-microvolt = <980000 1000000 1010000>;
		opp-microamp = <80000>;
		clock-latency-ns = <310000>;
		};
		opp02 {
		opp-hz = <1200000000>;
		opp-microvolt = <1025000>;
		opp-microamp = <90000;
		lock-latency-ns = <290000>;
		turbo-mode;
		};
		};
		};

		Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
		DVFS state together.

		/ {
		cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
		compatible = "arm,cortex-a7";
		reg = <0>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 0>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply0>;
		operating-points-v2 = <&cluster0_opp>;
		};

		cpu@1 {
		compatible = "arm,cortex-a7";
		reg = <1>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 0>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply0>;
		operating-points-v2 = <&cluster0_opp>;
		};

		cpu@100 {
		compatible = "arm,cortex-a15";
		reg = <100>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 1>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply1>;
		operating-points-v2 = <&cluster1_opp>;
		};

		cpu@101 {
		compatible = "arm,cortex-a15";
		reg = <101>;
		next-level-cache = <&L2>;
		clocks = <&clk_controller 1>;
		clock-names = "cpu";
		cpu-supply = <&cpu_supply1>;
		operating-points-v2 = <&cluster1_opp>;
		};
		};

		cluster0_opp: opp_table0 {
		compatible = "operating-points-v2";
		opp-shared;

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000 975000 985000>;
		opp-microamp = <70000>;
		clock-latency-ns = <300000>;
		opp-suspend;
		};
		opp01 {
		opp-hz = <1100000000>;
		opp-microvolt = <980000 1000000 1010000>;
		opp-microamp = <80000>;
		clock-latency-ns = <310000>;
		};
		opp02 {
		opp-hz = <1200000000>;
		opp-microvolt = <1025000>;
		opp-microamp = <90000>;
		clock-latency-ns = <290000>;
		turbo-mode;
		};
		};

		cluster1_opp: opp_table1 {
		compatible = "operating-points-v2";
		opp-shared;

		opp10 {
		opp-hz = <1300000000>;
		opp-microvolt = <1045000 1050000 1055000>;
		opp-microamp = <95000>;
		clock-latency-ns = <400000>;
		opp-suspend;
		};
		opp11 {
		opp-hz = <1400000000>;
		opp-microvolt = <1075000>;
		opp-microamp = <100000>;
		clock-latency-ns = <400000>;
		};
		opp12 {
		opp-hz = <1500000000>;
		opp-microvolt = <1010000 1100000 1110000>;
		opp-microamp = <95000>;
		clock-latency-ns = <400000>;
		turbo-mode;
		};
		};
		};

		Example 4: Handling multiple regulators

		/ {
		cpus {
		cpu@0 {
		compatible = "arm,cortex-a7";
		...

		cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
		operating-points-v2 = <&cpu0_opp_table>;
		};
		};

		cpu0_opp_table: opp_table0 {
		compatible = "operating-points-v2";
		opp-shared;

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000>, /* Supply 0 */
		<960000>, /* Supply 1 */
		<960000>; /* Supply 2 */
		opp-microamp = <70000>, /* Supply 0 */
		<70000>, /* Supply 1 */
		<70000>; /* Supply 2 */
		clock-latency-ns = <300000>;
		};

		/* OR */

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000 975000 985000>, /* Supply 0 */
		<960000 965000 975000>, /* Supply 1 */
		<960000 965000 975000>; /* Supply 2 */
		opp-microamp = <70000>, /* Supply 0 */
		<70000>, /* Supply 1 */
		<70000>; /* Supply 2 */
		clock-latency-ns = <300000>;
		};

		/* OR */

		opp00 {
		opp-hz = <1000000000>;
		opp-microvolt = <970000 975000 985000>, /* Supply 0 */
		<960000 965000 975000>, /* Supply 1 */
		<960000 965000 975000>; /* Supply 2 */
		opp-microamp = <70000>, /* Supply 0 */
		<0>, /* Supply 1 doesn't need this */
		<70000>; /* Supply 2 */
		clock-latency-ns = <300000>;
		};
		};
		};

		Example 5: Multiple OPP tables

		/ {
		cpus {
		cpu@0 {
		compatible = "arm,cortex-a7";
		...

		cpu-supply = <&cpu_supply>
		operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;
		operating-points-names = "slow", "fast";
		};
		};

		cpu0_opp_table_slow: opp_table_slow {
		compatible = "operating-points-v2";
		status = "okay";
		opp-shared;

		opp00 {
		opp-hz = <600000000>;
		...
		};

		opp01 {
		opp-hz = <800000000>;
		...
		};
		};

		cpu0_opp_table_fast: opp_table_fast {
		compatible = "operating-points-v2";
		status = "okay";
		opp-shared;

		opp10 {
		opp-hz = <1000000000>;
		...
		};

		opp11 {
		opp-hz = <1100000000>;
		...
		};
		};
		};

Documentation/kernel-parameters.txt

+31 −31

Original line number	Diff line number	Diff line
		@@ -179,11 +179,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.

		See also Documentation/power/runtime_pm.txt, pci=noacpi

		acpi_rsdp= [ACPI,EFI,KEXEC]
		Pass the RSDP address to the kernel, mostly used
		on machines running EFI runtime service to boot the
		second kernel for kdump.

		acpi_apic_instance= [ACPI, IOAPIC]
		Format: <int>
		2: use 2nd APIC table, if available
		@@ -197,6 +192,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		(e.g. thinkpad_acpi, sony_acpi, etc.) instead
		of the ACPI video.ko driver.

		acpica_no_return_repair [HW, ACPI]
		Disable AML predefined validation mechanism
		This mechanism can repair the evaluation result to make
		the return objects more ACPI specification compliant.
		This option is useful for developers to identify the
		root cause of an AML interpreter issue when the issue
		has something to do with the repair mechanism.

		acpi.debug_layer= [HW,ACPI,ACPI_DEBUG]
		acpi.debug_level= [HW,ACPI,ACPI_DEBUG]
		Format: <int>
		@@ -225,6 +228,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		unusable. The "log_buf_len" parameter may be useful
		if you need to capture more output.

		acpi_enforce_resources= [ACPI]
		{ strict \| lax \| no }
		Check for resource conflicts between native drivers
		and ACPI OperationRegions (SystemIO and SystemMemory
		only). IO ports and memory declared in ACPI might be
		used by the ACPI subsystem in arbitrary AML code and
		can interfere with legacy drivers.
		strict (default): access to resources claimed by ACPI
		is denied; legacy drivers trying to access reserved
		resources will fail to bind to device using them.
		lax: access to resources claimed by ACPI is allowed;
		legacy drivers trying to access reserved resources
		will bind successfully but a warning message is logged.
		no: ACPI OperationRegions are not marked as reserved,
		no further checks are performed.

		acpi_force_table_verification [HW,ACPI]
		Enable table checksum verification during early stage.
		By default, this is disabled due to x86 early mapping
		@@ -253,6 +272,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		This feature is enabled by default.
		This option allows to turn off the feature.

		acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump
		kernels.

		acpi_no_static_ssdt [HW,ACPI]
		Disable installation of static SSDTs at early boot time
		By default, SSDTs contained in the RSDT/XSDT will be
		@@ -263,13 +285,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		dynamic table installation which will install SSDT
		tables to /sys/firmware/acpi/tables/dynamic.

		acpica_no_return_repair [HW, ACPI]
		Disable AML predefined validation mechanism
		This mechanism can repair the evaluation result to make
		the return objects more ACPI specification compliant.
		This option is useful for developers to identify the
		root cause of an AML interpreter issue when the issue
		has something to do with the repair mechanism.
		acpi_rsdp= [ACPI,EFI,KEXEC]
		Pass the RSDP address to the kernel, mostly used
		on machines running EFI runtime service to boot the
		second kernel for kdump.

		acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS
		Format: To spoof as Windows 98: ="Microsoft Windows"
		@@ -365,25 +384,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
		Use timer override. For some broken Nvidia NF5 boards
		that require a timer override, but don't have HPET

		acpi_enforce_resources= [ACPI]
		{ strict \| lax \| no }
		Check for resource conflicts between native drivers
		and ACPI OperationRegions (SystemIO and SystemMemory
		only). IO ports and memory declared in ACPI might be
		used by the ACPI subsystem in arbitrary AML code and
		can interfere with legacy drivers.
		strict (default): access to resources claimed by ACPI
		is denied; legacy drivers trying to access reserved
		resources will fail to bind to device using them.
		lax: access to resources claimed by ACPI is allowed;
		legacy drivers trying to access reserved resources
		will bind successfully but a warning message is logged.
		no: ACPI OperationRegions are not marked as reserved,
		no further checks are performed.

		acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump
		kernels.

		add_efi_memmap [EFI; X86] Include EFI memory map in
		kernel's map of available physical RAM.

Documentation/power/runtime_pm.txt

+6 −0

Original line number	Diff line number	Diff line
		@@ -556,6 +556,12 @@ helper functions described in Section 4. In that case, pm_runtime_resume()
		should be used. Of course, for this purpose the device's runtime PM has to be
		enabled earlier by calling pm_runtime_enable().

		Note, if the device may execute pm_runtime calls during the probe (such as
		if it is registers with a subsystem that may call back in) then the
		pm_runtime_get_sync() call paired with a pm_runtime_put() call will be
		appropriate to ensure that the device is not put back to sleep during the
		probe. This can happen with systems such as the network device layer.

		It may be desirable to suspend the device once ->probe() has finished.
		Therefore the driver core uses the asyncronous pm_request_idle() to submit a
		request to execute the subsystem-level idle callback for the device at that