1. 20 4月, 2017 1 次提交
    • J
      PM / runtime: Fix autosuspend documentation · 72ec2e17
      Johan Hovold 提交于
      Update the autosuspend documentation which claimed that the autosuspend
      delay is not taken into account when using the non-autosuspend helper
      functions, something which is no longer true since commit d66e6db2
      ("PM / Runtime: Respect autosuspend when idle triggers suspend").
      
      This specifically means that drivers must now disable autosuspend before
      disabling runtime pm in probe error paths and remove callbacks if
      pm_runtime_put_sync was being used to suspend the device before
      returning. (If an idle callback can prevent suspend,
      pm_runtime_put_sync_suspend must be used instead of pm_runtime_put_sync
      as before.)
      
      Also remove the claim that the autosuspend helpers behave "just like
      the non-autosuspend counterparts", something which have never really
      been true as some of the latter use idle notifications.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      72ec2e17
  2. 24 2月, 2017 2 次提交
  3. 18 2月, 2017 1 次提交
  4. 07 2月, 2017 2 次提交
  5. 30 1月, 2017 1 次提交
  6. 20 1月, 2017 1 次提交
  7. 22 11月, 2016 2 次提交
    • R
      PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag · 08b98d32
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMario Limonciello <mario.limonciello@dell.com>
      08b98d32
    • R
      PM / sleep: System sleep state selection interface rework · 406e7938
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMario Limonciello <mario.limonciello@dell.com>
      406e7938
  8. 25 10月, 2016 1 次提交
  9. 24 10月, 2016 1 次提交
  10. 13 8月, 2016 1 次提交
  11. 11 8月, 2016 1 次提交
  12. 05 4月, 2016 1 次提交
  13. 21 12月, 2015 1 次提交
  14. 09 12月, 2015 1 次提交
  15. 25 9月, 2015 1 次提交
  16. 06 8月, 2015 1 次提交
    • V
      cpu-hotplug: convert cpu_hotplug_disabled to a counter · 89af7ba5
      Vitaly Kuznetsov 提交于
      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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89af7ba5
  17. 22 7月, 2015 1 次提交
  18. 07 7月, 2015 1 次提交
  19. 13 5月, 2015 1 次提交
  20. 10 3月, 2015 1 次提交
  21. 06 3月, 2015 1 次提交
  22. 26 2月, 2015 2 次提交
    • B
      PM / sleep: add configurable delay for pm_test · 1d4a9c17
      Brian Norris 提交于
      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: NBrian Norris <computersforpeace@gmail.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Reviewed-by: NKevin Cernekee <cernekee@chromium.org>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1d4a9c17
    • M
      genirq / PM: better describe IRQF_NO_SUSPEND semantics · 737eb030
      Mark Rutland 提交于
      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: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      737eb030
  23. 30 1月, 2015 1 次提交
  24. 18 11月, 2014 1 次提交
  25. 08 11月, 2014 1 次提交
  26. 25 9月, 2014 1 次提交
  27. 16 9月, 2014 1 次提交
  28. 07 9月, 2014 1 次提交
  29. 01 9月, 2014 1 次提交
  30. 28 8月, 2014 1 次提交
  31. 26 7月, 2014 1 次提交
    • T
      regulator: Add helpers for low-level register access · 04eca28c
      Tuomas Tynkkynen 提交于
      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: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      04eca28c
  32. 23 7月, 2014 1 次提交
  33. 19 7月, 2014 1 次提交
    • J
      power_supply: Add inlmt,iterm, min/max temp props · 6bb1d272
      Jenny TC 提交于
      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: NJenny TC <jenny.tc@intel.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      6bb1d272
  34. 10 6月, 2014 1 次提交
  35. 26 5月, 2014 1 次提交
    • R
      PM / sleep: Introduce command line argument for sleep state enumeration · 0399d4db
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0399d4db
  36. 17 5月, 2014 1 次提交