2010-01-24 04:03:22 +07:00
|
|
|
What: /sys/devices/.../power/
|
|
|
|
|
Date: January 2009
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-01-24 04:03:22 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power directory contains attributes
|
|
|
|
|
allowing the user space to check and modify some power
|
|
|
|
|
management related properties of given device.
|
|
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup
|
|
|
|
|
Date: January 2009
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-01-24 04:03:22 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/wakeup attribute allows the user
|
|
|
|
|
space to check if the device is enabled to wake up the system
|
|
|
|
|
from sleep states, such as the memory sleep state (suspend to
|
|
|
|
|
RAM) and hibernation (suspend to disk), and to enable or disable
|
|
|
|
|
it to do that as desired.
|
|
|
|
|
|
|
|
|
|
Some devices support "wakeup" events, which are hardware signals
|
|
|
|
|
used to activate the system from a sleep state. Such devices
|
|
|
|
|
have one of the following two values for the sysfs power/wakeup
|
|
|
|
|
file:
|
|
|
|
|
|
|
|
|
|
+ "enabled\n" to issue the events;
|
|
|
|
|
+ "disabled\n" not to do so;
|
|
|
|
|
|
|
|
|
|
In that cases the user space can change the setting represented
|
|
|
|
|
by the contents of this file by writing either "enabled", or
|
|
|
|
|
"disabled" to it.
|
|
|
|
|
|
|
|
|
|
For the devices that are not capable of generating system wakeup
|
2011-02-09 05:26:02 +07:00
|
|
|
events this file is not present. In that case the device cannot
|
|
|
|
|
be enabled to wake up the system from sleep states.
|
2010-01-24 04:03:22 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/control
|
|
|
|
|
Date: January 2009
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-01-24 04:03:22 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/control attribute allows the user
|
|
|
|
|
space to control the run-time power management of the device.
|
|
|
|
|
|
|
|
|
|
All devices have one of the following two values for the
|
|
|
|
|
power/control file:
|
|
|
|
|
|
|
|
|
|
+ "auto\n" to allow the device to be power managed at run time;
|
|
|
|
|
+ "on\n" to prevent the device from being power managed;
|
|
|
|
|
|
|
|
|
|
The default for all devices is "auto", which means that they may
|
|
|
|
|
be subject to automatic power management, depending on their
|
|
|
|
|
drivers. Changing this attribute to "on" prevents the driver
|
|
|
|
|
from power managing the device at run time. Doing that while
|
|
|
|
|
the device is suspended causes it to be woken up.
|
2010-01-24 04:25:23 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/async
|
|
|
|
|
Date: January 2009
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-01-24 04:25:23 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../async attribute allows the user space to
|
|
|
|
|
enable or diasble the device's suspend and resume callbacks to
|
|
|
|
|
be executed asynchronously (ie. in separate threads, in parallel
|
|
|
|
|
with the main suspend/resume thread) during system-wide power
|
|
|
|
|
transitions (eg. suspend to RAM, hibernation).
|
|
|
|
|
|
|
|
|
|
All devices have one of the following two values for the
|
|
|
|
|
power/async file:
|
|
|
|
|
|
|
|
|
|
+ "enabled\n" to permit the asynchronous suspend/resume;
|
|
|
|
|
+ "disabled\n" to forbid it;
|
|
|
|
|
|
|
|
|
|
The value of this attribute may be changed by writing either
|
|
|
|
|
"enabled", or "disabled" to it.
|
|
|
|
|
|
|
|
|
|
It generally is unsafe to permit the asynchronous suspend/resume
|
|
|
|
|
of a device unless it is certain that all of the PM dependencies
|
|
|
|
|
of the device are known to the PM core. However, for some
|
|
|
|
|
devices this attribute is set to "enabled" by bus type code or
|
|
|
|
|
device drivers and in that cases it should be safe to leave the
|
|
|
|
|
default value.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_count
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_count attribute contains the number
|
|
|
|
|
of signaled wakeup events associated with the device. This
|
2014-03-28 17:15:14 +07:00
|
|
|
attribute is read-only. If the device is not capable to wake up
|
2011-02-09 05:26:02 +07:00
|
|
|
the system from sleep states, this attribute is not present.
|
2014-03-28 17:15:14 +07:00
|
|
|
If the device is not enabled to wake up the system from sleep
|
|
|
|
|
states, this attribute is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_active_count
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_active_count attribute contains the
|
|
|
|
|
number of times the processing of wakeup events associated with
|
|
|
|
|
the device was completed (at the kernel level). This attribute
|
2014-03-28 17:15:14 +07:00
|
|
|
is read-only. If the device is not capable to wake up the
|
|
|
|
|
system from sleep states, this attribute is not present. If
|
|
|
|
|
the device is not enabled to wake up the system from sleep
|
|
|
|
|
states, this attribute is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
2012-04-30 03:52:52 +07:00
|
|
|
What: /sys/devices/.../power/wakeup_abort_count
|
|
|
|
|
Date: February 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
2012-04-30 03:52:52 +07:00
|
|
|
The /sys/devices/.../wakeup_abort_count attribute contains the
|
2010-09-23 03:09:10 +07:00
|
|
|
number of times the processing of a wakeup event associated with
|
2012-04-30 03:52:52 +07:00
|
|
|
the device might have aborted system transition into a sleep
|
|
|
|
|
state in progress. This attribute is read-only. If the device
|
2014-03-28 17:15:14 +07:00
|
|
|
is not capable to wake up the system from sleep states, this
|
|
|
|
|
attribute is not present. If the device is not enabled to wake
|
|
|
|
|
up the system from sleep states, this attribute is empty.
|
2012-04-30 03:52:52 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_expire_count
|
|
|
|
|
Date: February 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2012-04-30 03:52:52 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_expire_count attribute contains the
|
|
|
|
|
number of times a wakeup event associated with the device has
|
|
|
|
|
been reported with a timeout that expired. This attribute is
|
2014-03-28 17:15:14 +07:00
|
|
|
read-only. If the device is not capable to wake up the system
|
|
|
|
|
from sleep states, this attribute is not present. If the
|
|
|
|
|
device is not enabled to wake up the system from sleep states,
|
|
|
|
|
this attribute is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_active
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_active attribute contains either 1,
|
|
|
|
|
or 0, depending on whether or not a wakeup event associated with
|
|
|
|
|
the device is being processed (1). This attribute is read-only.
|
2014-03-28 17:15:14 +07:00
|
|
|
If the device is not capable to wake up the system from sleep
|
|
|
|
|
states, this attribute is not present. If the device is not
|
|
|
|
|
enabled to wake up the system from sleep states, this attribute
|
|
|
|
|
is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_total_time_ms
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_total_time_ms attribute contains
|
|
|
|
|
the total time of processing wakeup events associated with the
|
|
|
|
|
device, in milliseconds. This attribute is read-only. If the
|
2014-03-28 17:15:14 +07:00
|
|
|
device is not capable to wake up the system from sleep states,
|
|
|
|
|
this attribute is not present. If the device is not enabled to
|
|
|
|
|
wake up the system from sleep states, this attribute is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_max_time_ms
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_max_time_ms attribute contains
|
|
|
|
|
the maximum time of processing a single wakeup event associated
|
|
|
|
|
with the device, in milliseconds. This attribute is read-only.
|
2014-03-28 17:15:14 +07:00
|
|
|
If the device is not capable to wake up the system from sleep
|
|
|
|
|
states, this attribute is not present. If the device is not
|
|
|
|
|
enabled to wake up the system from sleep states, this attribute
|
|
|
|
|
is empty.
|
2010-09-23 03:09:10 +07:00
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/wakeup_last_time_ms
|
|
|
|
|
Date: September 2010
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2010-09-23 03:09:10 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_last_time_ms attribute contains
|
|
|
|
|
the value of the monotonic clock corresponding to the time of
|
|
|
|
|
signaling the last wakeup event associated with the device, in
|
|
|
|
|
milliseconds. This attribute is read-only. If the device is
|
|
|
|
|
not enabled to wake up the system from sleep states, this
|
2014-03-28 17:15:14 +07:00
|
|
|
attribute is not present. If the device is not enabled to wake
|
|
|
|
|
up the system from sleep states, this attribute is empty.
|
2010-09-26 04:35:21 +07:00
|
|
|
|
2012-04-30 03:53:32 +07:00
|
|
|
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
|
|
|
|
|
Date: February 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2012-04-30 03:53:32 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
|
|
|
|
|
contains the total time the device has been preventing
|
2012-11-08 19:57:35 +07:00
|
|
|
opportunistic transitions to sleep states from occurring.
|
2014-03-28 17:15:14 +07:00
|
|
|
This attribute is read-only. If the device is not capable to
|
2012-04-30 03:53:32 +07:00
|
|
|
wake up the system from sleep states, this attribute is not
|
2014-03-28 17:15:14 +07:00
|
|
|
present. If the device is not enabled to wake up the system
|
|
|
|
|
from sleep states, this attribute is empty.
|
2012-04-30 03:53:32 +07:00
|
|
|
|
2010-09-26 04:35:21 +07:00
|
|
|
What: /sys/devices/.../power/autosuspend_delay_ms
|
|
|
|
|
Date: September 2010
|
|
|
|
|
Contact: Alan Stern <stern@rowland.harvard.edu>
|
|
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/autosuspend_delay_ms attribute
|
|
|
|
|
contains the autosuspend delay value (in milliseconds). Some
|
|
|
|
|
drivers do not want their device to suspend as soon as it
|
|
|
|
|
becomes idle at run time; they want the device to remain
|
|
|
|
|
inactive for a certain minimum period of time first. That
|
|
|
|
|
period is called the autosuspend delay. Negative values will
|
|
|
|
|
prevent the device from being suspended at run time (similar
|
|
|
|
|
to writing "on" to the power/control attribute). Values >=
|
|
|
|
|
1000 will cause the autosuspend timer expiration to be rounded
|
|
|
|
|
up to the nearest second.
|
|
|
|
|
|
|
|
|
|
Not all drivers support this attribute. If it isn't supported,
|
|
|
|
|
attempts to read or write it will yield I/O errors.
|
PM / QoS: Make it possible to expose PM QoS latency constraints
A runtime suspend of a device (e.g. an MMC controller) belonging to
a power domain or, in a more complicated scenario, a runtime suspend
of another device in the same power domain, may cause power to be
removed from the entire domain. In that case, the amount of time
necessary to runtime-resume the given device (e.g. the MMC
controller) is often substantially greater than the time needed to
run its driver's runtime resume callback. That may hurt performance
in some situations, because user data may need to wait for the
device to become operational, so we should make it possible to
prevent that from happening.
For this reason, introduce a new sysfs attribute for devices,
power/pm_qos_resume_latency_us, allowing user space to specify the
upper bound of the time necessary to bring the (runtime-suspended)
device up after the resume of it has been requested. However, make
that attribute appear only for the devices whose drivers declare
support for it by calling the (new) dev_pm_qos_expose_latency_limit()
helper function with the appropriate initial value of the attribute.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-13 07:01:39 +07:00
|
|
|
|
PM / QoS: Introcuce latency tolerance device PM QoS type
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 <rafael.j.wysocki@intel.com>
2014-02-11 06:35:38 +07:00
|
|
|
What: /sys/devices/.../power/pm_qos_resume_latency_us
|
PM / QoS: Make it possible to expose PM QoS latency constraints
A runtime suspend of a device (e.g. an MMC controller) belonging to
a power domain or, in a more complicated scenario, a runtime suspend
of another device in the same power domain, may cause power to be
removed from the entire domain. In that case, the amount of time
necessary to runtime-resume the given device (e.g. the MMC
controller) is often substantially greater than the time needed to
run its driver's runtime resume callback. That may hurt performance
in some situations, because user data may need to wait for the
device to become operational, so we should make it possible to
prevent that from happening.
For this reason, introduce a new sysfs attribute for devices,
power/pm_qos_resume_latency_us, allowing user space to specify the
upper bound of the time necessary to bring the (runtime-suspended)
device up after the resume of it has been requested. However, make
that attribute appear only for the devices whose drivers declare
support for it by calling the (new) dev_pm_qos_expose_latency_limit()
helper function with the appropriate initial value of the attribute.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-13 07:01:39 +07:00
|
|
|
Date: March 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
PM / QoS: Make it possible to expose PM QoS latency constraints
A runtime suspend of a device (e.g. an MMC controller) belonging to
a power domain or, in a more complicated scenario, a runtime suspend
of another device in the same power domain, may cause power to be
removed from the entire domain. In that case, the amount of time
necessary to runtime-resume the given device (e.g. the MMC
controller) is often substantially greater than the time needed to
run its driver's runtime resume callback. That may hurt performance
in some situations, because user data may need to wait for the
device to become operational, so we should make it possible to
prevent that from happening.
For this reason, introduce a new sysfs attribute for devices,
power/pm_qos_resume_latency_us, allowing user space to specify the
upper bound of the time necessary to bring the (runtime-suspended)
device up after the resume of it has been requested. However, make
that attribute appear only for the devices whose drivers declare
support for it by calling the (new) dev_pm_qos_expose_latency_limit()
helper function with the appropriate initial value of the attribute.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
2012-03-13 07:01:39 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
|
|
|
|
|
contains the PM QoS resume latency limit for the given device,
|
|
|
|
|
which is the maximum allowed time it can take to resume the
|
|
|
|
|
device, after it has been suspended at run time, from a resume
|
|
|
|
|
request to the moment the device will be ready to process I/O,
|
|
|
|
|
in microseconds. If it is equal to 0, however, this means that
|
|
|
|
|
the PM QoS resume latency may be arbitrary.
|
|
|
|
|
|
|
|
|
|
Not all drivers support this attribute. If it isn't supported,
|
|
|
|
|
it is not present.
|
|
|
|
|
|
|
|
|
|
This attribute has no effect on system-wide suspend/resume and
|
|
|
|
|
hibernation.
|
2012-10-24 07:08:18 +07:00
|
|
|
|
PM / QoS: Introcuce latency tolerance device PM QoS type
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 <rafael.j.wysocki@intel.com>
2014-02-11 06:35:38 +07:00
|
|
|
What: /sys/devices/.../power/pm_qos_latency_tolerance_us
|
|
|
|
|
Date: January 2014
|
|
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
|
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/pm_qos_latency_tolerance_us attribute
|
|
|
|
|
contains the PM QoS active state latency tolerance limit for the
|
|
|
|
|
given device in microseconds. That is the maximum memory access
|
|
|
|
|
latency the device can suffer without any visible adverse
|
|
|
|
|
effects on user space functionality. If that value is the
|
|
|
|
|
string "any", the latency does not matter to user space at all,
|
|
|
|
|
but hardware should not be allowed to set the latency tolerance
|
|
|
|
|
for the device automatically.
|
|
|
|
|
|
|
|
|
|
Reading "auto" from this file means that the maximum memory
|
|
|
|
|
access latency for the device may be determined automatically
|
|
|
|
|
by the hardware as needed. Writing "auto" to it allows the
|
|
|
|
|
hardware to be switched to this mode if there are no other
|
|
|
|
|
latency tolerance requirements from the kernel side.
|
|
|
|
|
|
|
|
|
|
This attribute is only present if the feature controlled by it
|
|
|
|
|
is supported by the hardware.
|
|
|
|
|
|
|
|
|
|
This attribute has no effect on runtime suspend and resume of
|
|
|
|
|
devices and on system-wide suspend/resume and hibernation.
|
|
|
|
|
|
2012-10-24 07:08:18 +07:00
|
|
|
What: /sys/devices/.../power/pm_qos_no_power_off
|
|
|
|
|
Date: September 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2012-10-24 07:08:18 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/pm_qos_no_power_off attribute
|
|
|
|
|
is used for manipulating the PM QoS "no power off" flag. If
|
|
|
|
|
set, this flag indicates to the kernel that power should not
|
|
|
|
|
be removed entirely from the device.
|
|
|
|
|
|
|
|
|
|
Not all drivers support this attribute. If it isn't supported,
|
|
|
|
|
it is not present.
|
|
|
|
|
|
|
|
|
|
This attribute has no effect on system-wide suspend/resume and
|
|
|
|
|
hibernation.
|
|
|
|
|
|
|
|
|
|
What: /sys/devices/.../power/pm_qos_remote_wakeup
|
|
|
|
|
Date: September 2012
|
2013-10-09 06:47:53 +07:00
|
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
2012-10-24 07:08:18 +07:00
|
|
|
Description:
|
|
|
|
|
The /sys/devices/.../power/pm_qos_remote_wakeup attribute
|
|
|
|
|
is used for manipulating the PM QoS "remote wakeup required"
|
|
|
|
|
flag. If set, this flag indicates to the kernel that the
|
|
|
|
|
device is a source of user events that have to be signaled from
|
|
|
|
|
its low-power states.
|
|
|
|
|
|
|
|
|
|
Not all drivers support this attribute. If it isn't supported,
|
|
|
|
|
it is not present.
|
|
|
|
|
|
|
|
|
|
This attribute has no effect on system-wide suspend/resume and
|
|
|
|
|
hibernation.
|