Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 2月, 2018 1 次提交
  3. 02 2月, 2018 2 次提交
  5. 25 1月, 2018 1 次提交
  7. 11 1月, 2018 4 次提交
  9. 10 1月, 2018 2 次提交
  11. 08 1月, 2018 2 次提交
  13. 03 1月, 2018 2 次提交
    • R
      PM / core: Direct DPM_FLAG_LEAVE_SUSPENDED handling · 32bfa56a
      由 Rafael J. Wysocki 提交于 
      Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
devices whose "noirq", "late" and "early" driver callbacks are
invoked directly by it.

Namely, make it skip all of the system-wide resume callbacks for
such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
runtime suspend during the "noirq" phase of system-wide suspend
(or analogous) transitions or the system transition under way is
a proper suspend (rather than anything related to hibernation) and
the device's wakeup settings are compatible with runtime PM (that
is, the device cannot generate wakeup signals at all or it is
allowed to wake up the system from sleep).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      32bfa56a
    • R
      PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization · 75e94645
      由 Rafael J. Wysocki 提交于 
      Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions.  That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).

The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state).  Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.

This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75e94645
  15. 22 12月, 2017 1 次提交
  17. 19 12月, 2017 2 次提交
  19. 12 12月, 2017 3 次提交
  21. 05 12月, 2017 1 次提交
  23. 04 12月, 2017 1 次提交
  25. 02 12月, 2017 1 次提交
  27. 27 11月, 2017 1 次提交
    • R
      PM / core: Add LEAVE_SUSPENDED driver flag · 0d4b54c6
      由 Rafael J. Wysocki 提交于 
      Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
instruct the PM core and middle-layer (bus type, PM domain, etc.)
code that it is desirable to leave the device in runtime suspend
after system-wide transitions to the working state (for example,
the device may be slow to resume and it may be better to avoid
resuming it right away).

Generally, the middle-layer code involved in the handling of the
device is expected to indicate to the PM core whether or not the
device may be left in suspend with the help of the device's
power.may_skip_resume status bit.  That has to happen in the "noirq"
phase of the preceding system suspend (or analogous) transition.
The middle layer is then responsible for handling the device as
appropriate in its "noirq" resume callback which is executed
regardless of whether or not the device may be left suspended, but
the other resume callbacks (except for ->complete) will be skipped
automatically by the core if the device really can be left in
suspend.

The additional power.must_resume status bit introduced for the
implementation of this mechanisn is used internally by the PM core
to track the requirement to resume the device (which may depend on
its children etc).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      0d4b54c6
  29. 06 11月, 2017 7 次提交
  31. 21 10月, 2017 1 次提交
  33. 13 10月, 2017 1 次提交
  35. 12 10月, 2017 1 次提交
  37. 23 9月, 2017 1 次提交
    • R
      PM: Document rules on using pm_runtime_resume() in system suspend callbacks · 104dc5e2
      由 Rafael J. Wysocki 提交于 
      It quite often is necessary to resume devices from runtime suspend
during system suspend for various reasons (for example, if their
wakeup settings need to be changed), but that requires middle-layer
or subsystem code to follow additional rules which currently are not
clearly documented.

Namely, if a driver calls pm_runtime_resume() for the device from
its ->suspend (or equivalent) system sleep callback, that may not
work if the middle layer above it has updated the state of the
device from its ->prepare or ->suspend callbacks already in an
incompatible way.  For this reason, all middle layers must follow
the rule that, until the ->suspend callback provided by the device's
driver is invoked, the only way in which the device's state can be
updated is by calling pm_runtime_resume() for it, if necessary.
Fortunately enough, all middle layers in the code base today follow
this rule, but it is not explicitly stated anywhere, so do that.

Note that calling pm_runtime_resume() from the ->suspend callback
of a driver will cause the ->runtime_resume callback provided by the
middle layer to be invoked, but the rule above guarantees that this
callback will nest properly with the middle layer's ->suspend
callback and it will play well with the ->prepare one invoked before.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      104dc5e2
  39. 22 9月, 2017 1 次提交
  41. 21 9月, 2017 1 次提交
  43. 20 9月, 2017 1 次提交
  45. 11 9月, 2017 1 次提交
  47. 14 8月, 2017 1 次提交