Commit Graph

76 Commits

Author SHA1 Message Date
Linus Torvalds
fec98069fb Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cpu updates from Ingo Molnar:
 "The main changes in this cycle were:

   - Add support for the "Dhyana" x86 CPUs by Hygon: these are licensed
     based on the AMD Zen architecture, and are built and sold in China,
     for domestic datacenter use. The code is pretty close to AMD
     support, mostly with a few quirks and enumeration differences. (Pu
     Wen)

   - Enable CPUID support on Cyrix 6x86/6x86L processors"

* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tools/cpupower: Add Hygon Dhyana support
  cpufreq: Add Hygon Dhyana support
  ACPI: Add Hygon Dhyana support
  x86/xen: Add Hygon Dhyana support to Xen
  x86/kvm: Add Hygon Dhyana support to KVM
  x86/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/bugs: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/pci, x86/amd_nb: Add Hygon Dhyana support to PCI and northbridge
  x86/amd_nb: Check vendor in AMD-only functions
  x86/alternative: Init ideal_nops for Hygon Dhyana
  x86/events: Add Hygon Dhyana support to PMU infrastructure
  x86/smpboot: Do not use BSP INIT delay and MWAIT to idle on Dhyana
  x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number
  x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/CPU: Change query logic so CPUID is enabled before testing
  x86/CPU: Use correct macros for Cyrix calls
2018-10-23 16:16:40 +01:00
Prarit Bhargava
f69ffc5d3d cpupower: Fix coredump on VMWare
cpupower crashes on VMWare guests.  The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero.  As a result fid and did are zero
and the crash occurs because of a divide by zero (cof = fid/did).  This
can be prevented by checking the enable bit in the PStateDef MSR before
calculating cof.  By doing this the value of pstate[i] remains zero and
the value can be tested before displaying the active Pstates.

Check the enable bit in the PstateDef register for all supported families
and only print out enabled Pstates.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
2018-10-08 09:19:15 -06:00
Prarit Bhargava
8c22e2f695 cpupower: Fix AMD Family 0x17 msr_pstate size
The msr_pstate data is only 63 bits long and should be 64 bits.

Add in the missing bit from res1 for AMD Family 0x17.

Reference: https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf, page 138.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
2018-10-08 09:19:05 -06:00
Pu Wen
995d5f64b6 tools/cpupower: Add Hygon Dhyana support
The tool cpupower is useful to get CPU frequency information and monitor
power stats on the Hygon Dhyana platform. So add Hygon Dhyana support to
it by checking vendor and family to share the code path of AMD family
17h.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
CC: Prarit Bhargava <prarit@redhat.com>
CC: Shuah Khan <shuah@kernel.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Thomas Renninger <trenn@suse.com>
CC: linux-pm@vger.kernel.org
Link: http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.puwen@hygon.cn
2018-10-04 09:57:25 +02:00
Abhishek Goel
f9652d5cae cpupower : Fix header name to read idle state name
The names of the idle states in the output of cpupower monitor command are
truncated to 4 characters. On POWER9, this creates ambiguity as the states
are named "stop0", "stop1", etc.

root:~# cpupower monitor
              |Idle_Stats
PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop
   0|   0|   0|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  1.90
   0|   0|   1|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
   0|   0|   2|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
   0|   0|   3|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00

This patch modifies the output to print the state name that results in a
legible output. The names will be printed with atmost 1 padding in left.

root:~# cpupower monitor
              | Idle_Stats
 PKG|CORE| CPU|snooze|stop0L| stop0|stop1L| stop1|stop2L| stop2
   0|   0|   0|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.72
   0|   0|   1|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
   0|   0|   2|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
   0|   0|   3|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00

This patch does not affect the output for intel.
Output for intel before applying the patch:

root:~# cpupower monitor
    |Idle_Stats
CPU | POLL | C1-S | C1E- | C3-S | C6-S | C7s- | C8-S | C9-S | C10-
   0|  0.00|  0.14|  0.39|  0.35|  7.41|  0.00| 17.67|  1.01| 70.03
   2|  0.00|  0.19|  0.47|  0.10|  6.50|  0.00| 29.66|  2.17| 58.07
   1|  0.00|  0.11|  0.50|  1.50|  9.11|  0.18| 18.19|  0.40| 66.63
   3|  0.00|  0.67|  0.42|  0.03|  5.84|  0.00| 12.58|  0.77| 77.14

Output for intel after applying the patch:

root:~# cpupower monitor
    | Idle_Stats
 CPU| POLL | C1-S | C1E- | C3-S | C6-S | C7s- | C8-S | C9-S | C10-
   0|  0.03|  0.33|  1.01|  0.27|  3.03|  0.00| 19.18|  0.00| 71.24
   2|  0.00|  1.58|  0.58|  0.42|  8.55|  0.09| 21.11|  0.99| 63.32
   1|  0.00|  1.26|  0.88|  0.43|  9.00|  0.02|  7.78|  4.65| 71.91
   3|  0.00|  0.30|  0.42|  0.06| 13.62|  0.21| 30.29|  0.00| 52.45

Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
2018-05-29 10:48:33 -06:00
Rafael J. Wysocki
43d2d3b56d linux-cpupower-4.15-rc2
This update consists of fixes to tool's handling of offline cpus.
 The first patch fixes the tool to find information on the cpu it
 is running on, instead of always looking for cpu0 and failing if
 cpu0 happens to be offline.
 
 The second patch fixes the incorrect check for offline cpu status.
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABCAAGBQJaDyPgAAoJEAsCRMQNDUMcw88P/1LYlu4RXoVzReu14yy8U4XK
 bWQdc2uAGu0fdTf9olrk4OsCGP4Hbs3nDGf1VaOYWU2Gn87DhpiIWuJ0See0X4Gs
 6i7U8kLWRVtbJT25pvt5hNgW7udtKkhpXpfJOSQCKR3qB8rpvX6b+ueBmyCAHvuQ
 i5AnN9oiZopUQiCeXYDqO04CF/hr9aKRJQUBgeSjIiGeGvwOqCUWZrsVuUCR17Xj
 Bi5MG5qI/ufMYuy7FRPxMgne30OIA5y2axVTuhxLhR5mg+KXennMCltv8xQMeRUM
 e/dqKDsyXr1a4tq5u91j88L+yZrFYP3oS2oO97RpGhD7wjcHbrf17JW0cl4BVm3q
 u6Lpg22HdYMcyMZkVqTcP181PX9+Dbn/3vvpHWpNEqMg/LMUrrGa442nqtOZTB5Y
 flqpbhsDmaKMvIqqW7b0D8tbm1JKBRETqUaFeaGXcpAtzlWS9+4djdQiGpRu9JEf
 Q8YXazIrm9EYzKcNPor0m7ItxIxPWwD5xMU+jF3mqdM08zbU//he48hysryqtnbD
 cHpDpLwO6uaXtg+wEe+30mFGd2urvBTV0Y6pd0ok2FTnJRTY/OY9c6BhltUhpvBO
 zgf8AKhFBULrt/l/x0OQ0xJ7s9kfEDSnoDtr8sNM9Poc/2BajCSanWKRmzSmqNnZ
 rC9m7FKfJkQ8Lm/i0hkW
 =Xe5t
 -----END PGP SIGNATURE-----

Merge tag 'linux-cpupower-4.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux

Pull cpupower utility fixes for 4.15-rc2 from Shuah Khan:

"This update consists of fixes to tool's handling of offline cpus.

The first patch fixes the tool to find information on the cpu it
is running on, instead of always looking for cpu0 and failing if
cpu0 happens to be offline.

The second patch fixes the incorrect check for offline cpu status."

* tag 'linux-cpupower-4.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
  cpupower : Fix cpupower working when cpu0 is offline
  cpupowerutils: bench - Fix cpu online check
2017-11-18 15:05:31 +01:00
Abhishek Goel
dbdc468f35 cpupower : Fix cpupower working when cpu0 is offline
cpuidle_monitor used to assume that cpu0 is always online which is not
a valid assumption on POWER machines. This patch fixes this by getting
the cpu on which the current thread is running, instead of always using
cpu0 for monitoring which may not be online.

Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-11-15 08:37:42 -07:00
Rafael J. Wysocki
990a848d53 Merge branches 'pm-devfreq' and 'pm-tools'
* pm-devfreq:
  PM / devfreq: Define the constant governor name
  PM / devfreq: Remove unneeded conditional statement
  PM / devfreq: Show the all available frequencies
  PM / devfreq: Change return type of devfreq_set_freq_table()
  PM / devfreq: Use the available min/max frequency
  Revert "PM / devfreq: Add show_one macro to delete the duplicate code"
  PM / devfreq: Set min/max_freq when adding the devfreq device

* pm-tools:
  tools/power/cpupower: add libcpupower.so.0.0.1 to .gitignore
  tools/power/cpupower: Add 64 bit library detection
  MAINTAINERS: add maintainer for tools/power/cpupower
  cpupower: Fix no-rounding MHz frequency output
2017-11-13 01:41:39 +01:00
Prarit Bhargava
9da779c324 cpupower: Fix no-rounding MHz frequency output
'cpupower frequency-info -ln' returns kHz values on systems with MHz range
minimum CPU frequency range.  For example, on a 800MHz to 4.20GHz system
the command returns

hardware limits: 800000 MHz - 4.200000 GHz

The code that causes this error can be removed.  The next else if clause
will handle the output correctly such that

hardware limits: 800.000 MHz - 4.200000 GHz

is displayed correctly.

[v2]: Remove two lines instead of fixing broken code.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Renninger <trenn@suse.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Reviewed-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-11-03 09:28:02 -06:00
Greg Kroah-Hartman
b24413180f License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 11:10:55 +01:00
Prarit Bhargava
d0e4a193c3 tools/power/cpupower: allow running without cpu0
Linux-3.7 added CONFIG_BOOTPARAM_HOTPLUG_CPU0,
allowing systems to offline cpu0.

But when cpu0 is offline, cpupower monitor will not display all
processor and Mperf information:

[root@intel-skylake-dh-03 cpupower]# ./cpupower monitor
WARNING: at least one cpu is offline
    |Idle_Stats
CPU | POLL | C1-S | C1E- | C3-S | C6-S | C7s- | C8-S
   4|  0.00|  0.00|  0.00|  0.00|  0.90|  0.00| 96.13
   1|  0.00|  0.00|  5.49|  0.00|  0.01|  0.00| 92.26
   5|  0.00|  0.00|  0.00|  0.00|  0.46|  0.00| 99.50
   2| 45.42|  0.00|  0.00|  0.00| 22.94|  0.00| 28.84
   6|  0.00| 37.54|  0.00|  0.00|  0.00|  0.00|  0.00
   3|  0.00|  0.00|  0.00|  0.00|  0.30|  0.00| 91.99
   7|  0.00|  0.00|  0.00|  0.00|  4.70|  0.00|  0.70

This patch replaces the hard-coded use of cpu0 in cpupower with the
current cpu, allowing it to run without a cpu0.

After the patch is applied,

[root@intel-skylake-dh-03 cpupower]# ./cpupower monitor
WARNING: at least one cpu is offline
    |Nehalem                    || Mperf              || Idle_Stats
CPU | C3   | C6   | PC3  | PC6  || C0   | Cx   | Freq || POLL | C1-S | C1E- | C3-S | C6-S | C7s- | C8-S
   4|  0.01|  1.27|  0.00|  0.00||  0.04| 99.96|  3957||  0.00|  0.00|  0.00|  0.00|  1.43|  0.00| 98.52
   1|  0.00| 98.82|  0.00|  0.00||  0.05| 99.95|  3361||  0.00|  0.00|  0.01|  0.00|  0.03|  0.00| 99.88
   5|  0.00| 98.82|  0.00|  0.00||  0.09| 99.91|  3917||  0.00|  0.00|  0.00|  0.00| 99.38|  0.00|  0.50
   2|  0.33|  0.00|  0.00|  0.00||  0.00|100.00|  3890||  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|100.00
   6|  0.33|  0.00|  0.00|  0.00||  0.01| 99.99|  3903||  0.00|  0.00|  0.00|  0.00|  0.00|  0.00| 99.99
   3|  0.01|  0.71|  0.00|  0.00||  0.06| 99.94|  3678||  0.00|  0.00|  0.00|  0.00|  0.80|  0.00| 99.13
   7|  0.01|  0.71|  0.00|  0.00||  0.03| 99.97|  3538||  0.00|  0.69| 11.70|  0.00|  0.00|  0.00| 87.57

There are some minor cleanups included in this patch.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-31 14:17:30 +02:00
Sherry Hurwitz
902bef73fa cpupower: Add support for new AMD family 0x17
Add support for new AMD family 0x17
- Add bit field changes to the msr_pstate structure
- Add the new formula for the  calculation of cof
- Changed method to access to CpbDis

Signed-off-by: Sherry Hurwitz <sherry.hurwitz@amd.com>
Acked-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-27 01:43:22 +02:00
Sherry Hurwitz
6ae78b4e7c cpupower: Fix bug where return value was not used
Save return value from amd_pci_get_num_boost_states
and remove redundant setting of *support

Signed-off-by: Sherry Hurwitz <sherry.hurwitz@amd.com>
Reviewed-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-27 01:43:21 +02:00
Ben Hutchings
4cca045768 cpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores
The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and
CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both
flags set and an assumed base clock of 100 MHz for turbo values.

Reported-by: GSR <gsr.bugs@infernal-iceberg.com>
Tested-by: GSR <gsr.bugs@infernal-iceberg.com>
References: https://bugs.debian.org/859978
Fixes: 8fb2e440b2 (cpupower: Show Intel turbo ratio support via ...)
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-13 14:51:10 +02:00
Stafford Horne
4da39ceb26 cpupower: Restore format of frequency-info limit
The intel_pstate kselftest expects that the output of
`cpupower frequency-info -l | tail -1 | awk ' { print $1 } '`
to get frequency limits.  This does not work after the following two
changes.

 - 562e5f1a3: rework the "cpupower frequency-info" command
   (Jacob Tanenbaum) removed parsable limit output
 - ce512b840: Do not analyse offlined cpus
   (Thomas Renninger) added newline to break limit parsing more

This change preserves human readable output if wanted as well as
parsable output for scripts/tests.

Cc: Thomas Renninger <trenn@suse.com>
Cc: "Shreyas B. Prabhu" <shreyas@linux.vnet.ibm.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2017-01-19 10:30:28 -07:00
Laura Abbott
c25badc9ce cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set
When converting to a shared library in ac5a181d06 ("cpupower: Add
cpuidle parts into library"), cpu_freq_cpu_exists() was converted to
cpupower_is_cpu_online(). cpu_req_cpu_exists() returned 0 on success and
-ENOSYS on failure whereas cpupower_is_cpu_online returns 1 on success.
Check for the correct return value in cpufreq-set.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1374212
Fixes: ac5a181d06 (cpupower: Add cpuidle parts into library)
Reported-by: Julian Seward <jseward@acm.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Acked-by: Thomas Renninger <trenn@suse.com>
Cc: 4.7+ <stable@vger.kernel.org> # 4.7+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-01 06:16:52 +01:00
Thomas Renninger
ac5a181d06 cpupower: Add cpuidle parts into library
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>
2016-04-28 16:02:29 +02:00
Shreyas B. Prabhu
38cb76a307 cpupower: Fix build error in cpufreq-info
Fix the following build error by including limits.h -

utils/cpufreq-info.c: In function ‘get_latency’:
utils/cpufreq-info.c:437:29: error: ‘UINT_MAX’ undeclared (first use in
this function)
  if (!latency || latency == UINT_MAX) {
                             ^
Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Fixes: e98f033f94 (cpupower: fix how "cpupower frequency-info" interprets latency)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-19 01:17:23 +01:00
Jacob Tanenbaum
e98f033f94 cpupower: fix how "cpupower frequency-info" interprets latency
the intel-pstate driver does not support the ondemand governor and does not
have a valid value in
/sys/devices/system/cpu/cpu[x]/cpufreq/cpuinfo_transition_latency. The
intel-pstate driver sets cpuinfo_transition_latency to CPUFREQ_ETERNAL (-1),
the value written into cpuinfo_transition_latency is defind as an unsigned
int so checking the read value against max unsigned int will determine if the
value is valid.

Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:30:30 +01:00
Jacob Tanenbaum
562e5f1a35 cpupower: rework the "cpupower frequency-info" command
this patch makes two changes to the way that "cpupower
frequancy-info" operates

1. make it so that querying individual values always returns a
   message to the user

currently cpupower frequency info doesn't return anything to the user when
querying an individual value cannot be returned

[root@amd-dinar-09 cpupower]# cpupower -c 4 frequency-info -d
analyzing CPU 4:
[root@amd-dinar-09 cpupower]#

I added messages so that each query prints a message to the terminal

[root@amd-dinar-09 cpupower]# ./cpupower -c 4 frequency-info -d
analyzing CPU 4:
  no or unknown cpufreq driver is active on this CPU
[root@amd-dinar-09 cpupower]#

(this is just one example)

2. change debug_output_one() to use the functions already provided
   by cpufreq-info.c to query individual values of interest.

Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:30:30 +01:00
Thomas Renninger
ce512b8404 cpupower: Do not analyse offlined cpus
Use sysfs_is_cpu_online(cpu) instead of cpufreq_cpu_exists(cpu) to detect offlined cpus.

Re-arrange printfs slightly to have a consistent output even if you have multiple CPUs
as output and even if offlined cores are in between.

Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:30:30 +01:00
Thomas Renninger
7b0e1bf171 cpupower: Fix precedence issue
Signed-off-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:30:29 +01:00
Sriram Raghunathan
57ab3b0872 Creating a common structure initialization pattern for struct option
This patch tries to creates a common structure initialization
within the cpupower tool.

Previously the ``struct option`` was initialized
using `designated initializer` technique which was
not needed. There were conflicting initialization methods seen with

bench/main.c & others.

Signed-off-by: Sriram Raghunathan <sriram@marirs.net.in>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-02 02:28:59 +01:00
Thomas Renninger
19c9fb896f cpupower: Enable disabled Cstates if they are below max latency
cpupower idle-set -D <latency>
currently only disables all C-states that have a higher latency than the
specified <latency>. But if deep sleep states were already disabled and
have a lower latency, they should get enabled again.

For example:
This call:
cpupower idle-set -D 30
disables all C-states with a higher or equal latency than 30.
If one then calls:
cpupower idle-set -D 100
C-states with a latency between 30-99 will get enabled again with this patch
now. It is ensured that only C-states with a latency of 100 and higher are
disabled.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-02 02:28:59 +01:00
Thomas Renninger
645209472d cpupower: Remove debug message when using cpupower idle-set -D switch
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-02 02:28:59 +01:00
Jacob Tanenbaum
20102ac5be cpupower: cpupower monitor reports uninitialized values for offline cpus
[root@hp-dl980g7-02 linux]# cpupower monitor
...
5472|   0|   1|******|******|******|******|| 0.00|  0.00|  0.00|  0.00|  0.00 *is offline
10567|   0| 159|******|******|******|******||  0.00|  0.00|  0.00|  0.00|  0.00 *is offline
1661206560|859272560| 150|******|******|******|******|| 0.00|  0.00|  0.00|  0.00|  0.00 *is offline
1661206560|943093104| 140|******|******|******|******|| 0.00|  0.00|  0.00|  0.00|  0.00 *is offline

because of this cpupower also holds the incorrect value for the number
of physical packages in the machine

Changed cpupower to initialize the values of an offline cpu's socket and
core to -1, warn the user that one or more cpus is/are
offline and not print statistics for offline cpus.

This fix hides offlined cores where topology cannot be accessed.
With a recent kernel patch suggested from Prarit Bhargava it may be possible
that soft offlined cores' topology can still be parsed.
This patch would then show which cores in which package/socket are offline,
when sane toplogoy information is available.

Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-02 02:28:59 +01:00
Shreyas B. Prabhu
404c2db635 tools: cpupower: Fix error when running cpupower monitor
get_cpu_topology() tries to get topology info from all cpus by reading
files in the topology sysfs dir. If a cpu is offlined, since it doesn't
have topology dir, this function fails and returns -1. This causes
functions relying on get_cpu_topology() to fail. For example-

$ cpupower monitor
Cannot read number of available processors

Fix this by skipping fetching topology info for offline cpus.

Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Reported-by: Pavaman Subramaniyam <pavsubra@linux.vnet.ibm.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-29 01:38:16 +02:00
Shilpasri G Bhat
2e5e8fd1ff cpupower: Do not change the frequency of offline cpu
Check if the cpu is online before changing the frequency/governor of
the cpu.

Reported-by: Pavaman Subramaniyam <pavsubra@linux.vnet.ibm.com>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Thomas Renninger <trenn@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-23 20:40:51 +02:00
Herton R. Krzesinski
47b98c74fa cpupower: mperf monitor: fix output in MAX_FREQ_SYSFS mode
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 <herton@redhat.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-30 02:21:31 +02:00
Lucas Stach
06b230e3dd cpupower: fix breakage from libpci API change
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 <dev@lynxeye.de>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-15 21:54:26 +02:00
Prarit Bhargava
a59e5109f6 tools / cpupower: Fix no idle state information return value
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 <prarit@redhat.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-19 23:01:12 +01:00
Michal Privoznik
ad1d8313cd tools / cpupower: Correctly detect if running as root
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 <mprivozn@redhat.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-19 23:01:03 +01:00
Prarit Bhargava
2a813f1aaa Revert "tools: cpupower: fix return checks for sysfs_get_idlestate_count()"
This reverts commit 16b7c275c0.

My previous commit 16b7c275c0 ("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: 16b7c275c0 (tools: cpupower: fix return checks for ...)
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-14 22:14:16 +01:00
Prarit Bhargava
16b7c275c0 tools: cpupower: fix return checks for sysfs_get_idlestate_count()
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 <prarit@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-05 03:12:34 +01:00
Peter Senna Tschudin
059802f961 cpupower: Remove redundant error check
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:

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

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-30 01:57:13 +02:00
Himangi Saraogi
97fa1c5ca6 cpupower: mperf monitor: Correct use of ! and &
In commit ae91d60ba8, 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:

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

Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-30 01:57:12 +02:00
Andrey Utkin
788606cb88 PM / tools: cpupower: drop negativity check on unsigned value
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80621
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-19 21:41:17 +02:00
Thomas Renninger
7ea1bdb8e1 cpupower: Remove mc and smt power aware scheduler info/settings
These kernel interfaces got removed by:

commit 8e7fbcbc22
Author: Peter Zijlstra <peterz@infradead.org>
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 <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 00:36:37 +02:00
Thomas Renninger
3fc5a0e51a cpupower: cpupower info -b should return 0 on success, not the perf bias value
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 00:36:37 +02:00
Thomas Renninger
8a19cb5867 cpupower: If root, try to load msr driver on x86 if /dev/cpu/0/msr is not available
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 00:36:36 +02:00
Thomas Renninger
69cd502dd8 cpupower: Introduce idle state disable-by-latency and enable-all
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 00:36:36 +02:00
Prarit Bhargava
e091abc7f9 PM / tools: cpupower: add option to display values without round offs
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 <trenn@suse.de>
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-07 00:19:06 +02:00
Rafael J. Wysocki
df34ca72ed Merge branches 'acpi-tools' and 'pm-tools'
* 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
2014-01-17 01:59:48 +01:00
One Thousand Gnomes
fdfe840e48 cpupower: Fix sscanf robustness in cpufreq-set
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 <alan@linux.intel.com>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-08 15:10:39 +01:00
Josh Boyer
f447ef4a56 cpupower: Fix segfault due to incorrect getopt_long arugments
If a user calls 'cpupower set --perf-bias 15', the process will end with
a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi
call.  This is because the getopt_long structure currently has all of
the options as having an optional_argument when they really have a
required argument.  We change the structure to use required_argument to
match the short options and it resolves the issue.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1000439

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Thomas Renninger <trenn@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-17 11:29:30 -08:00
Thomas Renninger
f4a5d17efe tools: cpupower: fix wrong err msg not supported vs not available
idlestates in sysfs are counted from 0.

This fixes a wrong error message.
Current behavior on a machine with 4 sleep states is:

cpupower idle-set -e 4
Idlestate 4 enabled on CPU 0

-----Wrong---------------------
cpupower idle-set -e 5
Idlestate enabling not supported by kernel
-----Must and now will be -----
cpupower idle-set -e 5
Idlestate 6 not available on CPU 0
-------------------------------

cpupower idle-set -e 6
Idlestate 6 not available on CPU 0

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-11-25 23:10:50 +01:00
Thomas Renninger
7ee767b69b cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states
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-05 01:52:19 +02:00
Thomas Renninger
2aa1ca75c4 cpupower: Haswell also supports the C-states introduced with SandyBridge
Add Haswell model numbers to snb_register() as it also supports the
C-states introduced in SandyBridge processors.

[rjw: Changelog]
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-05 01:52:19 +02:00
Thomas Renninger
c4f3610eba cpupower: Introduce idle-set subcommand and C-state enabling/disabling
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>
2013-07-05 01:52:19 +02:00
Thomas Renninger
0924c369bc cpupower: Implement disabling of cstate interface
Latest kernel allows to disable C-states via:
/sys/devices/system/cpu/cpuX/cpuidle/stateY/disable

This patch provides lower level sysfs access functions to make use of
this interface.  A later patch will implement the higher level stuff.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-05 01:52:19 +02:00