acpicpu: Add support for ACPI P-states and T-states on Arm.

Remove the upper limit for the number of T-states.

branches: 1.43.2; 1.43.6; 1.43.8;
Convert to use cpufreq(9).

Get rid of RUN_ONCE(9). Should fix PR # kern/44043.

Move the evaluation of the _PDC control method out from the acpicpu(4)
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).

branches: 1.40.2;
Remove the "simple CPU lock" that was unnecessary.
Thanks to rmind@ for clarifications.

Like in rest of the acpi(4) stack, queue all resume hooks.

Properly set the frequency during suspend and resume. Should fix problems
introduced in the revision 1.42. Pointed out by Taylor C. Campbell.

branches: 1.37.2;
Add __cpu_simple_lock_t. Use it, x86_read_psl(), and x86_disable_intr() to
disable interrupts locally and protect the access to APERF and MPERF. Also
rationalize the MD initialization sequence.

Rename a badly named constant. Make it correspond with <x86/specialreg.h>.

Move the xcall(9) that does the P- and T-state transformations from the MD
layer to the main code. Makes the caches coherent and provides consistent
vmstat(1) output. This is still not quite right, given that most of the
cross-calls are typically unnecessary with the dependency coordination.

Provide MD wrappers for match and attach.

Comment the coordination types.

Start to derive the percpu(9) (or per-domain) state coordination
mechanisms by parsing the _CSD, _PSD, and _TSD objects by default.

Rename couple of badly named functions for consistency. No functional change.

Add preliminary support for the IA32_APERF and IA32_MPERF frequency counters.
These are not yet used for anything and only Intel is supported at the moment.

Store a pointer to cpu_info rather than cpu_info::ci_acpiid alone.

branches: 1.28.2; 1.28.4;
Move the function that counts the CPUs from acpicpu(4) to the MD layer.

Change the default behavior to enforce the maximum frequency when the
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.

Add AMD C1E quirk. Tested by cegger@.

(a) This should be removed once C-states are supported.

(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.

Fix PR kern/43765 from Scott Ellis.

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.

Add native support for AMD family 0Fh processors. This is the furthest we
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.

Other entry points beyond x86_cpu_idle_halt() may use HLT as the
idle-mechanism. Send an IPI also for these in cpu_need_resched().

Check from CPUID 0x06 %eax (on Intel) whether we might actually have an
invariant APIC timer or an "ARAT" ("always running APIC timer"). This means
that the APIC timer may keep ticking at the same rate also in deep C-states
with some new or forthcoming Intel CPUs.

Detect whether TSC is invariant, which may be the case on both new AMD and
Intel processors. The invariance means that TSC runs at a constant rate
during all ACPI state changes. If it is variant, skew may occur and TSC is
generally unsuitable for wall clock services. This is especially relevant
with C-states; with variant TSC, the whole counter may be stopped with states
larger than C1. All x86 CPUs before circa mid-2000s can be assumed to have a
variant time stamp counter.

Add two flags that needs to be dealt with (hardware vs. software
coordination of P-state transitions, and Turbo Boost / Turbo Core).

Use the idea from cegger@ and fill the (X)PSS structure during initialization.

Add support for the optional dynamic minimum (in terms of MHz) via _PDL.
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)

branches: 1.17.2;
Now that the deferred configuration actually works as expected and documented,
use config_defer(9) instead of config_finalize_register(9), and simplify the
code paths around the initialization.

Add support for Extended PSS ACPI Method Specification from Microsoft.
This will greatly simplify supporting PowerNow! on conforming systems.

Move the PIIX4-quirk to the MD file and disable T-states for PIIX4.

Merge T-state a.k.a. throttling support for acpicpu(4).

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.

branches: 1.13.2;
Use a define instead of a magic constant for the arbitrary P-state limit.

Use evcnt(9) for the counters.

Remove a redundant function.

jmcneill@: do not touch the bus_space(9) handle.

Merge P-state support for acpicpu(4).

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.

On second thought, rename the mutex so it can be (logically) shared. We will
not need such granularity that different states would require a different lock.

Add a per ACPI CPU mutex for C-states. Protect the _CST update with this:
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.

Move the GAS definition to the header so it can be shared. Make a basic
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.

Add a new flag that determines whether we should check for bus master
activity (BM_STS) by reading from the PM1 register. According to the Intel
processor specification for ACPI, the FFH GAS encoding may provide a hint
that the check is not required. This may help some systems to enter C2/C3
even when e.g. usb(4) keeps the BM_STS bit always enabled.

Remove the recently added ACPICPU_FLAG_INIT and instead operate with the
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.

XXX: If this is not correct, revert or fix.
This makes my laptop boot instead of panic:

panic: kernel diagnostic assertion "native_idle != NULL" failed: file "../../../../arch/x86/acpi/acpi_cpu_md.c", line 155
fatal breakpoint trap in supervisor mode
type 1 code 0 rip ffffffff8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp ffff80004c37db10

trace
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62
acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34
sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41

1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that
2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of
attaching the unmatched ones, make the match fail. Do we want to
attach and do nothing instead?
3. Create a flag, and only set it after we are completely initialized,
so the sysmon thread does not try to access unitialized state.

Add missing CVS identifiers.

Merge a driver for ACPI CPUs with basic support for processor power states,
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).

Remarks:

1. Commented out in the GENERICs; more testing exposure is needed.

2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.

3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.

Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.

4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.

ok jmcneill@, joerg@, and discussed with various people.