kernel/linux.git/drivers/base/power/qos.c, branch v6.3

PM / QoS: Restore DEV_PM_QOS_MIN/MAX_FREQUENCY

2019-11-29T11:04:50+00:00

Support for adding per-device frequency limits was removed in commit 2aac8bdf7a0f ("PM: QoS: Drop frequency QoS types from device PM QoS") after cpufreq switched to use a new "freq_constraints" construct. Restore support for per-device freq limits but base this upon freq_constraints. This is primarily meant to be used by the devfreq subsystem. This removes the "static" marking on freq_qos_apply but does not export it for modules. Signed-off-by: Leonard Crestez Reviewed-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke Signed-off-by: Rafael J. Wysocki

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: 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

drivers: base: power: add proper SPDX identifiers on files that did not have them.

2019-04-04T18:03:40+00:00

There were a few files in the driver core power code that did not have SPDX identifiers on them, so fix that up. At the same time, remove the "free form" text that specified the license of the file, as that is impossible for any tool to properly parse. Cc: "Rafael J. Wysocki" Signed-off-by: Greg Kroah-Hartman

PM / QoS: Fix typo in file description

2019-03-11T09:35:53+00:00

Fix a typo in the file description comment. Signed-off-by: Dong Aisheng Signed-off-by: Rafael J. Wysocki

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

PM / QoS: Use the correct variable to check the QoS request type

2017-09-18T11:38:30+00:00

Use the actual function argument for the validation of the request type, instead of the type field in a fresh (supposedly zero-initialized) request structure. Signed-off-by: Jan H. Schönherr Signed-off-by: Rafael J. Wysocki