linux-toradex.git/tools/power/cpupower, branch v4.2.3

cpupower: mperf monitor: fix output in MAX_FREQ_SYSFS mode

2015-05-30T00:21:31+00:00

There is clearly wrong output when mperf monitor runs in MAX_FREQ_SYSFS mode:
average frequency shows in kHz unit (despite the intended output to be in MHz),
and percentages for C state information are all wrong (including high/negative
values shown).

The problem is that the max_frequency read on initialization isn't used where it
should have been used on mperf_get_count_percent (to estimate the number of
ticks in the given time period), and the value we read from sysfs is in kHz, so
we must divide it to get the MHz value to use in current calculations.

While at it, also I fixed another small issues in the debug output of
max_frequency value in mperf_get_count_freq.

Signed-off-by: Herton R. Krzesinski 
Acked-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

cpupower: fix breakage from libpci API change

2015-04-15T19:54:26+00:00

libpci 3.3.0 introduced an additional member in the pci_filter struct
which needs to be initialized to -1 to get the same behavior as before
the API change. The libpci internal helpers got updated accordingly,
but as the cpupower pci helpers initialized the struct themselves the
behavior changed.

Use the libpci helper pci_filter_init() to fix this and guard against
similar breakages in the future.

This fixes probing of the AMD fam12h/14h cpuidle monitor on systems
with libpci >= 3.3.0.

Signed-off-by: Lucas Stach 
Acked-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

Revert "cpupower Makefile change to help run the tool without 'make install'"

2015-03-11T20:56:49+00:00

This reverts commit 5c1de006e8e66b0be05be422416629e344c71652.

While the original commit makes it easier to run cpupower from the
local build directory, it also leaves the binary with a rather poor
rpath of './' in it after it is installed on a system via 'make install'.

This is considered bad practice and can cause cpupower to fail in
rpmbuild with the following error:

ERROR   0004: file '/usr/bin/cpupower' contains an insecure rpath './' in [./]
error: Bad exit status from /var/tmp/rpm-tmp.A6u26r (%install)
    Bad exit status from /var/tmp/rpm-tmp.A6u26r (%install)

Developers should be able to use LD_LIBRARY_PATH to achieve the same
effect and not introduce rpath into the binary.

Signed-off-by: Josh Boyer 
Signed-off-by: Rafael J. Wysocki

cpupower Makefile change to help run the tool without 'make install'

2015-01-30T00:47:41+00:00

The cpupower tool, when compiled against libcpupower.so fail's to run as
the linker file path's are missing during compilation. So added changes
in the Makefile to run cpupower tool, which helps us run the tool
without doing a 'make install'.

Signed-off-by: Sriram Raghunathan 
Acked-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

tools / cpupower: Fix no idle state information return value

2014-12-19T22:01:12+00:00

sysfs_get_idlestate_count() returns an unsigned int.  Returning -ENODEV
is not the right thing to do here, and in any case is handled the same
way as if there are no states found.

Signed-off-by: Prarit Bhargava 
Acked-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

tools / cpupower: Correctly detect if running as root

2014-12-19T22:01:03+00:00

Some operations, like frequency-set, need root privileges. However,
the way that this is detected is not correct. The getuid() is called,
while in fact geteuid() should be. This way we can allow
distributions or users to set SETUID flags on the cpupower binary if
they want to and let regular users change the cpu frequency governor.

Signed-off-by: Michal Privoznik 
Acked-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki

Revert "tools: cpupower: fix return checks for sysfs_get_idlestate_count()"

2014-12-14T21:14:16+00:00

This reverts commit 16b7c275c055cc36218404b5d147be7f76575087.

My previous commit 16b7c275c055 ("tools: cpupower: fix return checks for
sysfs_get_idlestate_count()") was not correct.  After looking
at the changelog for cpupower I noticed that Thomas had changed the return of
sysfs_get_idlestate_count() to an unsigned int to simplify the code.  The
problem is really that both he (in his original change) and I (in my new
change) missed the obvious that sysfs_get_idlestate_count()
can't return -ENODEV.  It should just return 0 for "no c-states".

Fixes: 16b7c275c055 (tools: cpupower: fix return checks for ...)
Signed-off-by: Prarit Bhargava 
Signed-off-by: Rafael J. Wysocki

tools: cpupower: fix return checks for sysfs_get_idlestate_count()

2014-12-05T02:12:34+00:00

Red Hat and Fedora use a bug reporting tool that gathers data about
"broken" systems called sosreport.  Among other things, it includes the
output of 'cpupower idle-info'.  Executing 'cpupower idle-info' on a
system that has cpuidle disabled via 'cpuidle.off=1' results in a 300
second hang in the cpupower application.

ie)
[root@intel-brickland-05]# cpupower idle-info
Could not determine cpuidle driver

Analyzing CPU 0:
Number of idle states: -19
[hang]

The problem is that the cpupower code only checks for a zero return from
sysfs_get_idlestate_count().  The function can return -ENODEV (-19) as
above.  This patch fixes callers to sysfs_get_idlestate_count() to check
the right return values.

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

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: bench: parse.c: Fix several minor errors

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

Resolved several minor errors in prepare_config() and made some additional improvements.
Earlier, the risk of file stream that was not closed. Misuse of strncpy, and the use of strncmp with strlen that makes it pointless.
I also check that sscanf has been successful, otherwise continue to the next line. And minimized the use of magic numbers.

This was found using a static code analysis program called cppcheck.

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