still not ideal, as ACPI gives us information about "cross logical processor
dependencies". For instance, a single MSR call on one CPU may cause all other
CPUs in the same domain to follow the state shift. Thus, rather than using
xc_broadcast(9), we should xc_unicast(9) on per-domain or per-CPU-set basis.
reviews.
In kernel, it matches the 'i386_use_pae' variable (0: kernel does not use
PAE, 1: kernel uses PAE). Will be used by i386 kvm(3) to know the functions
that should get called for VA => PA translations.
on my i7, cpus 0/4, 1/5, 2/6 and 3/7 have identical information and the
processor manual says that there are only 4 actual sensors.
this still doesn't attach (yet) on that system, due to a core solo/duo
errata being wrongly applied, but i haven't figured out the right way
to do that.
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.
eliminating the temp completely (__func__ is already an array).
This has been sitting in my tree for years, and I forgot to commit it.
Compile-tested by compiling hpcsh GENERIC with options DEBUG.
the acpicpu(4) driver should attach even if the existing frequency management
code fails to attach, mainly because ACPI is the only proper way to deal
with EST on new Intel system.
Use a more drastic hack to deal with this: when acpicpu(4) attachs, it tears
down any existing sysctl(8) controls and installs identical ones in place.
Upon detachment, the initialization function of the existing EST is called.
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.
write-through map (i.e. map it without BUS_DMA_COHERENT) since
currently all DMA data transfers are memory to device only.
Disabled by default, but enabled by "options PXA2X0_LCD_WRITETHROUGH"
or setting pxa2x0_lcd_writethrough = 1 in a kernel binary.
Tested on WS003SH by me and on WS011SH by jun@, and console output speed
is improved ~three times faster than coherent (uncached) mapping.
XXX: should we have a flag like BUS_DMA_WRITETHROUGH in MI bus_dma(9)?
model value.
Required to avoid faulting on rdmsr(MSR_FSB_FREQ) early during boot.
Will ask for a pull-up. This affects GENERIC, and most likely, install iso
too.
XXX quick hack. Obtaining FSB through ACPI should be cleaner.
