#
2a6da27d |
| 30-Apr-2024 |
Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> |
tools/power/cpupower: Fix Pstate frequency reporting on AMD Family 1Ah CPUs
[ Upstream commit 43cad521c6d228ea0c51e248f8e5b3a6295a2849 ]
Update cpupower's P-State frequency calculation and reportin
tools/power/cpupower: Fix Pstate frequency reporting on AMD Family 1Ah CPUs
[ Upstream commit 43cad521c6d228ea0c51e248f8e5b3a6295a2849 ]
Update cpupower's P-State frequency calculation and reporting with AMD Family 1Ah+ processors, when using the acpi-cpufreq driver. This is due to a change in the PStateDef MSR layout in AMD Family 1Ah+.
Tested on 4th and 5th Gen AMD EPYC system
Signed-off-by: Ananth Narayan <Ananth.Narayan@amd.com> Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d8363e29 |
| 22-Feb-2022 |
Huang Rui <ray.huang@amd.com> |
cpupower: Add function to print AMD P-State performance capabilities
AMD P-State kernel module is using the fine grain frequency instead of acpi hardware pstate. So add a function to print performan
cpupower: Add function to print AMD P-State performance capabilities
AMD P-State kernel module is using the fine grain frequency instead of acpi hardware pstate. So add a function to print 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>
show more ...
|
#
bf9801ba |
| 22-Feb-2022 |
Huang Rui <ray.huang@amd.com> |
cpupower: Enable boost state support for AMD P-State module
The legacy ACPI hardware P-States function has 3 P-States on ACPI table, the CPU frequency only can be switched between the 3 P-States. Wh
cpupower: Enable boost state support for AMD P-State module
The legacy ACPI hardware P-States function has 3 P-States on ACPI table, the CPU frequency only can be switched between the 3 P-States. While the processor supports the boost state, it will have another boost state that the frequency can be higher than P0 state, and the state can be decoded by the function of decode_pstates() and read by amd_pci_get_num_boost_states().
However, the new AMD P-State function is different than legacy ACPI hardware P-State on AMD processors. That has a finer grain frequency range between the highest and lowest frequency. And boost frequency is actually the frequency which is mapped on highest performance ratio. The similar previous P0 frequency is mapped on nominal performance ratio. If the highest performance on the processor is higher than nominal performance, then we think the current processor supports the boost state. And it uses amd_pstate_boost_init() to initialize boost for AMD P-State function.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
33e43f36 |
| 22-Feb-2022 |
Huang Rui <ray.huang@amd.com> |
cpupower: Add AMD P-State sysfs definition and access helper
Introduce the marco definitions and access helper function for AMD P-State sysfs interfaces such as each performance goals and frequency
cpupower: Add AMD P-State sysfs definition and access helper
Introduce the marco definitions and access helper function for AMD P-State sysfs interfaces such as each performance goals and frequency levels in amd helper file. They will be used to read the sysfs attribute from AMD P-State cpufreq driver for cpupower utilities.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
d1abc4e9 |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Remove family arg to decode_pstates()
The decode_pstates() routine no longer uses the CPU family and the caleed routines (get_cof() and get_did()) can grab the family from the global cpupo
cpupower: Remove family arg to decode_pstates()
The decode_pstates() routine no longer uses the CPU family and the caleed routines (get_cof() and get_did()) can grab the family from the global cpupower_cpu_info struct. These update removes passing the family arg to all these routines.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
56a85eeb |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Condense pstate enabled bit checks in decode_pstates()
The enabled bit (bit 63) is common for all families so we can remove the multiple enabled checks based on family and have a common ch
cpupower: Condense pstate enabled bit checks in decode_pstates()
The enabled bit (bit 63) is common for all families so we can remove the multiple enabled checks based on family and have a common check for HW pstate enabled.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
23765b82 |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Update family checks when decoding HW pstates
The family checks in get_cof() and get_did() need to use the correct MSR format depending on the family. Add a cpupower capability for using t
cpupower: Update family checks when decoding HW pstates
The family checks in get_cof() and get_did() need to use the correct MSR format depending on the family. Add a cpupower capability for using the pstatedef (family 17h and newer) to control this instead of direct family checks.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
1421de79 |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Remove unused pscur variable.
The pscur variable is set but not uused, just remove it.
This may have previsously been set to validate the MSR_AMD_PSTATE_STATUS MSR. With the addition of t
cpupower: Remove unused pscur variable.
The pscur variable is set but not uused, just remove it.
This may have previsously been set to validate the MSR_AMD_PSTATE_STATUS MSR. With the addition of the CPUPOWER_CAP_AMD_HW_PSTATE cap flag this is no longer needed since the cpuid bit to enable this cap flag also validates that the MSR_AMD_PSTATE_STATUS MSR is present.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
a0255a76 |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Add CPUPOWER_CAP_AMD_HW_PSTATE cpuid caps flag
Add a check in get_cpu_info() for the ability to read frequencies from hardware and set the CPUPOWER_CAP_AMD_HW_PSTATE cpuid flag. The cpuid
cpupower: Add CPUPOWER_CAP_AMD_HW_PSTATE cpuid caps flag
Add a check in get_cpu_info() for the ability to read frequencies from hardware and set the CPUPOWER_CAP_AMD_HW_PSTATE cpuid flag. The cpuid flag is set when CPUID_80000007_EDX[7] is set, which is all families >= 10h. The check excludes family 14h because HW pstate reporting was not implemented on family 14h.
This is intended to reduce family checks in the main code paths.
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Reviewed-by: skhan@linuxfoundation.org Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
629d512d |
| 25-Jan-2021 |
Nathan Fontenot <nathan.fontenot@amd.com> |
cpupower: Update msr_pstate union struct naming
The msr_pstate union struct named fam17h_bits is misleading since this is the struct to use for all families >= 0x17, not just for family 0x17. Rename
cpupower: Update msr_pstate union struct naming
The msr_pstate union struct named fam17h_bits is misleading since this is the struct to use for all families >= 0x17, not just for family 0x17. Rename the bits structs to be 'pstate' (for pre family 17h CPUs) and 'pstatedef' (for CPUs since fam 17h) to align closer with PPR/BDKG (1) naming.
There are no functional changes as part of this update.
1: AMD Processor Programming Reference (PPR) and BIOS and Kernel Developer's Guide (BKDG) available at: http://developer.amd.com/resources/developer-guides-manuals
Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Reviewed-by: skhan@linuxfoundation.org Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
f69ffc5d |
| 08-Oct-2018 |
Prarit Bhargava <prarit@redhat.com> |
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 oc
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>
show more ...
|
#
8c22e2f6 |
| 08-Oct-2018 |
Prarit Bhargava <prarit@redhat.com> |
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/s
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>
show more ...
|
#
995d5f64 |
| 03-Oct-2018 |
Pu Wen <puwen@hygon.cn> |
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 check
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
show more ...
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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
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>
show more ...
|
#
902bef73 |
| 20-Jun-2017 |
Sherry Hurwitz <sherry.hurwitz@amd.com> |
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 meth
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>
show more ...
|
#
568a8990 |
| 11-Oct-2011 |
Thomas Renninger <trenn@suse.de> |
cpupower: Better interface for accessing AMD pci registers
AMD's BKDG (Bios and Kernel Developers Guide) talks in the CPU spec of their CPU families about PCI registers defined by "device" (slot) an
cpupower: Better interface for accessing AMD pci registers
AMD's BKDG (Bios and Kernel Developers Guide) talks in the CPU spec of their CPU families about PCI registers defined by "device" (slot) and func(tion).
Assuming that CPU specific configuration PCI devices are always on domain and bus zero a pci_slot_func_init() func which gets the slot and func of the desired PCI device passed looks like the most convenient way.
This also obsoletes the PCI device id maintenance.
Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Andreas Herrmann <herrmann.der.user@googlemail.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
show more ...
|
#
2cd005ca |
| 19-Apr-2011 |
Dominik Brodowski <linux@dominikbrodowski.net> |
cpupowerutils: helpers - ConfigStyle bugfixes
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
#
7fe2f639 |
| 30-Mar-2011 |
Dominik Brodowski <linux@dominikbrodowski.net> |
cpupowerutils - cpufrequtils extended with quite some features
CPU power consumption vs performance tuning is no longer limited to CPU frequency switching anymore: deep sleep states, traditional dyn
cpupowerutils - cpufrequtils extended with quite some features
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>
show more ...
|