1. 20 May, 2014 2 commits
  2. 16 May, 2014 4 commits
    • Rafael J. Wysocki's avatar
      PM / sleep: Update device PM documentation to cover direct_complete · f71495f3
      Rafael J. Wysocki authored
      Update the device PM documentation in devices.txt and runtime_pm.txt
      to reflect the changes in the system suspend and resume handling
      related to the introduction of the new power.direct_complete flag.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      f71495f3
    • Rafael J. Wysocki's avatar
      PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily · aae4518b
      Rafael J. Wysocki authored
      Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
      resume all runtime-suspended devices during system suspend, mostly
      because those devices may need to be reprogrammed due to different
      wakeup settings for system sleep and for runtime PM.
      
      For some devices, though, it's OK to remain in runtime suspend
      throughout a complete system suspend/resume cycle (if the device was in
      runtime suspend at the start of the cycle).  We would like to do this
      whenever possible, to avoid the overhead of extra power-up and power-down
      events.
      
      However, problems may arise because the device's descendants may require
      it to be at full power at various points during the cycle.  Therefore the
      most straightforward way to do this safely is if the device and all its
      descendants can remain runtime suspended until the complete stage of
      system resume.
      
      To this end, introduce a new device PM flag, power.direct_complete
      and modify the PM core to use that flag as follows.
      
      If the ->prepare() callback of a device returns a positive number,
      the PM core will regard that as an indication that it may leave the
      device runtime-suspended.  It will then check if the system power
      transition in progress is a suspend (and not hibernation in particular)
      and if the device is, indeed, runtime-suspended.  In that case, the PM
      core will set the device's power.direct_complete flag.  Otherwise it
      will clear power.direct_complete for the device and it also will later
      clear it for the device's parent (if there's one).
      
      Next, the PM core will not invoke the ->suspend() ->suspend_late(),
      ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
      callbacks for all devices having power.direct_complete set.  It
      will invoke their ->complete() callbacks, however, and those
      callbacks are then responsible for resuming the devices as
      appropriate, if necessary.  For example, in some cases they may
      need to queue up runtime resume requests for the devices using
      pm_request_resume().
      
      Changelog partly based on an Alan Stern's description of the idea
      (http://marc.info/?l=linux-pm&m=139940466625569&w=2).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      aae4518b
    • Dan Carpenter's avatar
      PM / hibernate: Fix memory corruption in resumedelay_setup() · f6514be5
      Dan Carpenter authored
      In the original code "resume_delay" is an int so on 64 bits, the call to
      kstrtoul() will cause memory corruption.  We may as well fix a style
      issue here as well and make "resume_delay" unsigned int, since that's
      what we pass to ssleep().
      
      Fixes: 317cf7e5 (PM / hibernate: convert simple_strtoul to kstrtoul)
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f6514be5
    • Rafael J. Wysocki's avatar
      ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state · 1f0b6386
      Rafael J. Wysocki authored
      The "freeze" sleep state suffers from the same issue that was
      addressed by commit ad07277e (ACPI / PM: Hold acpi_scan_lock over
      system PM transitions) for ACPI sleep states, that is, things break
      if ->remove() is called for devices whose system resume callbacks
      haven't been executed yet.
      
      It also can be addressed in the same way, by holding the ACPI scan
      lock over the "freeze" sleep state and PM transitions to and from
      that state, but ->begin() and ->end() platform operations for the
      "freeze" sleep state are needed for this purpose.
      
      This change has been tested on Acer Aspire S5 with Thunderbolt.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1f0b6386
  3. 09 May, 2014 8 commits
  4. 08 May, 2014 9 commits
  5. 07 May, 2014 6 commits
  6. 06 May, 2014 11 commits