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

Pull ACPI and power management updates from Rafael Wysocki:
 "The majority of this material spent some time in linux-next, some of
  it even several weeks.  There are a few relatively fresh commits in
  it, but they are mostly fixes and simple cleanups.

  ACPI took the lead this time, both in terms of the number of commits
  and the number of modified lines of code, cpufreq follows and there
  are a few changes in the PM core and in cpuidle too.

  A new feature that already got some LWN.net's attention is the device
  PM QoS extension allowing latency tolerance requirements to be
  propagated from leaf devices to their ancestors with hardware
  interfaces for specifying latency tolerance.  That should help systems
  with hardware-driven power management to avoid going too far with it
  in cases when there are latency tolerance constraints.

  There also are some significant changes in the ACPI core related to
  the way in which hotplug notifications are handled.  They affect PCI
  hotplug (ACPIPHP) and the ACPI dock station code too.  The bottom line
  is that all those notification now go through the root notify handler
  and are propagated to the interested subsystems by means of callbacks
  instead of having to install a notify handler for each device object
  that we can potentially get hotplug notifications for.

  In addition to that ACPICA will now advertise "Windows 2013"
  compatibility for _OSI, because some systems out there don't work
  correctly if that is not done (some of them don't even boot).

  On the system suspend side of things, all of the device suspend and
  resume callbacks, except for ->prepare() and ->complete(), are now
  going to be executed asynchronously as that turns out to speed up
  system suspend and resume on some platforms quite significantly and we
  have a few more optimizations in that area.

  Apart from that, there are some new device IDs and fixes and cleanups
  all over.  In particular, the system suspend and resume handling by
  cpufreq should be improved and the cpuidle menu governor should be a
  bit more robust now.

  Specifics:

   - Device PM QoS support for latency tolerance constraints on systems
     with hardware interfaces allowing such constraints to be specified.
     That is necessary to prevent hardware-driven power management from
     becoming overly aggressive on some systems and to prevent power
     management features leading to excessive latencies from being used
     in some cases.

   - Consolidation of the handling of ACPI hotplug notifications for
     device objects.  This causes all device hotplug notifications to go
     through the root notify handler (that was executed for all of them
     anyway before) that propagates them to individual subsystems, if
     necessary, by executing callbacks provided by those subsystems
     (those callbacks are associated with struct acpi_device objects
     during device enumeration).  As a result, the code in question
     becomes both smaller in size and more straightforward and all of
     those changes should not affect users.

   - ACPICA update, including fixes related to the handling of _PRT in
     cases when it is broken and the addition of "Windows 2013" to the
     list of supported "features" for _OSI (which is necessary to
     support systems that work incorrectly or don't even boot without
     it).  Changes from Bob Moore and Lv Zheng.

   - Consolidation of ACPI _OST handling from Jiang Liu.

   - ACPI battery and AC fixes allowing unusual system configurations to
     be handled by that code from Alexander Mezin.

   - New device IDs for the ACPI LPSS driver from Chiau Ee Chew.

   - ACPI fan and thermal optimizations related to system suspend and
     resume from Aaron Lu.

   - Cleanups related to ACPI video from Jean Delvare.

   - Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan
     Tianyu, Paul Bolle, Tomasz Nowicki.

   - Intel RAPL (Running Average Power Limits) driver cleanups from
     Jacob Pan.

   - intel_pstate fixes and cleanups from Dirk Brandewie.

   - cpufreq fixes related to system suspend/resume handling from Viresh
     Kumar.

   - cpufreq core fixes and cleanups from Viresh Kumar, Stratos
     Karafotis, Saravana Kannan, Rashika Kheria, Joe Perches.

   - cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob
     Herring.

   - cpuidle fixes related to the menu governor from Tuukka Tikkanen.

   - cpuidle fix related to coupled CPUs handling from Paul Burton.

   - Asynchronous execution of all device suspend and resume callbacks,
     except for ->prepare and ->complete, during system suspend and
     resume from Chuansheng Liu.

   - Delayed resuming of runtime-suspended devices during system suspend
     for the PCI bus type and ACPI PM domain.

   - New set of PM helper routines to allow device runtime PM callbacks
     to be used during system suspend and resume more easily from Ulf
     Hansson.

   - Assorted fixes and cleanups in the PM core from Geert Uytterhoeven,
     Prabhakar Lad, Philipp Zabel, Rashika Kheria, Sebastian Capella.

   - devfreq fix from Saravana Kannan"

* tag 'pm+acpi-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits)
  PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs
  PM / sleep: Correct whitespace errors in <linux/pm.h>
  intel_pstate: Set core to min P state during core offline
  cpufreq: Add stop CPU callback to cpufreq_driver interface
  cpufreq: Remove unnecessary braces
  cpufreq: Fix checkpatch errors and warnings
  cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs
  MAINTAINERS: Reorder maintainer addresses for PM and ACPI
  PM / Runtime: Update runtime_idle() documentation for return value meaning
  video / output: Drop display output class support
  fujitsu-laptop: Drop unneeded include
  acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL
  ACPI / gpu / drm: Stop selecting VIDEO_OUTPUT_CONTROL
  ACPI / video: fix ACPI_VIDEO dependencies
  cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}
  cpufreq: Do not allow ->setpolicy drivers to provide ->target
  cpufreq: arm_big_little: set 'physical_cluster' for each CPU
  cpufreq: arm_big_little: make vexpress driver depend on bL core driver
  ACPI / button: Add ACPI Button event via netlink routine
  ACPI: Remove duplicate definitions of PREFIX
  ...

1 files changed, 43 insertions, 28 deletions

diff --git a/include/linux/pm.h b/include/linux/pm.h
index 8c6583a53a06..d915d0345fa1 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -264,9 +264,9 @@ typedef struct pm_message {
  *      registers, so that it is fully operational.
  *
  * @runtime_idle: Device appears to be inactive and it might be put into a
- *      low-power state if all of the necessary conditions are satisfied.  Check
- *      these conditions and handle the device as appropriate, possibly queueing
- *      a suspend request for it.  The return value is ignored by the PM core.
+ *      low-power state if all of the necessary conditions are satisfied.
+ *      Check these conditions, and return 0 if it's appropriate to let the PM
+ *      core queue a suspend request for the device.
  *
  * Refer to Documentation/power/runtime_pm.txt for more information about the
  * role of the above callbacks in device runtime power management.
@@ -352,7 +352,7 @@ const struct dev_pm_ops name = { \
 
 /*
  * Use this for defining a set of PM operations to be used in all situations
- * (sustem suspend, hibernation or runtime PM).
+ * (system suspend, hibernation or runtime PM).
  * NOTE: In general, system suspend callbacks, .suspend() and .resume(), should
  * be different from the corresponding runtime PM callbacks, .runtime_suspend(),
  * and .runtime_resume(), because .runtime_suspend() always works on an already
@@ -379,7 +379,7 @@ const struct dev_pm_ops name = { \
  *
  * ON           No transition.
  *
- * FREEZE       System is going to hibernate, call ->prepare() and ->freeze()
+ * FREEZE       System is going to hibernate, call ->prepare() and ->freeze()
  *              for all devices.
  *
  * SUSPEND      System is going to suspend, call ->prepare() and ->suspend()
@@ -423,7 +423,7 @@ const struct dev_pm_ops name = { \
 
 #define PM_EVENT_INVALID        (-1)
 #define PM_EVENT_ON             0x0000
-#define PM_EVENT_FREEZE         0x0001
+#define PM_EVENT_FREEZE         0x0001
 #define PM_EVENT_SUSPEND        0x0002
 #define PM_EVENT_HIBERNATE      0x0004
 #define PM_EVENT_QUIESCE        0x0008
@@ -542,6 +542,8 @@ struct dev_pm_info {
         unsigned int            async_suspend:1;
         bool                    is_prepared:1;  /* Owned by the PM core */
         bool                    is_suspended:1; /* Ditto */
+        bool                    is_noirq_suspended:1;
+        bool                    is_late_suspended:1;
         bool                    ignore_children:1;
         bool                    early_init:1;   /* Owned by the PM core */
         spinlock_t              lock;
@@ -582,6 +584,7 @@ struct dev_pm_info {
         unsigned long           accounting_timestamp;
 #endif
         struct pm_subsys_data   *subsys_data;  /* Owned by the subsystem. */
+        void (*set_latency_tolerance)(struct device *, s32);
         struct dev_pm_qos       *qos;
 };
 
@@ -612,11 +615,11 @@ struct dev_pm_domain {
  * message is implicit:
  *
  * ON           Driver starts working again, responding to hardware events
- *              and software requests.  The hardware may have gone through
- *              a power-off reset, or it may have maintained state from the
- *              previous suspend() which the driver will rely on while
- *              resuming.  On most platforms, there are no restrictions on
- *              availability of resources like clocks during resume().
+ *              and software requests.  The hardware may have gone through
+ *              a power-off reset, or it may have maintained state from the
+ *              previous suspend() which the driver will rely on while
+ *              resuming.  On most platforms, there are no restrictions on
+ *              availability of resources like clocks during resume().
  *
  * Other transitions are triggered by messages sent using suspend().  All
  * these transitions quiesce the driver, so that I/O queues are inactive.
@@ -626,21 +629,21 @@ struct dev_pm_domain {
  * differ according to the message:
  *
  * SUSPEND      Quiesce, enter a low power device state appropriate for
- *              the upcoming system state (such as PCI_D3hot), and enable
- *              wakeup events as appropriate.
+ *              the upcoming system state (such as PCI_D3hot), and enable
+ *              wakeup events as appropriate.
  *
  * HIBERNATE    Enter a low power device state appropriate for the hibernation
- *              state (eg. ACPI S4) and enable wakeup events as appropriate.
+ *              state (eg. ACPI S4) and enable wakeup events as appropriate.
  *
  * FREEZE       Quiesce operations so that a consistent image can be saved;
- *              but do NOT otherwise enter a low power device state, and do
- *              NOT emit system wakeup events.
+ *              but do NOT otherwise enter a low power device state, and do
+ *              NOT emit system wakeup events.
  *
  * PRETHAW      Quiesce as if for FREEZE; additionally, prepare for restoring
- *              the system from a snapshot taken after an earlier FREEZE.
- *              Some drivers will need to reset their hardware state instead
- *              of preserving it, to ensure that it's never mistaken for the
- *              state which that earlier snapshot had set up.
+ *              the system from a snapshot taken after an earlier FREEZE.
+ *              Some drivers will need to reset their hardware state instead
+ *              of preserving it, to ensure that it's never mistaken for the
+ *              state which that earlier snapshot had set up.
  *
  * A minimally power-aware driver treats all messages as SUSPEND, fully
  * reinitializes its device during resume() -- whether or not it was reset
@@ -717,14 +720,26 @@ static inline void dpm_for_each_dev(void *data, void (*fn)(struct device *, void
 {
 }
 
-#define pm_generic_prepare      NULL
-#define pm_generic_suspend      NULL
-#define pm_generic_resume       NULL
-#define pm_generic_freeze       NULL
-#define pm_generic_thaw         NULL
-#define pm_generic_restore      NULL
-#define pm_generic_poweroff     NULL
-#define pm_generic_complete     NULL
+#define pm_generic_prepare              NULL
+#define pm_generic_suspend_late         NULL
+#define pm_generic_suspend_noirq        NULL
+#define pm_generic_suspend              NULL
+#define pm_generic_resume_early         NULL
+#define pm_generic_resume_noirq         NULL
+#define pm_generic_resume               NULL
+#define pm_generic_freeze_noirq         NULL
+#define pm_generic_freeze_late          NULL
+#define pm_generic_freeze               NULL
+#define pm_generic_thaw_noirq           NULL
+#define pm_generic_thaw_early           NULL
+#define pm_generic_thaw                 NULL
+#define pm_generic_restore_noirq        NULL
+#define pm_generic_restore_early        NULL
+#define pm_generic_restore              NULL
+#define pm_generic_poweroff_noirq       NULL
+#define pm_generic_poweroff_late        NULL
+#define pm_generic_poweroff             NULL
+#define pm_generic_complete             NULL
 #endif /* !CONFIG_PM_SLEEP */
 
 /* How to reorder dpm_list after device_move() */