Skip to content

L
linux
Switch branch/tag
  1. 06 Jun, 2014 2 commits
  3. 31 May, 2014 1 commit
  5. 30 May, 2014 1 commit
  7. 26 May, 2014 3 commits
    • Rafael J. Wysocki's avatar
      PM / sleep: Introduce command line argument for sleep state enumeration · 0399d4db
      Rafael J. Wysocki authored 
      On some systems the platform doesn't support neither
PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
only available system sleep state.  However, some user space frameworks
only use the "mem" and (sometimes) "standby" sleep state labels, so
the users of those systems need to modify user space in order to be
able to use system suspend at all and that is not always possible.

For this reason, add a new kernel command line argument,
relative_sleep_states, allowing the users of those systems to change
the way in which the kernel assigns labels to system sleep states.
Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
labels will enumerate the available system sleem states from the
deepest to the shallowest, respectively, so that "mem" is always
present in /sys/power/state and the other state strings may or may
not be presend depending on what is supported by the platform.

Update system sleep states documentation to reflect this change.
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0399d4db
    • Rafael J. Wysocki's avatar
      PM / sleep: Use valid_state() for platform-dependent sleep states only · 43e8317b
      Rafael J. Wysocki authored 
      Use the observation that, for platform-dependent sleep states
(PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
always supported or always unsupported and store that information
in pm_states[] instead of calling valid_state() every time we
need to check it.

Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
directly into enter_state().
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      43e8317b
    • Rafael J. Wysocki's avatar
      PM / sleep: Add state field to pm_states[] entries · 27ddcc65
      Rafael J. Wysocki authored 
      To allow sleep states corresponding to the "mem", "standby" and
"freeze" lables to be different from the pm_states[] indexes of
those strings, introduce struct pm_sleep_state, consisting of
a string label and a state number, and turn pm_states[] into an
array of objects of that type.

This modification should not lead to any functional changes.
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      27ddcc65
  9. 20 May, 2014 3 commits
  11. 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
  13. 09 May, 2014 8 commits
  15. 08 May, 2014 9 commits
  17. 07 May, 2014 6 commits
  19. 06 May, 2014 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7