[patch 30/86] PM / QoS: CPU C-state breakage with PM Qos change

From: Greg KH
Date: Fri Feb 10 2012 - 17:43:01 EST


3.2-stable review patch. If anyone has any objections, please let me know.

------------------

From: Venkatesh Pallipadi <venki@xxxxxxxxxx>

commit d020283dc694c9ec31b410f522252f7a8397e67d upstream.

Looks like change "PM QoS: Move and rename the implementation files"
merged during the 3.2 development cycle made PM QoS depend on
CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME).

That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs
to spend time in Polling loop idle instead of going into deep C-states,
consuming way way more power. This is with either acpi idle or intel idle
enabled.

Either CONFIG_PM should be enabled with any pm_qos users or
the !CONFIG_PM pm_qos_request() should return sane defaults not to break
the existing users. Here's is the patch for the latter option.

[rjw: Modified the changelog slightly.]

Signed-off-by: Venkatesh Pallipadi <venki@xxxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rjw@xxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

---
include/linux/pm_qos.h | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -107,7 +107,19 @@ static inline void pm_qos_remove_request
{ return; }

static inline int pm_qos_request(int pm_qos_class)
- { return 0; }
+{
+ switch (pm_qos_class) {
+ case PM_QOS_CPU_DMA_LATENCY:
+ return PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
+ case PM_QOS_NETWORK_LATENCY:
+ return PM_QOS_NETWORK_LAT_DEFAULT_VALUE;
+ case PM_QOS_NETWORK_THROUGHPUT:
+ return PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE;
+ default:
+ return PM_QOS_DEFAULT_VALUE;
+ }
+}
+
static inline int pm_qos_add_notifier(int pm_qos_class,
struct notifier_block *notifier)
{ return 0; }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/