25 Sep, 2014
1 commit
-
Also adds a class type PM_QOS_SUM that aggregates the values by summing them.
It can be used by memory controllers to calculate the optimum clock frequency
based on the bandwidth needs of the different memory clients.Signed-off-by: Tomeu Vizoso
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
11 Feb, 2014
3 commits
-
Rework dev_pm_qos_add_ancestor_request() so that device PM QoS type
is passed to it as the third argument and make it support the
DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type (in addition to
DEV_PM_QOS_RESUME_LATENCY).That will allow the drivers of devices without latency tolerance
hardware support to use their ancestors having it as proxies for
their latency tolerance requirements.Signed-off-by: Rafael J. Wysocki
-
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
-
Rename symbols, variables, functions and structure fields related do
the resume latency device PM QoS type so that it is clear where they
belong (in particular, to avoid confusion with the latency tolerance
device PM QoS type introduced by a subsequent changeset).Update the PM QoS documentation to better reflect its current state.
Signed-off-by: Rafael J. Wysocki
23 Jun, 2013
1 commit
-
Update PM QoS documentation after recent changes.
[rjw: Changelog]
Signed-off-by: Lan Tianyu
Signed-off-by: Rafael J. Wysocki
23 Oct, 2012
1 commit
-
Modify the device PM QoS core code to support PM QoS flags requests.
First, add a new field of type struct pm_qos_flags called "flags"
to struct dev_pm_qos for representing the list of PM QoS flags
requests for the given device. Accordingly, add a new "type" field
to struct dev_pm_qos_request (along with an enum for representing
request types) and a new member called "flr" to its data union for
representig flags requests.Second, modify dev_pm_qos_add_request(), dev_pm_qos_update_request(),
the internal routine apply_constraint() used by them and their
existing callers to cover flags requests as well as latency
requests. In particular, dev_pm_qos_add_request() gets a new
argument called "type" for specifying the type of a request to be
added.Finally, introduce two routines, __dev_pm_qos_flags() and
dev_pm_qos_flags(), allowing their callers to check which PM QoS
flags have been requested for the given device (the caller is
supposed to pass the mask of flags to check as the routine's
second argument and examine its return value for the result).Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jean Pihet
Reviewed-by: mark gross
05 Oct, 2011
1 commit
-
Update the documentation for the recently updated pm_qos API, kernel
and user space. Add documentation for the per-device PM QoS
(dev_pm_qos) framework API.Signed-off-by: Jean Pihet
Signed-off-by: Rafael J. Wysocki
11 May, 2010
1 commit
-
This patch changes the string based list management to a handle base
implementation to help with the hot path use of pm-qos, it also renames
much of the API to use "request" as opposed to "requirement" that was
used in the initial implementation. I did this because request more
accurately represents what it actually does.Also, I added a string based ABI for users wanting to use a string
interface. So if the user writes 0xDDDDDDDD formatted hex it will be
accepted by the interface. (someone asked me for it and I don't think
it hurts anything.)This patch updates some documentation input I got from Randy.
Signed-off-by: markgross
Signed-off-by: Rafael J. Wysocki
06 Aug, 2008
1 commit
-
A documentation cleanup patch. With a minor tweak to clarify units for
kbs.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: mark gross
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Mar, 2008
1 commit
-
Move 00-INDEX entries to power/00-INDEX (and add entry for
pm_qos_interface.txt).Update references to moved filenames.
Fix some trailing whitespace.
Signed-off-by: Randy Dunlap
Signed-off-by: Len Brown
