linux-stable.git/include/linux/pm_qos.h, branch v5.4.239

PM / QoS: Redefine FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX

2019-12-21T10:04:31+00:00

commit c6a3aea93571a5393602256d8f74772bd64c8225 upstream.

QOS requests for DEFAULT_VALUE are supposed to be ignored but this is
not the case for FREQ_QOS_MAX. Adding one request for MAX_DEFAULT_VALUE
and one for a real value will cause freq_qos_read_value to unexpectedly
return MAX_DEFAULT_VALUE (-1).

This happens because freq_qos max value is aggregated with PM_QOS_MIN
but FREQ_QOS_MAX_DEFAULT_VALUE is (-1) so it's smaller than other
values.

Fix this by redefining FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX.

Looking at current users for freq_qos it seems that none of them create
requests for FREQ_QOS_MAX_DEFAULT_VALUE.

Fixes: 77751a466ebd ("PM: QoS: Introduce frequency QoS")
Signed-off-by: Leonard Crestez 
Reported-by: Matthias Kaehlcke 
Reviewed-by: Matthias Kaehlcke 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM: QoS: Drop frequency QoS types from device PM QoS

2019-10-21T00:05:21+00:00

There are no more active users of DEV_PM_QOS_MIN_FREQUENCY and
DEV_PM_QOS_MAX_FREQUENCY device PM QoS request types, so drop them
along with the code supporting them.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

PM: QoS: Introduce frequency QoS

2019-10-21T00:05:21+00:00

Introduce frequency QoS, based on the "raw" low-level PM QoS, to
represent min and max frequency requests and aggregate constraints.

The min and max frequency requests are to be represented by
struct freq_qos_request objects and the aggregate constraints are to
be represented by struct freq_constraints objects.  The latter are
expected to be initialized with the help of freq_constraints_init().

The freq_qos_read_value() helper is defined to retrieve the aggregate
constraints values from a given struct freq_constraints object and
there are the freq_qos_add_request(), freq_qos_update_request() and
freq_qos_remove_request() helpers to manipulate the min and max
frequency requests.  It is assumed that the the helpers will not
run concurrently with each other for the same struct freq_qos_request
object, so if that may be the case, their uses must ensure proper
synchronization between them (e.g. through locking).

In addition, freq_qos_add_notifier() and freq_qos_remove_notifier()
are provided to add and remove notifiers that will trigger on aggregate
constraint changes to and from a given struct freq_constraints object,
respectively.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

PM: QoS: Get rid of unused flags

2019-08-20T22:38:54+00:00

The network_latency and network_throughput flags for PM-QoS have not
found much use in drivers or in userspace since they were introduced.

Commit 4a733ef1bea7 ("mac80211: remove PM-QoS listener") removed the
only user PM_QOS_NETWORK_LATENCY in the kernel a while ago and there
don't seem to be any userspace tools using the character device files
either.

PM_QOS_MEMORY_BANDWIDTH was never even added to the trace events.

Remove all the flags except cpu_dma_latency.

Signed-off-by: Amit Kucheria 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Add support for MIN/MAX frequency constraints

2019-07-04T08:40:54+00:00

This patch introduces the min-frequency and max-frequency device
constraints, which will be used by the cpufreq core to begin with.

Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Ulf Hansson 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

PM / QOS: Pass request type to dev_pm_qos_read_value()

2019-07-04T08:40:54+00:00

In order to allow dev_pm_qos_read_value() to read values for different
QoS requests, pass request type as a parameter to these routines.

For now, it only supports resume-latency request type but will be
extended to frequency limit (min/max) constraints later on.

Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Ulf Hansson 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()

2019-07-04T08:40:54+00:00

dev_pm_qos_read_value() will soon need to support more constraint types
(min/max frequency) and will have another argument to it, i.e. type of
the constraint. While that is fine for the existing users of
dev_pm_qos_read_value(), but not that optimal for the callers of
__dev_pm_qos_read_value() and dev_pm_qos_raw_read_value() as all the
callers of these two routines are only looking for resume latency
constraint.

Lets make these two routines care only about the resume latency
constraint and rename them to __dev_pm_qos_resume_latency() and
dev_pm_qos_raw_resume_latency().

Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()

2019-07-04T08:40:54+00:00

In order to use the same set of routines to register notifiers for
different request types, update the existing
dev_pm_qos_{add|remove}_notifier() routines with an additional
parameter: request-type.

For now, it only supports resume-latency request type but will be
extended to frequency limit (min/max) constraints later on.

Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Ulf Hansson 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-qos'

2017-11-13T00:33:48+00:00

* pm-qos:
  PM / QoS: Fix device resume latency framework
  PM / QoS: Drop PM_QOS_FLAG_REMOTE_WAKEUP

PM / QoS: Fix device resume latency framework

2017-11-08T11:14:51+00:00

The special value of 0 for device resume latency PM QoS means
"no restriction", but there are two problems with that.

First, device resume latency PM QoS requests with 0 as the
value are always put in front of requests with positive
values in the priority lists used internally by the PM QoS
framework, causing 0 to be chosen as an effective constraint
value.  However, that 0 is then interpreted as "no restriction"
effectively overriding the other requests with specific
restrictions which is incorrect.

Second, the users of device resume latency PM QoS have no
way to specify that *any* resume latency at all should be
avoided, which is an artificial limitation in general.

To address these issues, modify device resume latency PM QoS to
use S32_MAX as the "no constraint" value and 0 as the "no
latency at all" one and rework its users (the cpuidle menu
governor, the genpd QoS governor and the runtime PM framework)
to follow these changes.

Also add a special "n/a" value to the corresponding user space I/F
to allow user space to indicate that it cannot accept any resume
latencies at all for the given device.

Fixes: 85dc0b8a4019 (PM / QoS: Make it possible to expose PM QoS latency constraints)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323
Reported-by: Reinette Chatre 
Signed-off-by: Rafael J. Wysocki 
Tested-by: Reinette Chatre 
Tested-by: Geert Uytterhoeven 
Tested-by: Tero Kristo 
Reviewed-by: Ramesh Thomas