linux.git/tools/power/cpupower/utils, branch v3.17

cpupower: Remove redundant error check

2014-07-29T23:57:13+00:00

Remove double checks, and move the call to print_error to the
first check. Replace break by return, and return 0 on success.
The simplified version of the coccinelle semantic patch that
fixes this issue is as follows:

// 
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
-	if (E) break;
+	if (E){
+		pr(es);
+		break;
+	}
...
}
- if(E) pr(es);
// 

Signed-off-by: Peter Senna Tschudin 
Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

cpupower: mperf monitor: Correct use of ! and &

2014-07-29T23:57:12+00:00

In commit ae91d60ba88ef0bdb1b5e9b2363bd52fc45d2af7, a bug was fixed that
involved converting !x & y to !(x & y).  The code below shows the same
pattern, and thus should perhaps be fixed in the same way.

The Coccinelle semantic patch that makes this change is as follows:

// 
@@ expression E1,E2; @@
(
  !E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// 

Signed-off-by: Himangi Saraogi 
Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

PM / tools: cpupower: drop negativity check on unsigned value

2014-07-19T19:41:17+00:00

Link: https://bugzilla.kernel.org/show_bug.cgi?id=80621
Reported-by: David Binderman 
Signed-off-by: Andrey Utkin 
Signed-off-by: Rafael J. Wysocki

cpupower: Remove mc and smt power aware scheduler info/settings

2014-05-16T22:36:37+00:00

These kernel interfaces got removed by:

commit 8e7fbcbc22c12414bcc9dfdd683637f58fb32759
Author: Peter Zijlstra 
Date:   Mon Jan 9 11:28:35 2012 +0100

    sched: Remove stale power aware scheduling remnants and dysfunctional knobs

No need to further keep them as userspace configurations.

Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

cpupower: cpupower info -b should return 0 on success, not the perf bias value

2014-05-16T22:36:37+00:00

Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

cpupower: If root, try to load msr driver on x86 if /dev/cpu/0/msr is not available

2014-05-16T22:36:36+00:00

Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

cpupower: Introduce idle state disable-by-latency and enable-all

2014-05-16T22:36:36+00:00

Signed-off-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

PM / tools: cpupower: add option to display values without round offs

2014-05-06T22:19:06+00:00

The command "cpupower frequency-info" can be used when using cpupower to
monitor and test processor behaviour to determine if the processor is
behaving as expected. This data can be compared to the output of
/proc/cpuinfo or the output of
/sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies
to determine if the cpu is in an expected state.

When doing this I noticed comparison test failures due to the way the
data is displayed in cpupower. For example,

[root@intel-s3e37-02 cpupower]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2262000 2261000 2128000 1995000 1862000 1729000 1596000 1463000 1330000
1197000 1064000

compared to

[root@intel-s3e37-02 cpupower]# cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.06 GHz - 2.26 GHz
available frequency steps: 2.26 GHz, 2.26 GHz, 2.13 GHz, 2.00 GHz, 1.86 GHz, 1.73 GHz, 1.60 GHz, 1.46 GHz, 1.33 GHz, 1.20 GHz, 1.06 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 1.06 GHz and 2.26 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.26 GHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes

shows very different values for the available frequency steps. The cpupower
output rounds off values at 2 decimal points and this causes problems with
test scripts. For example, with the data above,

1.064 is 1.06
1.197 is 1.20
1.596 is 1.60
1.995 is 2.00
2.128 is 2.13

and most confusingly,

2.261 is 2.26
2.262 is 2.26

Truncating these values serves no real purpose other than making the output
pretty. Since the default has been to round off these values I am adding
a -n/--no-rounding option to the cpupower utility that will display the
data without rounding off the still significant digits.

After patch,

analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.000 us.
hardware limits: 1.064000 GHz - 2.262000 GHz
available frequency steps: 2.262000 GHz, 2.261000 GHz, 2.128000 GHz, 1.995000 GHz, 1.862000 GHz, 1.729000 GHz, 1.596000 GHz, 1.463000 GHz, 1.330000 GHz, 1.197000 GHz, 1.064000 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 1.064000 GHz and 2.262000 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.262000 GHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes

Acked-by: Thomas Renninger
Signed-off-by: Prarit Bhargava
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-tools' and 'pm-tools'

2014-01-17T00:59:48+00:00

* acpi-tools:
  ACPICA: acpidump: Update MAINTAINERS file to include tools folder for ACPI/ACPICA.
  ACPICA: acpidump: Enable tools Makefile to include acpi tools.
  ACPICA: acpidump: Cleanup tools/power/acpi makefiles.

* pm-tools:
  PM / tools: new tool for suspend/resume performance optimization
  cpupower: Fix sscanf robustness in cpufreq-set

cpupower: Fix sscanf robustness in cpufreq-set

2014-01-08T14:10:39+00:00

The cpufreq-set tool has a missing length check. This is basically
just correctness but still should get fixed.

One of a set of sscanf problems reported by Jackie Chang

Signed-off-by: Alan Cox 
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki