summaryrefslogtreecommitdiff
path: root/tools/power/cpupower/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2025-03-07cpupower: Make lib versioning scheme more obvious and fix version linkThomas Renninger1-8/+11
library versioning was broken: libcpupower.so.0.0.1 libcpupower.so -> libcpupower.so.0.0.1 libcpupower.so.1 -> libcpupower.so.0.0.1 and is fixed by this patch to: libcpupower.so.1.0.1 libcpupower.so -> libcpupower.so.1.0.1 libcpupower.so.1 -> libcpupower.so.1.0.1 Link: https://lore.kernel.org/r/20250307094334.39587-1-trenn@suse.de Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Shuah Khan <shuah@kernel.org>
2024-12-09pm: cpupower: Makefile: Fix cross compilationPeng Fan1-0/+8
After commit f79473ed9220 ("pm: cpupower: Makefile: Allow overriding cross-compiling env params") we would fail to cross compile cpupower in buildroot which uses the recipe at [1] where only the CROSS variable is being set. The issue here is the use of the lazy evaluation for all variables: CC, LD, AR, STRIP, RANLIB, rather than just CROSS. [1]: https://git.buildroot.net/buildroot/tree/package/linux-tools/linux-tool-cpupower.mk.in Fixes: f79473ed9220 ("pm: cpupower: Makefile: Allow overriding cross-compiling env params") Reported-by: Florian Fainelli <florian.fainelli@broadcom.com> Closes: https://lore.kernel.org/all/2bbabd2c-24ef-493c-a199-594e5dada3da@broadcom.com/ Signed-off-by: Peng Fan <peng.fan@nxp.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-10-21cpupower: add checks for xgettext and msgfmtSiddharth Menon1-0/+12
Check whether xgettext and msgfmt are available on the system before attempting to generate GNU gettext Language Translations. In case of missing dependency, generate error message directing user to install the necessary package. Tested-by: John B. Wyatt IV <jwyatt@redhat.com> Tested-by: John B. Wyatt IV <sageofredondo@gmail.com> Suggested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Siddharth Menon <simeddon@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-10-15cpupower: Add Chinese Simplified translationKieran Moy1-1/+1
Add Chinese Simplified translations for cpufrequtils package. Signed-off-by: Kieran Moy <kfatyuip@gmail.com> Reviewed-by: Candice Cheng <ccheng@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-09-30pm: cpupower: Makefile: Allow overriding cross-compiling env paramsPeng Fan1-6/+6
Allow overriding the cross-comple env parameters to make it easier for Yocto users. Then cross-compiler toolchains to build cpupower with only two steps: - source (toolchain path)/environment-setup-armv8a-poky-linux - make Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-07-02cpupower: fix lib default installation pathRoman Storozhenko1-9/+1
Invocation the tool built with the default settings fails: $ cpupower cpupower: error while loading shared libraries: libcpupower.so.1: cannot open shared object file: No such file or directory The issue is that Makefile puts the library to "/usr/lib64" dir for a 64 bit machine. This is wrong. According to the "File hierarchy standard specification: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf "/usr/lib<qual>" dirs are intended for alternative-format libraries (e.g., "/usr/lib32" for 32-bit libraries on a 64-bit machine (optional)). The utility is built for the current machine and doesn't handle 'CROSS_COMPILE' and 'ARCH' env variables. It also doesn't change bit depth. So the result is always the same - binary for x86_64 architecture. Therefore the library should be put in the '/usr/lib' dir regardless of the build options. This is the case for all the distros that comply with the 'File Hierarchy Standard 3.0" by Linux Foundation. Most of the distros comply with it. For example, one can check this by examining the "/usr/lb64" dir on debian-based distros and find that it contains only "/usr/lib64/ld-linux-x86-64.so.2". And examine that "/usr/lib" contains both 32 and 64 bit code: find /usr/lib -name "*.so*" -type f | xargs file | grep 32-bit find /usr/lib -name "*.so*" -type f | xargs file | grep 64-bit Fix the issue by changing library destination dir to "/usr/lib". Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-06-18cpupower: Add 'help' target to the main MakefileRoman Storozhenko1-1/+36
Make "cpupower" building process more user friendly by adding 'help' target to the main makefile. This target describes various build and cleaning options available to the user. Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-08-17cpupower: Add Georgian translation to Makefile LANGUAGESShuah Khan1-1/+1
Commit 4680b734e729 ("cpupower: Add Georgian translation") added new language support. This change didn't add "ka" to Makefile LANGUAGES variable. Add it now. Reported-by: Temuri Doghonadze <temuri.doghonadze@gmail.com> Reported-by: Zurab Kargareteli <zuraxt@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-07-13cpupower: Bump soname versionBen Hutchings1-1/+1
Several functions in the libcpupower API are renamed or removed in Linux 4.7. This is an backward-incompatible ABI change, so the library soname should change from libcpupower.so.0 to libcpupower.so.1. Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-30cpupower: rapl monitor - shows the used power consumption in uj for each ↵Thomas Renninger1-0/+1
rapl domain This CPU power monitor shows the power consumption as exposed by the powercap subsystem, cmp with: Documentation/power/powercap/powercap.rst cpupower monitor -m RAPL | RAPL CPU| pack | core | unco 0|6853926|967832|442381 8|6853926|967832|442381 1|6853926|967832|442381 9|6853926|967832|442381 Unfortunately RAPL domains cannot be directly mapped to the corresponding CPU socket/package, core it belongs to. Not sure this is possible at all with the current data exposed from the kernel. Still it can be worthful information for developers trying to optimize power consumption of workloads or their system in general. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Zhang Rui <rui.zhang@intel.com> CC: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-30cpupower: Introduce powercap intel-rapl library and powercap-info commandThomas Renninger1-4/+10
Read out powercap zone information via: cpupower powercap-info and show the zone hierarchy to the user: ./cpupower powercap-info Driver: intel-rapl Powercap domain hierarchy: Zone: package-0 (enabled) Power consumption can be monitored in micro Watts Zone: core (disabled) Power consumption can be monitored in micro Watts Zone: uncore (disabled) Power consumption can be monitored in micro Watts Zone: dram (disabled) Power consumption can be monitored in micro Watts There is a dummy -a option for powercap-info which can/should be used to show more detailed info later. Like that other args can be added easily later as well. A enable/disable option via powercap-set subcommand is also an enhancement for later. Also not all RAPL domains are shown. The func walking through RAPL subdomains is restricted and hardcoded to: "intel-rapl/intel-rapl:0" On my system above powercap domains map to: intel-rapl/intel-rapl:0 -> pack (age-0) intel-rapl/intel-rapl:0/intel-rapl:0:0 -> core intel-rapl/intel-rapl:0/intel-rapl:0:1 -> uncore Missing ones on my system are: intel-rapl-mmio/intel-rapl-mmio:0 -> pack (age-0) intel-rapl/intel-rapl:1 -> psys This could get enhanced in: struct powercap_zone *powercap_init_zones() and adopted to walk through all intel-rapl zones, but also to other powercap drivers like dtpm (Dynamic Thermal Power Management framework), cmp with: drivers/powercap/dtpm_* Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-22cpupower: Introduce ACPI CPPC libraryHuang Rui1-3/+3
Kernel ACPI subsytem introduced the sysfs attributes for acpi cppc library in below path: /sys/devices/system/cpu/cpuX/acpi_cppc/ And these attributes will be used for AMD P-State driver to provide some performance and frequency values. Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-01-05cpupower: add Makefile dependencies for install targetsIvan Babrou1-4/+4
This allows building cpupower in parallel rather than serially. Signed-off-by: Ivan Babrou <ivan@cloudflare.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2020-08-20cpupower: speed up generating git version stringMartin Kaistra1-1/+1
The variable VERSION is expanded for every use of CFLAGS. This causes "git describe" to get called multiple times on the kernel tree, which can be quite slow. The git revision does not change during build, so we can use simple variable expansion to set VERSION. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-08-29tools/power/cpupower: fix 64bit detection when cross-compilingSébastien Szymanski1-6/+8
When cross-compiling cpupower, 64bit detection is done with the host compiler instead of the cross-compiler and libcpupower.so.0 ends up in /usr/lib64 instead of /usr/lib for 32bit target. Fix this by moving 64bit detection after CC is defined. Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 167Thomas Gleixner1-13/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 83 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.021731668@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05cpupower : Auto-completion for cpupower toolAbhishek Goel1-1/+5
This script adds support for auto-completion for cpupower tool. Added support for auto-completion of all the eight commands for cpupower tool and their all subsequent sub-commands, wherever possible. A sample output after applying this script - root@ubuntu:~# cpupower f<TAB> root@ubuntu:~# cpupower frequency-<TAB> frequency-info frequency-set root@ubuntu:~# cpupower frequency-set - -d --freq --governor --min --related -f -g --max -r -u root@ubuntu:~# cpupower frequency-set -g <TAB> conservative ondemand performance powersave schedutil userspace root@ubuntu:~# cpupower frequency-set -f <TAB> 2061000 2194000 2327000 2460000 2593000 2726000 2859000 2094000 2227000 2360000 2493000 2626000 2759000 2892000 2128000 2261000 2394000 2527000 2660000 2793000 2926000 2161000 2294000 2427000 2560000 2693000 2826000 2959000 root@ubuntu:~# cpupower frequency-set -f 206<TAB> root@ubuntu:~# cpupower frequency-set -f 2061000 Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com> Signed-off-by: Bharath Thodla <bharath.thodla@in.ibm.com> Tested-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Shuah Khan <shuah@kernel.org>
2018-11-06tools cpupower: Override CFLAGS assignmentsJiri Olsa1-6/+6
So user could specify outside CFLAGS values. Cc: Thomas Renninger <trenn@suse.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
2017-11-18kbuild: /bin/pwd -> pwdBjørn Forsman1-1/+1
Most places use pwd and rely on $PATH lookup. Moving the remaining absolute path /bin/pwd users over for consistency. Also, a reason for doing /bin/pwd -> pwd instead of the other way around is because I believe build systems should make little assumptions on host filesystem layout. Case in point, we do this kind of patching already in NixOS. Ref. commit 028568d84da3cfca49f5f846eeeef01441d70451 ("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)"). Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-11-09tools/power/cpupower: Add 64 bit library detectionPrarit Bhargava1-0/+6
The kernel-tools-lib rpm is installing the library to /usr/lib64, and not /usr/lib as the cpupower Makefile is doing in the kernel tree. This resulted in a conflict between the two libraries. After looking at how other tools installed libraries, and looking at the perf code in tools/perf it looks like installing to /usr/lib64 for 64-bit arches is the correct thing to do. Checks with 'ldd cpupower' on SLES, RHEL, Fedora, and Ubuntu result in the correct binary AFAICT: [root@testsystem cpupower]# ldd cpupower | grep cpupower libcpupower.so.0 => /lib64/libcpupower.so.0 (0x00007f1dab447000) Commit ac5a181d065d ("cpupower: Add cpuidle parts into library") added a new cpupower library version. On Fedora, executing the cpupower binary then resulted in this error [root@testsystem cpupower]# ./cpupower monitor ./cpupower: symbol lookup error: ./cpupower: undefined symbol: get_cpu_topology 64-bit libraries should be installed to /usr/lib64, and other libraries should be installed to /usr/lib. This code was taken from the perf Makefile.config which supports /usr/lib and /usr/lib64. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-10-07kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)Masahiro Yamada1-1/+1
I thought commit 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)") was a safe conversion, but it changed the behavior. $(abspath ...) / $(realpath ...) does not expand shell special characters, such as '~'. Here is a simple Makefile example: ---------------->8---------------- $(info /bin/pwd: $(shell cd ~/; /bin/pwd)) $(info abspath: $(abspath ~/)) $(info realpath: $(realpath ~/)) all: @: ---------------->8---------------- $ make /bin/pwd: /home/masahiro abspath: /home/masahiro/workspace/~ realpath: This can be a real problem if 'make O=~/foo' is invoked from another Makefile or primitive shell like dash. This commit partially reverts 8e9b46679923. Fixes: 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)") Reported-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Julien Grall <julien.grall@arm.com>
2017-09-01kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)Masahiro Yamada1-1/+1
Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get the absolute path of the directory because GNU Make 3.80, the minimal supported version at that time, did not support $(abspath ...) or $(realpath ...). Commit 37d69ee30808 ("docs: bump minimal GNU Make version to 3.81") dropped the GNU Make 3.80 support, so we are now allowed to use those make-builtin helpers. This conversion will provide better portability without relying on the pwd command or its location /bin/pwd. I am intentionally using $(realpath ...) instead $(abspath ...) in some places. The difference between the two is $(realpath ...) returns an empty string if the given path does not exist. It is convenient in places where we need to error-out if the makefile fails to create an output directory. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Thierry Reding <treding@nvidia.com>
2016-12-11make use of make variable CURDIR instead of calling pwdUwe Kleine-König1-3/+0
make already provides the current working directory in a variable, so make use of it instead of forking a shell. Also replace usage of PWD by CURDIR. PWD is provided by most shells, but not all, so this makes the build system more robust. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-04-28cpupower: Add cpuidle parts into libraryThomas Renninger1-5/+7
This more or less is a renaming and moving of functions and should not introduce any functional change. cpupower was built from cpufrequtils (which had a C library providing easy access to cpu frequency platform info). In the meantime it got enhanced by quite some neat cpuidle userspace tools. Now the cpu idle functions have been separated and added to the cpupower.so library. So beside an already existing public header file: cpufreq.h cpupower now also exports these cpu idle functions in: cpuidle.h Here again pasted for better review of the interfaces: ====================================== int cpuidle_is_state_disabled(unsigned int cpu, unsigned int idlestate); int cpuidle_state_disable(unsigned int cpu, unsigned int idlestate, unsigned int disable); unsigned long cpuidle_state_latency(unsigned int cpu, unsigned int idlestate); unsigned long cpuidle_state_usage(unsigned int cpu, unsigned int idlestate); unsigned long long cpuidle_state_time(unsigned int cpu, unsigned int idlestate); char *cpuidle_state_name(unsigned int cpu, unsigned int idlestate); char *cpuidle_state_desc(unsigned int cpu, unsigned int idlestate); unsigned int cpuidle_state_count(unsigned int cpu); char *cpuidle_get_governor(void); char *cpuidle_get_driver(void); ====================================== Signed-off-by: Thomas Renninger <trenn@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03cpupower: Provide STATIC variable in Makefile for debug buildsThomas Renninger1-0/+19
When working on cpupower code, you often want to compile library code into the binary. This allows to execute modified cpupower code, even with library changes without doing "make install" Signed-off-by: Thomas Renninger <trenn@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-11Revert "cpupower Makefile change to help run the tool without 'make install'"Josh Boyer1-1/+1
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 <jwboyer@feoraproject.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-30cpupower Makefile change to help run the tool without 'make install'sriram@marirs.net.in1-1/+1
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 <sriram@marirs.net.in> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-03Merge branches 'acpi-tools' and 'pm-tools'Rafael J. Wysocki1-2/+8
* acpi-tools: ACPI / tools: Introduce ec_access.c - tool to access the EC * pm-tools: cpupower: Remove mc and smt power aware scheduler info/settings cpupower: cpupower info -b should return 0 on success, not the perf bias value cpupower: If root, try to load msr driver on x86 if /dev/cpu/0/msr is not available cpupower: Install recently added cpupower-idle-{set, info} manpages cpupower: Introduce idle state disable-by-latency and enable-all cpupower: Remove all manpages on make uninstall cpupower: Remove dead link to homepage, and update the targets built. cpupower: Rename cpufrequtils -> cpupower, and libcpufreq -> libcpupower. PM / tools: cpupower: add option to display values without round offs tools / power: turbostat: Drop temperature checks
2014-05-17cpupower: Install recently added cpupower-idle-{set, info} manpagesThomas Renninger1-0/+2
Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17cpupower: Remove all manpages on make uninstallRamkumar Ramachandra1-2/+6
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-01cpufreq: Make linux-pm@vger.kernel.org official mailing listViresh Kumar1-1/+1
There has been confusion all the time about which mailing list to follow for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org. Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork which is a maintenance workflow problem, make linux-pm@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpufreq@vger.kernel.org from kernel source. Later, we can request that the list be dropped entirely. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-05cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 statesThomas Renninger1-0/+1
This specific processor supports 3 new package sleep states. Provide a monitor, so that the user can see their usage. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-05cpupower: Introduce idle-set subcommand and C-state enabling/disablingThomas Renninger1-1/+2
Example: cpupower idle-set -d 3 will disable C-state 3 on all processors (set commands are active on all CPUs by default), same as: cpupower -c all idle-set -d 3 Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-27cpupower tools: Remove brace expansion from clean targetPalmer Cox1-1/+2
The clean targets from the cpupower tools' Makefiles use brace expansion to remove some generated files. However, the default shells on many systems do not support this feature resulting in some generated files not being removed by clean. Signed-off-by: Palmer Cox <p@lmercox.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-03kbuild: Fix gcc -x syntaxJean Delvare1-1/+1
The correct syntax for gcc -x is "gcc -x assembler", not "gcc -xassembler". Even though the latter happens to work, the former is what is documented in the manual page and thus what gcc wrappers such as icecream do expect. This isn't a cosmetic change. The missing space prevents icecream from recognizing compilation tasks it can't handle, leading to silent kernel miscompilations. Besides me, credits go to Michael Matz and Dirk Mueller for investigating the miscompilation issue and tracking it down to this incorrect -x parameter syntax. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Bernhard Walle <bernhard@bwalle.de> Cc: Michal Marek <mmarek@suse.cz> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2012-03-03cpupower tool: allow to build in a separate directoryFranck Bui-Huu1-31/+56
This patch allows cpupower tool to generate its output files in a seperate directory. This is now possible by passing the 'O=<path>' to the command line. This can be usefull for a normal user if the kernel source code is located in a read only location. This is patch stole some bits of the perf makefile. [linux@dominikbrodowski.net: fix commit message] Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2012-03-03cpupower tool: makefile: simplify the recipe used to generate cpupower.pot ↵Franck Bui-Huu1-3/+1
target Use the '-p' and '-o' switches to specify the pathname of the output file to xgettext(1). This avoids to move manually the output file if xgettext(1) succeeds. Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2012-03-03cpupower tool: remove use of undefined variables from the clean target of ↵Franck Bui-Huu1-2/+0
the top makefile UTIL_BINS and IDLE_OBJS variables are not defined at all, so there's no need to remove their content from the 'clean' target. Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2012-03-03cpupower: Fix linking with --as-neededOzan Çağlayan1-1/+1
Fix linking order to avoid undefined reference errors when using --as-needed linker flag. Signed-off-by: Ozan Çağlayan <ozan@pardus.org.tr> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-08-19cpupower: make NLS truly optionalDominik Brodowski1-0/+1
Loosely based on a patch for cpufrequtils, submittted by Sergey Dryabzhinsky <sergey.dryabzhinsky@gmail.com> and signed-off-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-08-19cpupower: fix Makefile typoDave Jones1-2/+2
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-08-15cpupower: mperf monitor - Use TSC to calculate max frequency if possibleThomas Renninger1-1/+1
Which makes the implementation independent from cpufreq drivers. Therefore this would also work on a Xen kernel where the hypervisor is doing frequency switching and idle entering. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupower: Rename package from cpupowerutils to cpupowerThomas Renninger1-6/+6
Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils: Rename: libcpufreq->libcpupowerThomas Renninger1-13/+13
[linux@dominikbrodowski.net: fix .gitignore] Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils: use kernel version-derived version stringDominik Brodowski1-7/+6
As cpupowerutils is intended to be included into the kernel sources, use the kernel versioning instead of a custom version. The script utils/version-gen.sh is largely based on the script already found in tools/perf/util/PERF-VERSION-GEN . Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils: bench - ConfigStyle bugfixesDominik Brodowski1-3/+2
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils: do not update po files on each and every compileDominik Brodowski1-7/+16
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils: remove ccdv, use kernel quiet/verbose mechanismDominik Brodowski1-16/+15
Use the quiet/verbose mechanism found in kernel tools, without relying on the special tool "ccdv" Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2011-07-29cpupowerutils - cpufrequtils extended with quite some featuresDominik Brodowski1-0/+273
CPU power consumption vs performance tuning is no longer limited to CPU frequency switching anymore: deep sleep states, traditional dynamic frequency scaling and hidden turbo/boost frequencies are tied close together and depend on each other. The first two exist on different architectures like PPC, Itanium and ARM, the latter (so far) only on X86. On X86 the APU (CPU+GPU) will only run most efficiently if CPU and GPU has proper power management in place. Users and Developers want to have *one* tool to get an overview what their system supports and to monitor and debug CPU power management in detail. The tool should compile and work on as many architectures as possible. Once this tool stabilizes a bit, it is intended to replace the Intel-specific tools in tools/power/x86 Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>