Remarks:
1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.
2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.
3. There is no rationale to export controls to user land.
4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.
5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.
(required for interaction with T-states), and (3) use aprint_debug(9)
instead of the ACPI_DEBUG_PRINT(x) macro for the dynamic frequency changes
(for the time being, people need easier way to observe the dynamic changes).
/*
* XXX: The pci_find_device(9) function only deals with
* attached devices. Change this to use something like
* pci_device_foreach(), and implement it for IA-64.
*/
functional, the previously loaded EST code may have used frequencies that
are not present in the BIOS. This will cause failures since acpicpu(4) will
treat these unknown frequencies as errors. "Fix" this by initializing the
cached P-state to P0, regardless of what the true state might be.
Remarks:
1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.
2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.
3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.
This can help when dealing with problem reports, as the user does not need
to reboot nor compile a kernel. Instead: 'modload -b dump=true acpiverbose'.
when the idle-information is being updated (e.g. due acpiacad(4) events),
we can not enter the idle-loop. The lock must run at the same priority
(IPL_NONE) as ACPICA's mutexes obtained via AcpiOsCreateMutex() a.k.a.
AcpiOsCreateSemaphore(). Also check want_resched as the first thing and
clarify the suspend/resume path.
There is still one race condition identified: when the driver is loaded as a
module, we must gracefully kick all CPUs out from the ACPI idle-loop upon
detachment.
It was analyzed that this DSDT busy-loops some unknown PCI memory regions in
several places. Because the regions are apparently almost constant, this
causes several conditions where the interpreter might enter into an infinite
loop. Luckily ACPICA detects this and rightly spams AE_AML_INFINITE_LOOP
warnings.
Not much we can do. Declare as broken beyond repair. Set acpi_force_load=1
to use ACPI or use a custom DSDT.
sanity check before casting to the GAS. Rename the _CSD structure; the
optional "cross logical processor dependency information" is almost
identical in C, P, and T states. Add some comments to the header.
