linux-stable.git/kernel/power/qos.c, branch v5.0

PM / QoS: Change to use DEFINE_SHOW_ATTRIBUTE macro

2018-11-29T21:28:11+00:00

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Drop redundant declaration of pm_qos_get_value()

2018-05-28T21:21:41+00:00

The extra forward declaration of pm_qos_get_value() is redundant, so
drop it.

Signed-off-by: Rafael J. Wysocki

PM / QoS: mark expected switch fall-throughs

2018-04-09T11:49:40+00:00

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki

PM: Use a more common logging style

2017-10-03T00:57:17+00:00

Convert printks to pr_.

Miscellanea:

o Use pr_fmt with "PM:" and remove "PM: " from format strings
o Coalesce format strings and realign format arguments
o Convert an embedded incorrect function name to "%s: ", __func__
o Convert a couple multi-line formats to multiple pr_ calls

Signed-off-by: Joe Perches 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki

power, workqueue: remove keventd_up() usage

2016-09-17T17:18:21+00:00

Now that workqueue can handle work item queueing/cancelling from very
early during boot, there is no need to gate cancel_delayed_work_sync()
while !keventd_up().  Remove it.

Signed-off-by: Tejun Heo 
Acked-by: Rafael J. Wysocki 
Cc: Qiao Zhou

PM / QoS: avoid calling cancel_delayed_work_sync() during early boot

2016-09-05T13:07:53+00:00

of_clk_init() ends up calling into pm_qos_update_request() very early
during boot where irq is expected to stay disabled.
pm_qos_update_request() uses cancel_delayed_work_sync() which
correctly assumes that irq is enabled on invocation and
unconditionally disables and re-enables it.

Gate cancel_delayed_work_sync() invocation with kevented_up() to avoid
enabling irq unexpectedly during early boot.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Qiao Zhou 
Link: http://lkml.kernel.org/r/d2501c4c-8e7b-bea3-1b01-000b36b5dfe9@asrmicro.com
Signed-off-by: Rafael J. Wysocki

PM / QoS: Add debugfs support to view the list of constraints

2015-01-23T21:16:21+00:00

PM QoS requests are notoriously hard to debug and made even
more so due to their highly dynamic nature. Having visibility
into the internal data representation per constraint allows
us to have much better appreciation of potential issues or
bad usage by drivers in the system.

So introduce for all classes of PM QoS, an entry in
/sys/kernel/debug/pm_qos that shall show all the current
requests as well as the snapshot of the value these requests
boil down to. For example:
==> /sys/kernel/debug/pm_qos/cpu_dma_latency <==
1: 4444: Active
2: 2000000000: Default
3: 2000000000: Default
4: 2000000000: Default
Type=Minimum, Value=4444, Requests: active=1 / total=4

==> /sys/kernel/debug/pm_qos/memory_bandwidth <==
Empty!

...

The actual value listed will have their meaning based
on the QoS it is on, the 'Type' indicates what logic
it would use to collate the information - Minimum,
Maximum, or Sum. Value is the collation of all requests.
This interface also compares the values with the defaults
for the QoS class and marks the ones that are
currently active.

Signed-off-by: Nishanth Menon 
Signed-off-by: Dave Gerlach 
Acked-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

2014-09-24T23:18:33+00:00

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

PM / QoS: Introcuce latency tolerance device PM QoS type

2014-02-10T23:35:38+00:00

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

PM / QoS: Add no_constraints_value field to struct pm_qos_constraints

2014-02-10T23:35:29+00:00

Add a new field, no_constraints_value, to struct pm_qos_constraints
representing a list of PM QoS constraint requests to be returned by
pm_qos_get_value() when that list of requests is empty.

That field will be equal to default_value for all of the existing
global PM QoS classes and for the resume latency device PM QoS type,
but it will be different from default_value for the new latency
tolerance device PM QoS type introduced by the next changeset.

Signed-off-by: Rafael J. Wysocki