|
| 1 | +.. SPDX-License-Identifier: GPL-2.0 |
| 2 | +
|
| 3 | +======================================================= |
| 4 | +Legacy Documentation of CPU Performance Scaling Drivers |
| 5 | +======================================================= |
| 6 | + |
| 7 | +Included below are historic documents describing assorted |
| 8 | +:doc:`CPU performance scaling <cpufreq>` drivers. They are reproduced verbatim, |
| 9 | +with the original white space formatting and indentation preserved, except for |
| 10 | +the added leading space character in every line of text. |
| 11 | + |
| 12 | + |
| 13 | +AMD PowerNow! Drivers |
| 14 | +===================== |
| 15 | + |
| 16 | +:: |
| 17 | + |
| 18 | + PowerNow! and Cool'n'Quiet are AMD names for frequency |
| 19 | + management capabilities in AMD processors. As the hardware |
| 20 | + implementation changes in new generations of the processors, |
| 21 | + there is a different cpu-freq driver for each generation. |
| 22 | + |
| 23 | + Note that the driver's will not load on the "wrong" hardware, |
| 24 | + so it is safe to try each driver in turn when in doubt as to |
| 25 | + which is the correct driver. |
| 26 | + |
| 27 | + Note that the functionality to change frequency (and voltage) |
| 28 | + is not available in all processors. The drivers will refuse |
| 29 | + to load on processors without this capability. The capability |
| 30 | + is detected with the cpuid instruction. |
| 31 | + |
| 32 | + The drivers use BIOS supplied tables to obtain frequency and |
| 33 | + voltage information appropriate for a particular platform. |
| 34 | + Frequency transitions will be unavailable if the BIOS does |
| 35 | + not supply these tables. |
| 36 | + |
| 37 | + 6th Generation: powernow-k6 |
| 38 | + |
| 39 | + 7th Generation: powernow-k7: Athlon, Duron, Geode. |
| 40 | + |
| 41 | + 8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron. |
| 42 | + Documentation on this functionality in 8th generation processors |
| 43 | + is available in the "BIOS and Kernel Developer's Guide", publication |
| 44 | + 26094, in chapter 9, available for download from www.amd.com. |
| 45 | + |
| 46 | + BIOS supplied data, for powernow-k7 and for powernow-k8, may be |
| 47 | + from either the PSB table or from ACPI objects. The ACPI support |
| 48 | + is only available if the kernel config sets CONFIG_ACPI_PROCESSOR. |
| 49 | + The powernow-k8 driver will attempt to use ACPI if so configured, |
| 50 | + and fall back to PST if that fails. |
| 51 | + The powernow-k7 driver will try to use the PSB support first, and |
| 52 | + fall back to ACPI if the PSB support fails. A module parameter, |
| 53 | + acpi_force, is provided to force ACPI support to be used instead |
| 54 | + of PSB support. |
| 55 | + |
| 56 | + |
| 57 | +``cpufreq-nforce2`` |
| 58 | +=================== |
| 59 | + |
| 60 | +:: |
| 61 | + |
| 62 | + The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms. |
| 63 | + |
| 64 | + This works better than on other platforms, because the FSB of the CPU |
| 65 | + can be controlled independently from the PCI/AGP clock. |
| 66 | + |
| 67 | + The module has two options: |
| 68 | + |
| 69 | + fid: multiplier * 10 (for example 8.5 = 85) |
| 70 | + min_fsb: minimum FSB |
| 71 | + |
| 72 | + If not set, fid is calculated from the current CPU speed and the FSB. |
| 73 | + min_fsb defaults to FSB at boot time - 50 MHz. |
| 74 | + |
| 75 | + IMPORTANT: The available range is limited downwards! |
| 76 | + Also the minimum available FSB can differ, for systems |
| 77 | + booting with 200 MHz, 150 should always work. |
| 78 | + |
| 79 | + |
| 80 | +``pcc-cpufreq`` |
| 81 | +=============== |
| 82 | + |
| 83 | +:: |
| 84 | + |
| 85 | + /* |
| 86 | + * pcc-cpufreq.txt - PCC interface documentation |
| 87 | + * |
| 88 | + * Copyright (C) 2009 Red Hat, Matthew Garrett <[email protected]> |
| 89 | + * Copyright (C) 2009 Hewlett-Packard Development Company, L.P. |
| 90 | + * Nagananda Chumbalkar <[email protected]> |
| 91 | + */ |
| 92 | + |
| 93 | + |
| 94 | + Processor Clocking Control Driver |
| 95 | + --------------------------------- |
| 96 | + |
| 97 | + Contents: |
| 98 | + --------- |
| 99 | + 1. Introduction |
| 100 | + 1.1 PCC interface |
| 101 | + 1.1.1 Get Average Frequency |
| 102 | + 1.1.2 Set Desired Frequency |
| 103 | + 1.2 Platforms affected |
| 104 | + 2. Driver and /sys details |
| 105 | + 2.1 scaling_available_frequencies |
| 106 | + 2.2 cpuinfo_transition_latency |
| 107 | + 2.3 cpuinfo_cur_freq |
| 108 | + 2.4 related_cpus |
| 109 | + 3. Caveats |
| 110 | + |
| 111 | + 1. Introduction: |
| 112 | + ---------------- |
| 113 | + Processor Clocking Control (PCC) is an interface between the platform |
| 114 | + firmware and OSPM. It is a mechanism for coordinating processor |
| 115 | + performance (ie: frequency) between the platform firmware and the OS. |
| 116 | + |
| 117 | + The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC |
| 118 | + interface. |
| 119 | + |
| 120 | + OS utilizes the PCC interface to inform platform firmware what frequency the |
| 121 | + OS wants for a logical processor. The platform firmware attempts to achieve |
| 122 | + the requested frequency. If the request for the target frequency could not be |
| 123 | + satisfied by platform firmware, then it usually means that power budget |
| 124 | + conditions are in place, and "power capping" is taking place. |
| 125 | + |
| 126 | + 1.1 PCC interface: |
| 127 | + ------------------ |
| 128 | + The complete PCC specification is available here: |
| 129 | + https://acpica.org/sites/acpica/files/Processor-Clocking-Control-v1p0.pdf |
| 130 | + |
| 131 | + PCC relies on a shared memory region that provides a channel for communication |
| 132 | + between the OS and platform firmware. PCC also implements a "doorbell" that |
| 133 | + is used by the OS to inform the platform firmware that a command has been |
| 134 | + sent. |
| 135 | + |
| 136 | + The ACPI PCCH() method is used to discover the location of the PCC shared |
| 137 | + memory region. The shared memory region header contains the "command" and |
| 138 | + "status" interface. PCCH() also contains details on how to access the platform |
| 139 | + doorbell. |
| 140 | + |
| 141 | + The following commands are supported by the PCC interface: |
| 142 | + * Get Average Frequency |
| 143 | + * Set Desired Frequency |
| 144 | + |
| 145 | + The ACPI PCCP() method is implemented for each logical processor and is |
| 146 | + used to discover the offsets for the input and output buffers in the shared |
| 147 | + memory region. |
| 148 | + |
| 149 | + When PCC mode is enabled, the platform will not expose processor performance |
| 150 | + or throttle states (_PSS, _TSS and related ACPI objects) to OSPM. Therefore, |
| 151 | + the native P-state driver (such as acpi-cpufreq for Intel, powernow-k8 for |
| 152 | + AMD) will not load. |
| 153 | + |
| 154 | + However, OSPM remains in control of policy. The governor (eg: "ondemand") |
| 155 | + computes the required performance for each processor based on server workload. |
| 156 | + The PCC driver fills in the command interface, and the input buffer and |
| 157 | + communicates the request to the platform firmware. The platform firmware is |
| 158 | + responsible for delivering the requested performance. |
| 159 | + |
| 160 | + Each PCC command is "global" in scope and can affect all the logical CPUs in |
| 161 | + the system. Therefore, PCC is capable of performing "group" updates. With PCC |
| 162 | + the OS is capable of getting/setting the frequency of all the logical CPUs in |
| 163 | + the system with a single call to the BIOS. |
| 164 | + |
| 165 | + 1.1.1 Get Average Frequency: |
| 166 | + ---------------------------- |
| 167 | + This command is used by the OSPM to query the running frequency of the |
| 168 | + processor since the last time this command was completed. The output buffer |
| 169 | + indicates the average unhalted frequency of the logical processor expressed as |
| 170 | + a percentage of the nominal (ie: maximum) CPU frequency. The output buffer |
| 171 | + also signifies if the CPU frequency is limited by a power budget condition. |
| 172 | + |
| 173 | + 1.1.2 Set Desired Frequency: |
| 174 | + ---------------------------- |
| 175 | + This command is used by the OSPM to communicate to the platform firmware the |
| 176 | + desired frequency for a logical processor. The output buffer is currently |
| 177 | + ignored by OSPM. The next invocation of "Get Average Frequency" will inform |
| 178 | + OSPM if the desired frequency was achieved or not. |
| 179 | + |
| 180 | + 1.2 Platforms affected: |
| 181 | + ----------------------- |
| 182 | + The PCC driver will load on any system where the platform firmware: |
| 183 | + * supports the PCC interface, and the associated PCCH() and PCCP() methods |
| 184 | + * assumes responsibility for managing the hardware clocking controls in order |
| 185 | + to deliver the requested processor performance |
| 186 | + |
| 187 | + Currently, certain HP ProLiant platforms implement the PCC interface. On those |
| 188 | + platforms PCC is the "default" choice. |
| 189 | + |
| 190 | + However, it is possible to disable this interface via a BIOS setting. In |
| 191 | + such an instance, as is also the case on platforms where the PCC interface |
| 192 | + is not implemented, the PCC driver will fail to load silently. |
| 193 | + |
| 194 | + 2. Driver and /sys details: |
| 195 | + --------------------------- |
| 196 | + When the driver loads, it merely prints the lowest and the highest CPU |
| 197 | + frequencies supported by the platform firmware. |
| 198 | + |
| 199 | + The PCC driver loads with a message such as: |
| 200 | + pcc-cpufreq: (v1.00.00) driver loaded with frequency limits: 1600 MHz, 2933 |
| 201 | + MHz |
| 202 | + |
| 203 | + This means that the OPSM can request the CPU to run at any frequency in |
| 204 | + between the limits (1600 MHz, and 2933 MHz) specified in the message. |
| 205 | + |
| 206 | + Internally, there is no need for the driver to convert the "target" frequency |
| 207 | + to a corresponding P-state. |
| 208 | + |
| 209 | + The VERSION number for the driver will be of the format v.xy.ab. |
| 210 | + eg: 1.00.02 |
| 211 | + ----- -- |
| 212 | + | | |
| 213 | + | -- this will increase with bug fixes/enhancements to the driver |
| 214 | + |-- this is the version of the PCC specification the driver adheres to |
| 215 | + |
| 216 | + |
| 217 | + The following is a brief discussion on some of the fields exported via the |
| 218 | + /sys filesystem and how their values are affected by the PCC driver: |
| 219 | + |
| 220 | + 2.1 scaling_available_frequencies: |
| 221 | + ---------------------------------- |
| 222 | + scaling_available_frequencies is not created in /sys. No intermediate |
| 223 | + frequencies need to be listed because the BIOS will try to achieve any |
| 224 | + frequency, within limits, requested by the governor. A frequency does not have |
| 225 | + to be strictly associated with a P-state. |
| 226 | + |
| 227 | + 2.2 cpuinfo_transition_latency: |
| 228 | + ------------------------------- |
| 229 | + The cpuinfo_transition_latency field is 0. The PCC specification does |
| 230 | + not include a field to expose this value currently. |
| 231 | + |
| 232 | + 2.3 cpuinfo_cur_freq: |
| 233 | + --------------------- |
| 234 | + A) Often cpuinfo_cur_freq will show a value different than what is declared |
| 235 | + in the scaling_available_frequencies or scaling_cur_freq, or scaling_max_freq. |
| 236 | + This is due to "turbo boost" available on recent Intel processors. If certain |
| 237 | + conditions are met the BIOS can achieve a slightly higher speed than requested |
| 238 | + by OSPM. An example: |
| 239 | + |
| 240 | + scaling_cur_freq : 2933000 |
| 241 | + cpuinfo_cur_freq : 3196000 |
| 242 | + |
| 243 | + B) There is a round-off error associated with the cpuinfo_cur_freq value. |
| 244 | + Since the driver obtains the current frequency as a "percentage" (%) of the |
| 245 | + nominal frequency from the BIOS, sometimes, the values displayed by |
| 246 | + scaling_cur_freq and cpuinfo_cur_freq may not match. An example: |
| 247 | + |
| 248 | + scaling_cur_freq : 1600000 |
| 249 | + cpuinfo_cur_freq : 1583000 |
| 250 | + |
| 251 | + In this example, the nominal frequency is 2933 MHz. The driver obtains the |
| 252 | + current frequency, cpuinfo_cur_freq, as 54% of the nominal frequency: |
| 253 | + |
| 254 | + 54% of 2933 MHz = 1583 MHz |
| 255 | + |
| 256 | + Nominal frequency is the maximum frequency of the processor, and it usually |
| 257 | + corresponds to the frequency of the P0 P-state. |
| 258 | + |
| 259 | + 2.4 related_cpus: |
| 260 | + ----------------- |
| 261 | + The related_cpus field is identical to affected_cpus. |
| 262 | + |
| 263 | + affected_cpus : 4 |
| 264 | + related_cpus : 4 |
| 265 | + |
| 266 | + Currently, the PCC driver does not evaluate _PSD. The platforms that support |
| 267 | + PCC do not implement SW_ALL. So OSPM doesn't need to perform any coordination |
| 268 | + to ensure that the same frequency is requested of all dependent CPUs. |
| 269 | + |
| 270 | + 3. Caveats: |
| 271 | + ----------- |
| 272 | + The "cpufreq_stats" module in its present form cannot be loaded and |
| 273 | + expected to work with the PCC driver. Since the "cpufreq_stats" module |
| 274 | + provides information wrt each P-state, it is not applicable to the PCC driver. |
0 commit comments