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

Pull power management and ACPI updates from Rafael J Wysocki:

 - ARM big.LITTLE cpufreq driver from Viresh Kumar.

 - exynos5440 cpufreq driver from Amit Daniel Kachhap.

 - cpufreq core cleanup and code consolidation from Viresh Kumar and
   Stratos Karafotis.

 - cpufreq scalability improvement from Nathan Zimmer.

 - AMD "frequency sensitivity feedback" powersave bias for the ondemand
   cpufreq governor from Jacob Shin.

 - cpuidle code consolidation and cleanups from Daniel Lezcano.

 - ARM OMAP cpuidle fixes from Santosh Shilimkar and Daniel Lezcano.

 - ACPICA fixes and other improvements from Bob Moore, Jung-uk Kim, Lv
   Zheng, Yinghai Lu, Tang Chen, Colin Ian King, and Linn Crosetto.

 - ACPI core updates related to hotplug from Toshi Kani, Paul Bolle,
   Yasuaki Ishimatsu, and Rafael J Wysocki.

 - Intel Lynxpoint LPSS (Low-Power Subsystem) support improvements from
   Rafael J Wysocki and Andy Shevchenko.

* tag 'pm+acpi-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (192 commits)
  cpufreq: Revert incorrect commit 5800043
  cpufreq: MAINTAINERS: Add co-maintainer
  cpuidle: add maintainer entry
  ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points
  ARM: s3c64xx: cpuidle: use init/exit common routine
  cpufreq: pxa2xx: initialize variables
  ACPI: video: correct acpi_video_bus_add error processing
  SH: cpuidle: use init/exit common routine
  ARM: S5pv210: compiling issue, ARM_S5PV210_CPUFREQ needs CONFIG_CPU_FREQ_TABLE=y
  ACPI: Fix wrong parameter passed to memblock_reserve
  cpuidle: fix comment format
  pnp: use %*phC to dump small buffers
  isapnp: remove debug leftovers
  ARM: imx: cpuidle: use init/exit common routine
  ARM: davinci: cpuidle: use init/exit common routine
  ARM: kirkwood: cpuidle: use init/exit common routine
  ARM: calxeda: cpuidle: use init/exit common routine
  ARM: tegra: cpuidle: use init/exit common routine for tegra3
  ARM: tegra: cpuidle: use init/exit common routine for tegra2
  ARM: OMAP4: cpuidle: use init/exit common routine
  ...

9 files changed, 215 insertions, 5 deletions

diff --git a/Documentation/ABI/testing/sysfs-devices-lpss_ltr b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
new file mode 100644
index 000000000000..ea9298d9bbaf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
@@ -0,0 +1,44 @@
+What:           /sys/devices/.../lpss_ltr/
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/ directory is only present for
+                devices included into the Intel Lynxpoint Low Power Subsystem
+                (LPSS).  If present, it contains attributes containing the LTR
+                mode and the values of LTR registers of the device.
+
+What:           /sys/devices/.../lpss_ltr/ltr_mode
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
+                integer number (0 or 1) indicating whether or not the devices'
+                LTR functionality is working in the software mode (1).
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
+
+What:           /sys/devices/.../lpss_ltr/auto_ltr
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+                current value of the device's AUTO_LTR register (raw)
+                represented as an 8-digit hexadecimal number.
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
+
+What:           /sys/devices/.../lpss_ltr/sw_ltr
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+                current value of the device's SW_LTR register (raw) represented
+                as an 8-digit hexadecimal number.
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
new file mode 100644
index 000000000000..e0588feeb6e1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
@@ -0,0 +1,13 @@
+What:           /sys/devices/.../power_resources_wakeup/
+Date:           April 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_wakeup/ directory is only
+                present for device objects representing ACPI device nodes that
+                require ACPI power resources for wakeup signaling.
+
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be able to signal wakeup.  The names of
+                the links are the same as the names of the directories they
+                point to.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index dd930c8db41f..ce9bee98b43b 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -18,6 +18,32 @@ Description:
                 yoffset: The number of pixels between the top of the screen
                          and the top edge of the image.
 
+What:           /sys/firmware/acpi/hotplug/
+Date:           February 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                There are separate hotplug profiles for different classes of
+                devices supported by ACPI, such as containers, memory modules,
+                processors, PCI root bridges etc.  A hotplug profile for a given
+                class of devices is a collection of settings defining the way
+                that class of devices will be handled by the ACPI core hotplug
+                code.  Those profiles are represented in sysfs as subdirectories
+                of /sys/firmware/acpi/hotplug/.
+
+                The following setting is available to user space for each
+                hotplug profile:
+
+                enabled: If set, the ACPI core will handle notifications of
+                        hotplug events associated with the given class of
+                        devices and will allow those devices to be ejected with
+                        the help of the _EJ0 control method.  Unsetting it
+                        effectively disables hotplug for the correspoinding
+                        class of devices.
+
+                The value of the above attribute is an integer number: 1 (set)
+                or 0 (unset).  Attempts to write any other values to it will
+                cause -EINVAL to be returned.
+
 What:           /sys/firmware/acpi/interrupts/
 Date:           February 2008
 Contact:        Len Brown <lenb@kernel.org>
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index 72f70b16d299..a3585eac83b6 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -108,8 +108,9 @@ policy->governor		must contain the "default policy" for
                                 cpufreq_driver.target is called with
                                 these values.
 
-For setting some of these values, the frequency table helpers might be
-helpful. See the section 2 for more information on them.
+For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
+frequency table helpers might be helpful. See the section 2 for more information
+on them.
 
 SMP systems normally have same clock source for a group of cpus. For these the
 .init() would be called only once for the first online cpu. Here the .init()
@@ -184,10 +185,10 @@ the reference implementation in drivers/cpufreq/longrun.c
 As most cpufreq processors only allow for being set to a few specific
 frequencies, a "frequency table" with some functions might assist in
 some work of the processor driver. Such a "frequency table" consists
-of an array of struct cpufreq_freq_table entries, with any value in
+of an array of struct cpufreq_frequency_table entries, with any value in
 "index" you want to use, and the corresponding frequency in
 "frequency". At the end of the table, you need to add a
-cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
+cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
 if you want to skip one entry in the table, set the frequency to 
 CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
 order.
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index c7a2eb8450c2..66f9cc310686 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -167,6 +167,27 @@ of load evaluation and helping the CPU stay at its top speed when truly
 busy, rather than shifting back and forth in speed. This tunable has no
 effect on behavior at lower speeds/lower CPU loads.
 
+powersave_bias: this parameter takes a value between 0 to 1000. It
+defines the percentage (times 10) value of the target frequency that
+will be shaved off of the target. For example, when set to 100 -- 10%,
+when ondemand governor would have targeted 1000 MHz, it will target
+1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
+(disabled) by default.
+When AMD frequency sensitivity powersave bias driver --
+drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
+defines the workload frequency sensitivity threshold in which a lower
+frequency is chosen instead of ondemand governor's original target.
+The frequency sensitivity is a hardware reported (on AMD Family 16h
+Processors and above) value between 0 to 100% that tells software how
+the performance of the workload running on a CPU will change when
+frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
+will not perform any better on higher core frequency, whereas a
+workload with sensitivity of 100% (CPU-bound) will perform better
+higher the frequency. When the driver is loaded, this is set to 400
+by default -- for CPUs running workloads with sensitivity value below
+40%, a lower frequency is chosen. Unloading the driver or writing 0
+will disable this feature.
+
 
 2.5 Conservative
 ----------------
@@ -191,6 +212,12 @@ governor but for the opposite direction.  For example when set to its
 default value of '20' it means that if the CPU usage needs to be below
 20% between samples to have the frequency decreased.
 
+sampling_down_factor: similar functionality as in "ondemand" governor.
+But in "conservative", it controls the rate at which the kernel makes
+a decision on when to decrease the frequency while running in any
+speed. Load for frequency increase is still evaluated every
+sampling rate.
+
 3. The Governor Interface in the CPUfreq Core
 =============================================
 
diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09ece931..1b0d81d92583 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
 cpuidle driver initializes the cpuidle_device structure for each CPU device
 and registers with cpuidle using cpuidle_register_device.
 
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
 It can also support the dynamic changes (like battery <-> AC), by using
 cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
 cpuidle_resume_and_unlock.
 
 Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+                            const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
 extern int cpuidle_register_driver(struct cpuidle_driver *drv);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
new file mode 100644
index 000000000000..0715695e94a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -0,0 +1,65 @@
+Generic ARM big LITTLE cpufreq driver's DT glue
+-----------------------------------------------
+
+This is DT specific glue layer for generic cpufreq driver for big LITTLE
+systems.
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
+
+FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster
+must be present contiguously. Generic DT driver will check only node 'x' for
+cpu:x.
+
+Required properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
+  for details
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+  in unit of nanoseconds.
+
+Examples:
+
+cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        cpu@0 {
+                compatible = "arm,cortex-a15";
+                reg = <0>;
+                next-level-cache = <&L2>;
+                operating-points = <
+                        /* kHz    uV */
+                        792000  1100000
+                        396000  950000
+                        198000  850000
+                >;
+                clock-latency = <61036>; /* two CLK32 periods */
+        };
+
+        cpu@1 {
+                compatible = "arm,cortex-a15";
+                reg = <1>;
+                next-level-cache = <&L2>;
+        };
+
+        cpu@100 {
+                compatible = "arm,cortex-a7";
+                reg = <100>;
+                next-level-cache = <&L2>;
+                operating-points = <
+                        /* kHz    uV */
+                        792000  950000
+                        396000  750000
+                        198000  450000
+                >;
+                clock-latency = <61036>; /* two CLK32 periods */
+        };
+
+        cpu@101 {
+                compatible = "arm,cortex-a7";
+                reg = <101>;
+                next-level-cache = <&L2>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 4416ccc33472..051f764bedb8 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -32,7 +32,7 @@ cpus {
                         396000  950000
                         198000  850000
                 >;
-                transition-latency = <61036>; /* two CLK32 periods */
+                clock-latency = <61036>; /* two CLK32 periods */
         };
 
         cpu@1 {
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000000000000..caff1a57436f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+-------------------
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned into,
+        in the decreasing order. Frequency should be in KHz units and voltage
+        should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+--------
+        cpufreq@160000 {
+                compatible = "samsung,exynos5440-cpufreq";
+                reg = <0x160000 0x1000>;
+                interrupts = <0 57 0>;
+                operating-points = <
+                                1000000 975000
+                                800000  925000>;
+                clock-latency = <100000>;
+        };