11 Dec, 2017
1 commit
-
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
(cherry picked from commit 9ed9895370aedd6032af2a9181c62c394d08223b)
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
18 Feb, 2013
1 commit
-
pm_idle appears in no generic Linux code,
it appears only in architecture-specific code.Thus, pm_idle should not be declared in pm.h.
Architectures that use an idle function pointer
should delcare one local to their architecture,
and/or use cpuidle.Signed-off-by: Len Brown
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Cc: linux-pm@vger.kernel.org
24 Oct, 2012
1 commit
-
Define two device PM QoS flags, PM_QOS_FLAG_NO_POWER_OFF
and PM_QOS_FLAG_REMOTE_WAKEUP, and introduce routines
dev_pm_qos_expose_flags() and dev_pm_qos_hide_flags() allowing the
caller to expose those two flags to user space or to hide them
from it, respectively.After the flags have been exposed, user space will see two
additional sysfs attributes, pm_qos_no_power_off and
pm_qos_remote_wakeup, under the device's /sys/devices/.../power/
directory. Then, writing 1 to one of them will update the
PM QoS flags request owned by user space so that the corresponding
flag is requested to be set. In turn, writing 0 to one of them
will cause the corresponding flag in the user space's request to
be cleared (however, the owners of the other PM QoS flags requests
for the same device may still request the flag to be set and it
may be effectively set even if user space doesn't request that).Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jean Pihet
Acked-by: mark gross
23 Oct, 2012
1 commit
-
Currently struct dev_pm_info contains only one PM QoS constraints
pointer reserved for latency requirements. Since one more device
constraints type (i.e. flags) will be necessary, introduce a new
structure, struct dev_pm_qos, that eventually will contain all of
the available device PM QoS constraints and replace the "constraints"
pointer in struct dev_pm_info with a pointer to the new structure
called "qos".Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jean Pihet
03 Oct, 2012
1 commit
-
Pull power management updates from Rafael J Wysocki:
- Improved system suspend/resume and runtime PM handling for the SH
TMU, CMT and MTU2 clock event devices (also used by ARM/shmobile).- Generic PM domains framework extensions related to cpuidle support
and domain objects lookup using names.- ARM/shmobile power management updates including improved support for
the SH7372's A4S power domain containing the CPU core.- cpufreq changes related to AMD CPUs support from Matthew Garrett,
Andre Przywara and Borislav Petkov.- cpu0 cpufreq driver from Shawn Guo.
- cpufreq governor fixes related to the relaxing of limit from Michal
Pecio.- OMAP cpufreq updates from Axel Lin and Richard Zhao.
- cpuidle ladder governor fixes related to the disabling of states from
Carsten Emde and me.- Runtime PM core updates related to the interactions with the system
suspend core from Alan Stern and Kevin Hilman.- Wakeup sources modification allowing more helper functions to be
called from interrupt context from John Stultz and additional
diagnostic code from Todd Poynor.- System suspend error code path fix from Feng Hong.
Fixed up conflicts in cpufreq/powernow-k8 that stemmed from the
workqueue fixes conflicting fairly badly with the removal of support for
hardware P-state chips. The changes were independent but somewhat
intertwined.* tag 'pm-for-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (76 commits)
Revert "PM QoS: Use spinlock in the per-device PM QoS constraints code"
PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2
cpuidle: rename function name "__cpuidle_register_driver", v2
cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name
cpuidle: remove some empty lines
PM: Prevent runtime suspend during system resume
PM QoS: Use spinlock in the per-device PM QoS constraints code
PM / Sleep: use resume event when call dpm_resume_early
cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure
ACPI / processor: remove pointless variable initialization
ACPI / processor: remove unused function parameter
cpufreq: OMAP: remove loops_per_jiffy recalculate for smp
sections: fix section conflicts in drivers/cpufreq
cpufreq: conservative: update frequency when limits are relaxed
cpufreq / ondemand: update frequency when limits are relaxed
properly __init-annotate pm_sysrq_init()
cpufreq: Add a generic cpufreq-cpu0 driver
PM / OPP: Initialize OPP table from device tree
ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp
cpufreq: Remove support for hardware P-state chips from powernow-k8
...
04 Sep, 2012
3 commits
-
The syscore device PM flag used to mark the devices (belonging to
PM domains) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages, need not be
accessed by the runtime PM core functions, because all of the devices
it is set for need to be marked as "irq safe" anyway and are
protected from being turned off by runtime PM by ensuring that their
usage counters are always set.For this reason, make the syscore flag system-wide PM-specific
and simplify the code used for manipulating it, because it need not
acquire the device's power.lock any more.Signed-off-by: Rafael J. Wysocki
-
The syscore device PM flag is used to mark the devices (belonging to
a PM domain) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages. That flag is
stored in the device's struct pm_subsys_data object whose address is
available from struct device. However, in some situations it may be
convenient to set that flag before the device is added to a PM
domain, so it is better to move it directly to the "power" member of
struct device. Then, it can be checked by the routines in
drivers/base/power/runtime.c and drivers/base/power/main.c, which is
more straightforward.This also reduces the number of dev_gpd_data() invocations in the
generic PM domains framework, so the overhead related to the syscore
flag is slightly smaller.Signed-off-by: Rafael J. Wysocki
Acked-by: Magnus Damm -
Runtime PM helper functions, like pm_runtime_get_sync(), cannot be
called by early platform device drivers, because the devices' power
management locks are not initialized at that time. This is quite
inconvenient, so modify early_platform_add_devices() to initialize
the devices power management locks as appropriate and make sure that
they won't be initialized more than once if an early platform
device is going to be used as a regular one later.Signed-off-by: Rafael J. Wysocki
