| Age | Commit message (Collapse) | Author |
|
|
|
automate installation of sysctl nodes.
Note that there are still a number of device and pseudo-device modules
that create entries tied to individual device units, rather than to the
module itself. These are not changed.
|
|
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
|
|
the sysctl link sets are processed, and remove redundancy.
Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate
lines of code.
|
|
(rev. 1.48). Also add a quirk for ASUSTeK's M2A-MX in order to allow
powernow(4) to attach (reported by bouyer@).
|
|
system-vendor, system-product, system-version, system-serial, system-uuid
bios-vendor, bios-version
board-vendor, board-product, board-version, board-serial
the *-serial and *-uuid keys are marked with CTLFLAG_PRIVATE
a few of the pmf platform key names changed so update callers to match
|
|
not be used before interrupts have been enabled. Suggested by macallan@.
|
|
|
|
|
|
|
|
|
|
|
|
driver to the main acpi(4) stack. Follow Linux and evaluate it early.
Should fix PR port-amd64/42895, possibly also PR kern/42583, and many
other comparable bugs.
A common sense explanation is that Intel supplies additional CPU tables to
OEMs. BIOS writers do not bother to modify their DSDTs, but instead load
these extra tables dynamically as secondary SSDT tables. The actual Load()
happens when the _PDC method is invoked, and thus namespace errors occur
when the CPU-specific ACPI methods are not yet present but referenced in the
AML by various drivers, including, but not limited to, acpitz(4).
|
|
|
|
Thanks to rmind@ for clarifications.
|
|
|
|
disable interrupts locally and protect the access to APERF and MPERF. Also
rationalize the MD initialization sequence.
|
|
are matched, the whole driver will be prevented from attaching. The first
entry is Supermicro PDSMi-LN4+ (a BIOS bug with bogus P-state entries).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.
|
|
|
|
|
|
|
|
|
|
firmware requests to do so. This cures severe overhating (> 120 C) observed
on many laptops, being also on par with the specification(s). This can be
reverted by using the new "hw.acpi.cpu.dynamic" sysctl variable.
|
|
|
|
Note that the solution is not optimal. If ichlpcib(4) provides SpeedStep
support, possible I/O resource conflicts may occur with acpicpu(4). Ideally,
as noted for instance in Windows design documents, ichlpcib(4) should never
expose SpeedStep when ACPI is being used. The probability for potential race
conditions is however very small, being limited to few P4-era machines and
being dependent on user actions.
|
|
|
|
config_interrupts(9) to be executed. This is necessary because: (a) the
initialization routines must be run only once after interrupts are enabled
and (b) all ACPI CPUs have attached.
|
|
Comparable to T-states, this gives effectively a window of available
performance states for passive cooling. An example:
Init: max = 0, min = Pn.
Time j. Time j + 1.
----------- -----------
2000 MHz P0 max P0
P1 P1 max
P2 ==> P2
P3 P3 min
P4 P4
P5 min P5
500 Mhz Pn Pn
----------- -----------
Search: repeat (i = P0; i <= P5) repeat (i = P1; i <= P3)
|
|
1. Initialize P-states properly to P0. It is processor-specific
what value we might get without initialization. (Some AMD CPUs
have even specific registers for the state after cold reset.)
2. Following design notes for Windows, set the lowest-power P-state
upon suspend and restore the saved state after resume.
|
|
use config_defer(9) instead of config_finalize_register(9), and simplify the
code paths around the initialization.
|
|
|
|
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.
|
|
we start the detachment routine.
|
|
|
|
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.
|
|
match the ACPI processor object ID with the ID available in the APIC table.
|
|
not need such granularity that different states would require a different lock.
|
|
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.
|
|
|
|
|
|
|
|
existing ACPICPU_FLAG_C, as was intended. Set that flag only after the
idle-loop has been installed, so that the notify handler errors out if an
interrupt is received before the idle-loop is in place.
|
|
Fixes panic reported by Patrick Welche on current-users@
Fixes panic on my own HP Pavilion laptop
|