An error occurred fetching the project authors.
  1. 24 Jul, 2017 1 commit
  2. 22 Jul, 2017 3 commits
  3. 14 Jun, 2017 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle · 33e4f80e
      Rafael J. Wysocki authored
      The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
      during suspend-to-idle transitions and, consequently, any events
      signaled through it wake up the system from that state.  However,
      on some systems some of the events signaled via the ACPI SCI while
      suspended to idle should not cause the system to wake up.  In fact,
      quite often they should just be discarded.
      
      Arguably, systems should not resume entirely on such events, but in
      order to decide which events really should cause the system to resume
      and which are spurious, it is necessary to resume up to the point
      when ACPI SCIs are actually handled and processed, which is after
      executing dpm_resume_noirq() in the system resume path.
      
      For this reasons, add a loop around freeze_enter() in which the
      platforms can process events signaled via multiplexed IRQ lines
      like the ACPI SCI and add suspend-to-idle hooks that can be
      used for this purpose to struct platform_freeze_ops.
      
      In the ACPI case, the ->wake hook is used for checking if the SCI
      has triggered while suspended and deferring the interrupt-induced
      system wakeup until the events signaled through it are actually
      processed sufficiently to decide whether or not the system should
      resume.  In turn, the ->sync hook allows all of the relevant event
      queues to be flushed so as to prevent events from being missed due
      to race conditions.
      
      In addition to that, some ACPI code processing wakeup events needs
      to be modified to use the "hard" version of wakeup triggers, so that
      it will cause a system resume to happen on device-induced wakeup
      events even if the "soft" mechanism to prevent the system from
      suspending is not enabled.  However, to preserve the existing
      behavior with respect to suspend-to-RAM, this only is done in
      the suspend-to-idle case and only if an SCI has occurred while
      suspended.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      33e4f80e
  4. 06 Jun, 2017 1 commit
  5. 05 May, 2017 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle · eed4d47e
      Rafael J. Wysocki authored
      The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
      during suspend-to-idle transitions and, consequently, any events
      signaled through it wake up the system from that state.  However,
      on some systems some of the events signaled via the ACPI SCI while
      suspended to idle should not cause the system to wake up.  In fact,
      quite often they should just be discarded.
      
      Arguably, systems should not resume entirely on such events, but in
      order to decide which events really should cause the system to resume
      and which are spurious, it is necessary to resume up to the point
      when ACPI SCIs are actually handled and processed, which is after
      executing dpm_resume_noirq() in the system resume path.
      
      For this reasons, add a loop around freeze_enter() in which the
      platforms can process events signaled via multiplexed IRQ lines
      like the ACPI SCI and add suspend-to-idle hooks that can be
      used for this purpose to struct platform_freeze_ops.
      
      In the ACPI case, the ->wake hook is used for checking if the SCI
      has triggered while suspended and deferring the interrupt-induced
      system wakeup until the events signaled through it are actually
      processed sufficiently to decide whether or not the system should
      resume.  In turn, the ->sync hook allows all of the relevant event
      queues to be flushed so as to prevent events from being missed due
      to race conditions.
      
      In addition to that, some ACPI code processing wakeup events needs
      to be modified to use the "hard" version of wakeup triggers, so that
      it will cause a system resume to happen on device-induced wakeup
      events even if the "soft" mechanism to prevent the system from
      suspending is not enabled (that also helps to catch device-induced
      wakeup events occurring during suspend transitions in progress).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eed4d47e
  6. 20 Jan, 2017 1 commit
  7. 21 Nov, 2016 2 commits
    • Rafael J. Wysocki's avatar
      PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag · 08b98d32
      Rafael J. Wysocki authored
      Modify the ACPI system sleep support setup code to select
      suspend-to-idle as the default system sleep state if the
      ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and the
      default sleep state was not selected from the kernel command
      line.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      08b98d32
    • Rafael J. Wysocki's avatar
      PM / sleep: System sleep state selection interface rework · 406e7938
      Rafael J. Wysocki authored
      There are systems in which the platform doesn't support any special
      sleep states, so suspend-to-idle (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 may be a pain in practice.
      
      Commit 0399d4db (PM / sleep: Introduce command line argument for
      sleep state enumeration) attempted to address this problem by adding
      a command line argument to change the meaning of the "mem" string in
      /sys/power/state to make it trigger suspend-to-idle (instead of
      suspend-to-RAM).
      
      However, there also are systems in which the platform does support
      special sleep states, but suspend-to-idle is the preferred one anyway
      (it even may save more energy than the platform-provided sleep states
      in some cases) and the above commit doesn't help in those cases.
      
      For this reason, rework the system sleep state selection interface
      again (but preserve backwards compatibiliby).  Namely, add a new
      sysfs file, /sys/power/mem_sleep, that will control the system
      suspend mode triggered by writing "mem" to /sys/power/state (in
      analogy with what /sys/power/disk does for hibernation).  Make it
      select suspend-to-RAM ("deep" sleep) by default (if supported) and
      fall back to suspend-to-idle ("s2idle") otherwise and add a new
      command line argument, mem_sleep_default, allowing that default to
      be overridden if need be.
      
      At the same time, drop the relative_sleep_states command line
      argument that doesn't make sense any more.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      406e7938
  8. 24 Oct, 2016 1 commit
    • Jon Hunter's avatar
      PM / suspend: Fix missing KERN_CONT for suspend message · 1adb469b
      Jon Hunter authored
      Commit 4bcc595c (printk: reinstate KERN_CONT for printing
      continuation lines) exposed a missing KERN_CONT from one of the
      messages shown on entering suspend. With v4.9-rc1, the 'done.' shown
      after syncing the filesystems no longer appears as a continuation but
      a new message with its own timestamp.
      
      [    9.259566] PM: Syncing filesystems ... [    9.264119] done.
      
      Fix this by adding the KERN_CONT log level for the 'done.' part of the
      message seen after syncing filesystems. While we are at it, convert
      these suspend printks to pr_info and pr_cont, respectively.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1adb469b
  9. 13 Sep, 2016 1 commit
    • Sudeep Holla's avatar
      PM / sleep: enable suspend-to-idle even without registered suspend_ops · fa7fd6fa
      Sudeep Holla authored
      Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
      in which all of the processors enter deepest possible idle state and
      wait for interrupts right after suspending all the devices.
      
      There is no hard requirement for a platform to support and register
      platform specific suspend_ops to enter suspend-to-idle/freeze state.
      Only deeper system sleep states like PM_SUSPEND_STANDBY and
      PM_SUSPEND_MEM rely on such low level support/implementation.
      
      suspend-to-idle can be entered as along as all the devices can be
      suspended. This patch enables the support for suspend-to-idle even on
      systems that don't have any low level support for deeper system sleep
      states and/or don't register any platform specific suspend_ops.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Tested-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fa7fd6fa
  10. 27 Jun, 2016 1 commit
  11. 22 Mar, 2016 1 commit
  12. 11 Feb, 2016 1 commit
  13. 14 Oct, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PM / sleep: Add flags to indicate platform firmware involvement · ef25ba04
      Rafael J. Wysocki authored
      There are quite a few cases in which device drivers, bus types or
      even the PM core itself may benefit from knowing whether or not
      the platform firmware will be involved in the upcoming system power
      transition (during system suspend) or whether or not it was involved
      in it (during system resume).
      
      For this reason, introduce global system suspend flags that can be
      used by the platform code to expose that information for the benefit
      of the other parts of the kernel and make the ACPI core set them
      as appropriate.
      
      Users of the new flags will be added later.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ef25ba04
  14. 31 Jul, 2015 1 commit
  15. 19 May, 2015 1 commit
  16. 12 May, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PM / sleep: Refine diagnostic messages in enter_state() · a9215045
      Rafael J. Wysocki authored
      Some of the system suspend diagnostic messages related to
      suspend-to-idle refer to it as "freeze sleep" or "freeze state"
      while the others say "suspend-to-idle".  To reduce the possible
      confusion that may result from that, refine the former either to
      say "suspend to idle" too or to make it clearer that what is printed
      is a state string written to /sys/power/state ("mem", "standby",
      or "freeze").
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a9215045
  17. 26 Feb, 2015 1 commit
    • Brian Norris's avatar
      PM / sleep: add configurable delay for pm_test · 1d4a9c17
      Brian Norris authored
      When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
      selecting one of a few suspend test modes, where rather than entering a
      full suspend state, the kernel will perform some subset of suspend
      steps, wait 5 seconds, and then resume back to normal operation.
      
      This mode is useful for (among other things) observing the state of the
      system just before entering a sleep mode, for debugging or analysis
      purposes. However, a constant 5 second wait is not sufficient for some
      sorts of analysis; for example, on an SoC, one might want to use
      external tools to probe the power states of various on-chip controllers
      or clocks.
      
      This patch turns this 5 second delay into a configurable module
      parameter, so users can determine how long to wait in this
      pseudo-suspend state before resuming the system.
      
      Example (wait 30 seconds);
      
        # echo 30 > /sys/module/suspend/parameters/pm_test_delay
        # echo core > /sys/power/pm_test
        # time echo mem  > /sys/power/state
        ...
        [   17.583625] suspend debug: Waiting for 30 second(s).
        ...
        real	0m30.381s
        user	0m0.017s
        sys	0m0.080s
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Reviewed-by: default avatarKevin Cernekee <cernekee@chromium.org>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1d4a9c17
  18. 13 Feb, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PM / sleep: Re-implement suspend-to-idle handling · 38106313
      Rafael J. Wysocki authored
      In preparation for adding support for quiescing timers in the final
      stage of suspend-to-idle transitions, rework the freeze_enter()
      function making the system wait on a wakeup event, the freeze_wake()
      function terminating the suspend-to-idle loop and the mechanism by
      which deep idle states are entered during suspend-to-idle.
      
      First of all, introduce a simple state machine for suspend-to-idle
      and make the code in question use it.
      
      Second, prevent freeze_enter() from losing wakeup events due to race
      conditions and ensure that the number of online CPUs won't change
      while it is being executed.  In addition to that, make it force
      all of the CPUs re-enter the idle loop in case they are in idle
      states already (so they can enter deeper idle states if possible).
      
      Next, drop cpuidle_use_deepest_state() and replace use_deepest_state
      checks in cpuidle_select() and cpuidle_reflect() with a single
      suspend-to-idle state check in cpuidle_idle_call().
      
      Finally, introduce cpuidle_enter_freeze() that will simply find the
      deepest idle state available to the given CPU and enter it using
      cpuidle_enter().
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      38106313
  19. 08 Nov, 2014 1 commit
  20. 30 Sep, 2014 3 commits
  21. 22 Sep, 2014 1 commit
  22. 02 Sep, 2014 1 commit
  23. 22 Jul, 2014 1 commit
  24. 21 Jul, 2014 1 commit
  25. 17 Jul, 2014 1 commit
  26. 15 Jul, 2014 1 commit
  27. 06 Jun, 2014 1 commit
    • Todd E Brandt's avatar
      PM / sleep: trace events for suspend/resume · bb3632c6
      Todd E Brandt authored
      Adds trace events that give finer resolution into suspend/resume. These
      events are graphed in the timelines generated by the analyze_suspend.py
      script. They represent large areas of time consumed that are typical to
      suspend and resume.
      
      The event is triggered by calling the function "trace_suspend_resume"
      with three arguments: a string (the name of the event to be displayed
      in the timeline), an integer (case specific number, such as the power
      state or cpu number), and a boolean (where true is used to denote the start
      of the timeline event, and false to denote the end).
      
      The suspend_resume trace event reproduces the data that the machine_suspend
      trace event did, so the latter has been removed.
      Signed-off-by: default avatarTodd Brandt <todd.e.brandt@intel.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bb3632c6
  28. 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
  29. 16 May, 2014 1 commit
    • 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
  30. 06 May, 2014 1 commit
  31. 21 Apr, 2014 1 commit
  32. 07 Apr, 2014 1 commit
  33. 11 Mar, 2014 1 commit