1. 23 Feb, 2017 2 commits
  2. 18 Feb, 2017 1 commit
  3. 06 Feb, 2017 2 commits
  4. 30 Jan, 2017 1 commit
  5. 20 Jan, 2017 1 commit
  6. 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
  7. 24 Oct, 2016 2 commits
  8. 13 Aug, 2016 1 commit
  9. 10 Aug, 2016 1 commit
  10. 05 Apr, 2016 1 commit
  11. 21 Dec, 2015 1 commit
  12. 09 Dec, 2015 1 commit
  13. 25 Sep, 2015 1 commit
  14. 05 Aug, 2015 1 commit
    • Vitaly Kuznetsov's avatar
      cpu-hotplug: convert cpu_hotplug_disabled to a counter · 89af7ba5
      Vitaly Kuznetsov authored
      As a prerequisite to exporting cpu_hotplug_enable/cpu_hotplug_disable
      functions to modules we need to convert cpu_hotplug_disabled to a counter
      to properly support disable -> disable -> enable call sequences. E.g.
      after Hyper-V vmbus module (which is supposed to be the first user of
      exported cpu_hotplug_enable/cpu_hotplug_disable) did cpu_hotplug_disable()
      hibernate path calls disable_nonboot_cpus() and if we hit an error in
      _cpu_down() enable_nonboot_cpus() will be called on the failure path (thus
      making cpu_hotplug_disabled = 0 and leaving cpu hotplug in 'enabled'
      state). Same problem is possible if more than 1 module use
      cpu_hotplug_disable/cpu_hotplug_enable on their load/unload paths. When
      one of these modules is been unloaded it is logical to leave cpu hotplug
      in 'disabled' state.
      
      To support the change we need to increse cpu_hotplug_disabled counter
      in disable_nonboot_cpus() unconditionally as all users of
      disable_nonboot_cpus() are supposed to do enable_nonboot_cpus() in case
      an error was returned.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89af7ba5
  15. 21 Jul, 2015 1 commit
  16. 06 Jul, 2015 1 commit
  17. 12 May, 2015 1 commit
  18. 09 Mar, 2015 1 commit
  19. 06 Mar, 2015 1 commit
  20. 26 Feb, 2015 2 commits
    • 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: Pavel Machek's 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
    • Mark Rutland's avatar
      genirq / PM: better describe IRQF_NO_SUSPEND semantics · 737eb030
      Mark Rutland authored
      The IRQF_NO_SUSPEND flag is intended to be used for interrupts required
      to be enabled during the suspend-resume cycle. This mostly consists of
      IPIs and timer interrupts, potentially including chained irqchip
      interrupts if these are necessary to handle timers or IPIs. If an
      interrupt does not fall into one of the aforementioned categories,
      requesting it with IRQF_NO_SUSPEND is likely incorrect.
      
      Using IRQF_NO_SUSPEND does not guarantee that the interrupt can wake the
      system from a suspended state. For an interrupt to be able to trigger a
      wakeup, it may be necessary to program various components of the system.
      In these cases it is necessary to use {enable,disabled}_irq_wake.
      
      Unfortunately, several drivers assume that IRQF_NO_SUSPEND ensures that
      an IRQ can wake up the system, and the documentation can be read
      ambiguously w.r.t. this property.
      
      This patch updates the documentation regarding IRQF_NO_SUSPEND to make
      this caveat explicit, hopefully making future misuse rarer. Cleanup of
      existing misuse will occur as part of later patch series.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      737eb030
  21. 30 Jan, 2015 1 commit
  22. 17 Nov, 2014 1 commit
  23. 08 Nov, 2014 1 commit
  24. 24 Sep, 2014 1 commit
  25. 16 Sep, 2014 1 commit
  26. 06 Sep, 2014 1 commit
  27. 01 Sep, 2014 1 commit
  28. 27 Aug, 2014 1 commit
  29. 25 Jul, 2014 1 commit
    • Tuomas Tynkkynen's avatar
      regulator: Add helpers for low-level register access · 04eca28c
      Tuomas Tynkkynen authored
      Add helper functions that allow regulator consumers to obtain low-level
      details about the regulator hardware, like the voltage selector register
      address and such. These details can be useful when configuring hardware
      or firmware that want to do low-level access to regulators, with no
      involvement from the kernel.
      
      The use-case for Tegra is a voltage-controlled oscillator clocksource
      which has control logic to change the supply voltage via I2C to achieve
      a desired output clock rate.
      Signed-off-by: default avatarTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      04eca28c
  30. 22 Jul, 2014 1 commit
  31. 18 Jul, 2014 1 commit
    • Jenny TC's avatar
      power_supply: Add inlmt,iterm, min/max temp props · 6bb1d272
      Jenny TC authored
      Add new power supply properties for input current, charge termination
      current, min and max temperature
      
      POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
      POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature
      
      POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT - input current limit programmed
      by charger. Indicates the input current for a charging source.
      
      POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT - Charge termination current used
      to detect the end of charge condition
      Signed-off-by: default avatarJenny TC <jenny.tc@intel.com>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      6bb1d272
  32. 09 Jun, 2014 1 commit
  33. 26 May, 2014 1 commit
    • 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
  34. 16 May, 2014 2 commits