25 Jul, 2017
1 commit
-
Put the device interrupts disabling and enabling as well as
cpuidle_pause() and cpuidle_resume() called during the "noirq"
stages of system suspend into separate functions to allow the
core suspend-to-idle code to be optimized (later).The only functional difference this makes is that debug facilities
and diagnostic tools will not include the above operations into the
"noirq" device suspend/resume duration measurements.Signed-off-by: Rafael J. Wysocki
28 Jun, 2017
1 commit
-
The run_wake flag in struct dev_pm_info is used to indicate whether
or not the device is capable of generating remote wakeup signals at
run time (or in the system working state), but the distinction
between runtime remote wakeup and system wakeup signaling has always
been rather artificial. The only practical reason for it to exist
at the core level was that ACPI and PCI treated those two cases
differently, but that's not the case any more after recent changes.For this reason, get rid of the run_wake flag and, when applicable,
use device_set_wakeup_capable() and device_can_wakeup() instead of
device_set_run_wake() and device_run_wake(), respectively.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas
07 Feb, 2017
2 commits
-
Move the document describing the system sleep state transitions API
for devices to Documentation/driver-api/pm/, convert it to reST and
update it to use current terminology. Also remove the remaining
reference to the old version of it from pm.h.The new document still contains references to some documents in the
.txt format that will be converted later.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jonathan Corbet -
Refresh the struct dev_pm_ops kerneldoc comment, so that it looks
better and is more readable after processing by Sphinx, and drop
the kerneldoc marker from a few other comments ("PM_EVENT_ messages"
and a couple of enum types declarations) which are not proper
kerneldoc and generally confuse Sphinx.Also change the comment describing struct dev_pm_domain into
a kerneldoc one.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jonathan Corbet
14 Dec, 2016
1 commit
-
Pull driver core updates from Greg KH:
"Here's the new driver core patches for 4.10-rc1.Big thing here is the nice addition of "functional dependencies" to
the driver core. The idea has been talked about for a very long time,
great job to Rafael for stepping up and implementing it. It's been
tested for longer than the 4.9-rc1 date, we held off on merging it
earlier in order to feel more comfortable about it.Other than that, it's just a handful of small other patches, some good
cleanups to the mess that is the firmware class code, and we have a
test driver for the deferred probe logic.All of these have been in linux-next for a while with no reported
issues"* tag 'driver-core-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (30 commits)
firmware: Correct handling of fw_state_wait() return value
driver core: Silence device links sphinx warning
firmware: remove warning at documentation generation time
drivers: base: dma-mapping: Fix typo in dmam_alloc_non_coherent comments
driver core: test_async: fix up typo found by 0-day
firmware: move fw_state_is_done() into UHM section
firmware: do not use fw_lock for fw_state protection
firmware: drop bit ops in favor of simple state machine
firmware: refactor loading status
firmware: fix usermode helper fallback loading
driver core: firmware_class: convert to use class_groups
driver core: devcoredump: convert to use class_groups
driver core: class: add class_groups support
kernfs: Declare two local data structures static
driver-core: fix platform_no_drv_owner.cocci warnings
drivers/base/memory.c: Remove unused 'first_page' variable
driver core: add CLASS_ATTR_WO()
drivers: base: cacheinfo: support DT overrides for cache properties
drivers: base: cacheinfo: add pr_fmt logging
drivers: base: cacheinfo: fix boot error message when acpi is enabled
...
01 Nov, 2016
2 commits
-
If the device has no links to suppliers that should be used for
runtime PM (links with DEVICE_LINK_PM_RUNTIME set), there is no
reason to walk the list of suppliers for that device during
runtime suspend and resume.Add a simple mechanism to detect that case and possibly avoid the
extra unnecessary overhead.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
Currently, there is a problem with taking functional dependencies
between devices into account.What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
24 Oct, 2016
1 commit
-
The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right places.Signed-off-by: Mauro Carvalho Chehab
22 Apr, 2016
1 commit
-
The ignore_children flag is used only when CONFIG_PM is set, so let's move
it into that section within the struct dev_pm_info.Move also the corresponding pm_suspend_ignore_children() API out of
device.h into pm_runtime.h, to be consistent with similar APIs.Unfortunate this causes the Toshiba PCI SD mmc host driver to fail to
compile as it needs pm_runtime.h, so let's fix this here as well.Signed-off-by: Ulf Hansson
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
08 Jan, 2016
1 commit
-
If a suitable prepare callback cannot be found for a given device and
its driver has no PM callbacks at all, assume that it can go direct to
complete when the system goes to sleep.The reason for this is that there's lots of devices in a system that do
no PM at all and there's no reason for them to prevent their ancestors
to do direct_complete if they can support it.Signed-off-by: Tomeu Vizoso
Reviewed-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
14 Oct, 2015
1 commit
-
There is a concern that if the platform firmware was involved in
the system resume that's being completed, some devices might have
been reset by it and if those devices had the power.direct_complete
flag set during the preceding suspend transition, they may stay
in a reset-power-on state indefinitely (until they are runtime-resumed
and then suspended again). That may not be a big deal from the
individual device's perspective, but if the system is an SoC, it may
be prevented from entering deep SoC-wide low-power states on idle
because of that.The devices that are most likely to be affected by this issue are
PCI devices and ACPI-enumerated devices using the general ACPI PM
domain, so to prevent it from happening for those devices, force a
runtime resume for them if they have their power.direct_complete
flags set and the platform firmware was involved in the resume
transition currently in progress.Signed-off-by: Rafael J. Wysocki
19 Jun, 2015
1 commit
-
* pm-wakeirq:
PM / wakeirq: Fix typo in prototype for dev_pm_set_dedicated_wake_irq
PM / Wakeirq: Add automated device wake IRQ handling
20 May, 2015
1 commit
-
Turns out we can automate the handling for the device_may_wakeup()
quite a bit by using the kernel wakeup source list as suggested
by Rafael J. Wysocki .And as some hardware has separate dedicated wake-up interrupt
in addition to the IO interrupt, we can automate the handling by
adding a generic threaded interrupt handler that just calls the
device PM runtime to wake up the device.This allows dropping code from device drivers as we currently
are doing it in multiple ways, and often wrong.For most drivers, we should be able to drop the following
boilerplate code from runtime_suspend and runtime_resume
functions:...
device_init_wakeup(dev, true);
...
if (device_may_wakeup(dev))
enable_irq_wake(irq);
...
if (device_may_wakeup(dev))
disable_irq_wake(irq);
...
device_init_wakeup(dev, false);
...We can replace it with just the following init and exit
time code:...
device_init_wakeup(dev, true);
dev_pm_set_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...And for hardware with dedicated wake-up interrupts:
...
device_init_wakeup(dev, true);
dev_pm_set_dedicated_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...Signed-off-by: Tony Lindgren
Signed-off-by: Rafael J. Wysocki
13 May, 2015
1 commit
-
The same approach is used as for the existing SET_SYSTEM_SLEEP_PM_OPS,
but for noirq callbacks.New SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
point ->suspend_noirq, ->freeze_noirq and ->poweroff_noirq to the same
function. Vice versa happens for ->resume_noirq, ->thaw_noirq and
->restore_noirq.Signed-off-by: Grygorii Strashko
Acked-by: Santosh Shilimkar
Reviewed-by: Ulf Hansson
Acked-by: Pavel Machek
Reviewed-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
23 Mar, 2015
1 commit
-
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.Signed-off-by: Rafael J. Wysocki
Acked-by: Ulf Hansson
Reviewed-by: Kevin Hilman
Acked-by: Greg Kroah-Hartman
04 Feb, 2015
1 commit
-
Clients using the dev_pm_put_subsys_data() API isn't interested of a
return value. They care only of decreasing a reference to the device's
pm_subsys_data. So, let's convert the API to a void function, which
anyway seems like reasonable thing to do.Signed-off-by: Ulf Hansson
Acked-by: Geert Uytterhoeven
Signed-off-by: Rafael J. Wysocki
13 Dec, 2014
1 commit
-
There're now no users left of the SET_PM_RUNTIME_PM_OPS() macro, since
all have converted to use the SET_RUNTIME_PM_OPS() macro instead, so
let's remove it.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
09 Dec, 2014
1 commit
-
* pm-runtime: (25 commits)
i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c
dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hwrandom / exynos / PM: Use CONFIG_PM in #ifdef
block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
PM: Merge the SET*_RUNTIME_PM_OPS() macros
PM / Kconfig: Do not select PM directly from Kconfig files
PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core
...
04 Dec, 2014
2 commits
-
The SET_PM_RUNTIME_PM_OPS() and SET_RUNTIME_PM_OPS() macros are
identical except that one of them is not empty for CONFIG_PM set,
while the other one is not empty for CONFIG_PM_RUNTIME set,
respectively.However, after commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so one
of these macros is now redundant.For this reason, replace SET_PM_RUNTIME_PM_OPS() with
SET_RUNTIME_PM_OPS() everywhere and redefine the SET_PM_RUNTIME_PM_OPS
symbol as SET_RUNTIME_PM_OPS in case new code is starting to use the
macro being removed here.Reviewed-by: Ulf Hansson
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki -
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM or even may be dropped entirely in some cases.Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PM core code.
Reviewed-by: Ulf Hansson
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
18 Nov, 2014
1 commit
-
The definition of the struct pm_domain_data better belongs in the
header for the PM domains, let's move it there.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
07 Oct, 2014
1 commit
-
* pm-domains: (32 commits)
PM / Domains: Rename cpu_data to cpuidle_data
PM / Domains: Move dev_pm_domain_attach|detach() to pm_domain.h
PM / Domains: Remove legacy API for adding devices through DT
PM / Domains: Add genpd attach/detach callbacks
PM / Domains: add debugfs listing of struct generic_pm_domain-s
ACPI / PM: Convert acpi_dev_pm_detach() into a static function
ARM: exynos: Move to generic PM domain DT bindings
amba: Add support for attach/detach of PM domains
spi: core: Convert to dev_pm_domain_attach|detach()
mmc: sdio: Convert to dev_pm_domain_attach|detach()
i2c: core: Convert to dev_pm_domain_attach|detach()
drivercore / platform: Convert to dev_pm_domain_attach|detach()
PM / Domains: Add APIs to attach/detach a PM domain for a device
PM / Domains: Add generic OF-based PM domain look-up
ACPI / PM: Assign the ->detach() callback when attaching the PM domain
PM / Domains: Add a detach callback to the struct dev_pm_domain
PM / domains: Spelling s/domian/domain/
PM / domains: Keep declaration of dev_power_governors together
PM / domains: Remove default_stop_ok() API
drivers: sh: Leave disabling of unused PM domains to genpd
...
01 Oct, 2014
1 commit
-
Subsequent change sets will add platform-related operations between
dpm_suspend_late() and dpm_suspend_noirq() as well as between
dpm_resume_noirq() and dpm_resume_early() in suspend_enter(), so
export these functions for suspend_enter() to be able to call them
separately and split the invocations of dpm_suspend_end() and
dpm_resume_start() in there accordingly.Signed-off-by: Rafael J. Wysocki
30 Sep, 2014
1 commit
-
The commit 46420dd73b80 (PM / Domains: Add APIs to attach/detach a PM
domain for a device) started using errno values in pm.h header file.
It also failed to include the header for these, thus it caused
compiler errors.Instead of including the errno header to pm.h, let's move the functions
to pm_domain.h, since it's a better match.Fixes: 46420dd73b80 (PM / Domains: Add APIs to attach/detach a PM domain for a device)
Signed-off-by: Ulf Hansson
Acked-by: Geert Uytterhoeven
Acked-by: Wolfram Sang
Acked-by: Mark Brown
Signed-off-by: Rafael J. Wysocki
22 Sep, 2014
2 commits
-
To maintain scalability let's add common methods to attach and detach
a PM domain for a device, dev_pm_domain_attach|detach().Typically dev_pm_domain_attach() shall be invoked from subsystem level
code at the probe phase to try to attach a device to its PM domain.
The reversed actions may be done a the remove phase and then by
invoking dev_pm_domain_detach().When attachment succeeds, the attach function should assign its
corresponding detach function to a new ->detach() callback added in the
struct dev_pm_domain.Signed-off-by: Ulf Hansson
Tested-by: Philipp Zabel
Reviewed-by: Kevin Hilman
Reviewed-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki -
The intent of this callback is to simplify detachment of devices from
their PM domains. Further patches will show the benefit.Signed-off-by: Ulf Hansson
Reviewed-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki
17 May, 2014
1 commit
-
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: Rafael J. Wysocki
Acked-by: Alan Stern
20 Mar, 2014
3 commits
-
* pm-runtime:
PM / Runtime: Update runtime_idle() documentation for return value meaning* pm-sleep:
PM / sleep: Correct whitespace errors in
PM: Add missing "freeze" state
PM / Hibernate: Spelling s/anonymouns/anonymous/
PM / Runtime: Add missing "it" in comment
PM / suspend: Remove unnecessary !!
PCI / PM: Resume runtime-suspended devices later during system suspend
ACPI / PM: Resume runtime-suspended devices later during system suspend
PM / sleep: Set pm_generic functions to NULL for !CONFIG_PM_SLEEP
PM: fix typo in comment
PM / hibernate: use name_to_dev_t to parse resume
PM / wakeup: Include appropriate header file in kernel/power/wakelock.c
PM / sleep: Move prototype declaration to header file kernel/power/power.h
PM / sleep: Asynchronous threads for suspend_late
PM / sleep: Asynchronous threads for suspend_noirq
PM / sleep: Asynchronous threads for resume_early
PM / sleep: Asynchronous threads for resume_noirq
PM / sleep: Two flags for async suspend_noirq and suspend_late -
rjw> Why exactly are they errors?
Geert> checkpatch.pl says: "WARNING: please, no space before tabs",
Vim (with "let c_space_errors=1") shows them in red.Signed-off-by: Geert Uytterhoeven
Signed-off-by: Rafael J. Wysocki -
As of commit 45f0a85c8258 ('PM / Runtime: Rework the "runtime idle"
helper routine'), the return value of ->runtime_idle() is no longer
ignored by the PM core, but used to decide whether to suspend the
device or not.Update the documentation to match the code.
Signed-off-by: Geert Uytterhoeven
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
01 Mar, 2014
2 commits
-
Previously only a subset of the functions were defined and set to NULL
while !CONFIG_PM_SLEEP. Let's make them all available so they can be
used no matter of CONFIG_PM_SLEEP or not.Signed-off-by: Ulf Hansson
Reviewed-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki -
Signed-off-by: Lad, Prabhakar
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
20 Feb, 2014
1 commit
-
The patch is a helper adding two new flags for implementing
async threads for suspend_noirq and suspend_late.Signed-off-by: Chuansheng Liu
Signed-off-by: Rafael J. Wysocki
11 Feb, 2014
1 commit
-
Add a new latency tolerance device PM QoS type to be use for
specifying active state (RPM_ACTIVE) memory access (DMA) latency
tolerance requirements for devices. It may be used to prevent
hardware from choosing overly aggressive energy-saving operation
modes (causing too much latency to appear) for the whole platform.This feature reqiures hardware support, so it only will be
available for devices having a new .set_latency_tolerance()
callback in struct dev_pm_info populated, in which case the
routine pointed to by it should implement whatever is necessary
to transfer the effective requirement value to the hardware.Whenever the effective latency tolerance changes for the device,
its .set_latency_tolerance() callback will be executed and the
effective value will be passed to it. If that value is negative,
which means that the list of latency tolerance requirements for
the device is empty, the callback is expected to switch the
underlying hardware latency tolerance control mechanism to an
autonomous mode if available. If that value is PM_QOS_LATENCY_ANY,
in turn, and the hardware supports a special "no requirement"
setting, the callback is expected to use it. That allows software
to prevent the hardware from automatically updating the device's
latency tolerance in response to its power state changes (e.g. during
transitions from D3cold to D0), which generally may be done in the
autonomous latency tolerance control mode.If .set_latency_tolerance() is present for the device, a new
pm_qos_latency_tolerance_us attribute will be present in the
devivce's power directory in sysfs. Then, user space can use
that attribute to specify its latency tolerance requirement for
the device, if any. Writing "any" to it means "no requirement, but
do not let the hardware control latency tolerance" and writing
"auto" to it allows the hardware to be switched to the autonomous
mode if there are no other requirements from the kernel side in the
device's list.This changeset includes a fix from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki
13 Jan, 2014
1 commit
-
* pm-sleep:
PM / hibernate: Call platform_leave() in suspend path too
PM / Sleep: Add macro to define common late/early system PM callbacks
PM / hibernate: export hibernation_set_ops* pm-runtime:
PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM
PM / Runtime: Add second macro for definition of runtime PM callbacks* pm-apm:
apm-emulation: add hibernation APM events to support suspend2disk
22 Dec, 2013
2 commits
-
By having the runtime PM callbacks implemented for CONFIG_PM, these
becomes available in all combinations of CONFIG_PM_SLEEP and
CONFIG_PM_RUNTIME.The benefit using this, is that we don't need to implement the wrapper
functions which handles runtime PM resourses, typically called from
both runtime PM and system PM callbacks. Instead the runtime PM
callbacks can be invoked directly from system PM callbacks, which is
useful for some drivers, subsystems and power domains.Use the new macro SET_PM_RUNTIME_PM_OPS in cases were the above makes
sense. Make sure the callbacks are encapsulated within CONFIG_PM
instead of CONFIG_PM_RUNTIME.Do note that the old macro SET_RUNTIME_PM_OPS, which is being quite
widely used right now, requires the callbacks to be defined for
CONFIG_PM_RUNTIME. In many cases it will certainly be convenient to
convert to the new macro above, but that will have to be distinguished
in case by case.Cc: Kevin Hilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
We use the same approach as for the existing SET_SYSTEM_SLEEP_PM_OPS,
but for the late and early callbacks instead.The new SET_LATE_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
point ->suspend_late, ->freeze_late and ->poweroff_late to the same
function. Vice verse happens for ->resume_early, ->thaw_early and
->restore_early.Cc: Kevin Hilman
Cc: Alan Stern
Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
19 Mar, 2013
1 commit
-
Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce incommit a321e91b6d73ed011ffceed384c40d2785cf723b
Author: Imre Deak
Date: Wed Feb 27 17:02:56 2013 -0800lib/scatterlist: add simple page iterator
The merge itself is just two trivial conflicts:
Signed-off-by: Daniel Vetter
24 Feb, 2013
1 commit
-
Introduce the flag memalloc_noio in 'struct dev_pm_info' to help PM core
to teach mm not allocating memory with GFP_KERNEL flag for avoiding
probable deadlock.As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume() or runtime_suspend() on any one of device in the path
from one block or network device to the root device in the device tree
may cause deadlock, the introduced pm_runtime_set_memalloc_noio() sets
or clears the flag on device in the path recursively.Signed-off-by: Ming Lei
Cc: Minchan Kim
Cc: Alan Stern
Cc: Oliver Neukum
Cc: Jiri Kosina
Cc: Mel Gorman
Cc: KAMEZAWA Hiroyuki
Cc: Michal Hocko
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc: Greg KH
Cc: Jens Axboe
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: David Decotigny
Cc: Tom Herbert
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Feb, 2013
1 commit
-
KMS drivers can potentially restore the display configuration without
userspace help. Such drivers can can call a new funciton,
pm_vt_switch_required(false) if they support this feature. In that
case, the PM layer won't VT switch to the suspend console at suspend
time and then back to the original VT on resume, but rather leave things
alone for a nicer looking suspend and resume sequence.v2: make a function so we can handle multiple drivers (Alan)
v3: use a list to track device requests (Rafael)
v4: Squash in build fix from Jesse for CONFIG_VT_CONSOLE_SLEEP=n
v5: Squash in patch from Wu Fengguang to add a few missing static
qualifiers.
v6: Add missing EXPORT_SYMBOL.Signed-off-by: Jesse Barnes
Reviewed-by: Rafael J. Wysocki (v3)
Signed-off-by: Daniel Vetter
