MFC r344855 (by jhb):

Drop "All rights reserved" from my copyright statements.

Reviewed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D19485

MFC r333806:
Use NULL for SYSINIT's last arg, which is a pointer type

Sponsored by: The FreeBSD Foundation

MFC of r355574, r358095, and r358395:

Add ACPI battery subsystem man page.

Add _BIX (Battery Information Extended) object support.

ACPI Control Method Batteries have a _BIF and/or _BIX object which
provide static properties of the battery. FreeBSD acpi_cmbat module
supported _BIF object only, which was deprecated as of ACPI 4.0.
_BIX is an extended version of _BIF defined in ACPI 4.0 or later.

As of writing, _BIX has two revisions. One is in ACPI 4.0 (rev.0) and
another is in ACPI 6.0 (rev.1). It seems that hardware vendors still
stick to _BIF only or _BIX rev.0 + _BIF for the maximum compatibility.
Microsoft requires _BIX rev.0 for Windows machines, so there are some
laptop machines with _BIX rev.0 only. In this case, FreeBSD does not
recognize the battery information.

After this change, the acpi_cmbat module gets battery information from
_BIX or _BIF object and internally uses _BIX rev.1 data structure as
the primary information store in the kernel. ACPIIO_BATT_GET_BI[FX]
returns an acpi_bi[fx] structure built by using information obtained
from a _BIF or a _BIX object found on the system. The revision number
field can be used to check which field is available. The acpiconf(8)
utility will show additional information if _BIX is available.

Although ABIs of ACPIIO_BATT_* were changed, the existing APIs for
userland utilities are not changed and the backward-compatible ABIs
are provided. This means that older versions of acpiconf(8) can also
work with the new kernel. The (union acpi_battery_ioctl_arg) was
padded to 256 byte long to avoid another ABI change in the future.
A _BIX object with its revision number >1 will be treated as
compatible with the rev.1 _BIX format.

Add workaround for models which do not follow the ACPI specification strictly.
Extra objects are now simply ignored instead of rejecting everything.

Differential Revision: https://reviews.freebsd.org/D22556
Differential Revision: https://reviews.freebsd.org/D23728

MFC r358537:
Expose the ACPI power button, sleep button and LID state as evdev's.

This allows libinput to disable touchpads when the lid is closed and
various desktop environments can show power-off dialogs when the power
button is pressed. While the latter is doable with devd a
cross-platform solution is nicer.

Submitted by: Greg V <greg@unrelenting.technology>
Differential Revision: https://reviews.freebsd.org/D23863
Sponsored by: Mellanox Technologies

MFC r358219 and r358270:
Make sure the ACPI lid state is updated during boot and after resume.
While at it update the sysctl(9) description for the lid state.

Always check return value from acpi_GetInteger().
If a failure happens reading the lid state, assume the lid is opened.

Differential Revision: https://reviews.freebsd.org/D23724
PR: 240881
Submitted by: Yuri Pankov <yuripv@yuripv.me>
Sponsored by: Mellanox Technologies

MFC r315166:
Export the actual LID state via sysctl. This allows more complex
policies about when to suspend based on other events happening AND the
lid being closed through the use of clever devd or other scripts.

MFC r326956 (by cem):
Implement ACPI CPU support when Processor object is not present

By the ACPI standard (ACPI 5 chapter 8.4 Declaring Processors) Processors
can be implemented in 2 distinct ways:

* Through a Processor object type (which provides P_BLK)
* Through a Device object type

Prior to this change, the FreeBSD driver only supported the former. AMD
Epyc / Poweredge systems we are testing both implement the latter only. Add
the missing support.

Because P_BLK is not defined in the device object case, C-states entering
must be completely controlled via _CST methods rather than P_LVL2/3.

John Baldwin points out that ACPI 6.0 formally deprecates the Processor
keyword, so eventually processors will only be enumerated as Device objects.

MFC 353585,353586: Support hot insertion and removal of PCI devices on EC2.

353585:
Export pci_attach() and pci_detach().

353586:
Support hot insertion and removal of PCI devices on EC2.

Install ACPI notify handlers on PCI devices with an _EJ0 method. This
handler is invoked when devices are added or removed.

- When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus
device. Note that strictly speaking we only need to rescan the
specified device, but BUS_RESCAN is what is available, so we rescan
the entire bus.
- When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device
associated with the ACPI handle, invoke the _EJ0 method, and then
delete the device.

Eventually this might be changed to vector notify events to devd in
userspace where devctl can be used instead to permit more complex
actions such as graceful unmounting of filesystems.

MFC 350662:
Detect invalid PCI devices more correctly in PCI interrupt router drivers.

- Check for an invalid device (vendor is invalid) before reading the
header type register when examining function 0 of a possible device.
- When iterating over functions of a device, reject any device whose
16-bit vendor is invalid rather than requiring the full 32-bit
vendor+device to be all 1's. In practice the latter check is
probably fine, but checking the vendor is what the PCI spec
recommends.

MFC r348065:

Correct the way remaining battery life is calculated

Previously, if a system had multiple batteries, the remaining life
percentage was calculated as the average of each battery's percent
remaining. This results in rather incorrect values when you consider the
case of the Thinkpad X270 that has a small 3 cell internally battery, and
a hot-swappable 9 cell battery that is used first. Battery 0 is at 100%,
but battery 1 is at 10%, you do not infact have 55% of your capacity
remaining.

The new method calculates the percentage based on remaining capacity
out of total capacity, giving a much more accurate reading.

PR: 229818
Submitted by: Keegan Drake H.P. <kd-dev@pm.me>
Sponsored by: Klara Systems
Event: Waterloo Hackathon 2019
Approved by: re (gjb)

MFC 346063: Don't pre-reserve resources for CPU devices when they are set.

CPUs can use shared (RF_SHAREABLE) resources for the I/O port used for
entering and exiting C states. If this I/O port is included in an ACPI
system resource device, then this happens to still work, but if the port
wasn't part of a system resource device, only the first CPU could allocate
the I/O port and use C states since resource_list_reserve() was always
allocating the resource from nexus0 without RF_SHAREABLE. By avoiding
the reservation, the flags from the bus_alloc_resource() in the CPU driver
(which include RF_SHAREABLE) are honored.

PR: 236513

MFC 339899: Make battery emptying rate available as sysctl variable.

Curiously, the in-kernel routines always use the design voltage to
convert from mA to mW, but acpiconf in userland uses the current
voltage. As a result, this can report a different mW rate than
acpiconf.

Backport of r338074 - generalize uart_bus_probe and add SNPS support to x86

Submitted by: Rajesh Kumar
Differential Revision: https://reviews.freebsd.org/D17381

MFC r335934: remove unneeded inclusion of sys/interrupt.h from several files

MFC r334479: call AcpiLeaveSleepStatePrep after re-enabling interrupts

MFC r334204,r334338: re-synchronize TSC-s on SMP systems after resume

MFC r333994: stop and restart kernel event timers in the suspend / resume cycle

MFC r332918, r333222: go deeper for ACPI suspend bounce test

debug.acpi.suspend_bounce sysctl now allows a deeper dive into the sleep
abyss. The system will execute the suspend sequence up to the call to
AcpiEnterSleepState(). That includes saving processor contexts and
parking APs. Then, instead of actually entering the sleep state, the
BSP will call resumectx() to emulate the wakeup. The APs should get
restarted by the sequence of Init and Startup IPIs that BSP sends to
them.

AcpiOsEnterSleep() is used to implement this feature.

Joint work with jkim.

MFC r333209: hpet: use macros instead of magic values for the timer mode

MFC 332733:
Workaround fixed I/O port resources encoded as I/O port ranges in _CRS.

ACPI I/O port descriptors use _MIN and _MAX fields to specify the set
of allowable base (start) addresses for an I/O port resource along with
a _LEN field specifying the length. A fixed resource is supposed to be
encoded with _MIN == _MAX, but some buggy firmwares instead set _MAX to
the end of the fixed range. Relocating I/O ranges only make sense in
_PRS (possible resource settings), not in _CRS (current resource settings),
so if an I/O port range with _MAX set set to the end of the range is
present in _CRS, treat it as a fixed I/O port resource starting at
_MIN.

PR: 224096

MFC r313447:
Ensure the idle thread's loop services interrupts in a timely way when
using the ACPI C1/mwait sleep method.

Previously, the mwait instruction would return when an interrupt was
pending; however, the idle loop did not actually enable interrupts when
this occurred. This led to a situation where the idle loop could quickly
spin through the C1/mwait sleep method a number of times when an interrupt
was pending. (Eventually, the situation corrected itself when something
other than an interrupt triggered the idle loop to either enable
interrupts or schedule another thread.)

Sponsored by: Netflix, Inc.

MFC r316648:

Corrected misspelled versions of rendezvous.

The MFC maintains smp_no_rendevous_barrier() as a symbol alias of
smp_no_rendezvous_barrier().

__FreeBSD_version bumped to indicate presence of the new name
smp_no_rendezvous_barrier().

Reviewed by: gnn, jhb (email), kib
Differential Revision: https://reviews.freebsd.org/D10313

MFC: r323076, r324502, r325670, r326866

Merge ACPICA 20171214.

MFC: r324501

Do not check whether AcpiOsGetTimer() is called during boot.

MFC: r319365, r321670

Merge ACPICA 20170728.

MFC r320690:
Defer ACPI taskqueue creation to SI_SUB_KICK_SCHEDULER.

PR: 220277

MFC 318136

hyperv/vmbus: Reorganize vmbus device tree

For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the
resources for PCI passthrough and SR-IOV. There is no
acpi_syscontainer0 on GEN1 Hyper-V.

For GEN2 Hyper-V, vmbus is attached to acpi_syscontainer0, which
contains the resources for PCI passthrough and SR-IOV. There is
no pcib0 on GEN2 Hyper-V.

The ACPI VMBUS device now only holds its _CRS, which is empty as
of this commit; its existence is mainly for upward compatibility.

Device tree structure is suggested by jhb@.

Tested-by: dexuan@
Collabrated-wth: dexuan@
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D10565

MFC: r306686, r308953, r311462, r311529, r312438, r314611

- Merge ACPICA 20170303.
- Remove '-vd' option to make iasl(8) reproducible.

Relnotes: yes

MFC r314328:

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by: avg @

MFC r313817

acpica: remove a superfluous NULL check

The address-of operator can't produce NULL (in practice).
Remove an unnecessary NULL check.

Sponsored by: Dell EMC

MFC r314211:
Remove cpu_deepest_sleep variable.

MFC 309588: Don't attach to Host-PCI bridges with a bad bus number.

If the bus number assigned to a Host-PCI bridge doesn't match the first
bus number in the associated producer range from _CRS, print a warning and
fail to attach rather than panicking due to an assertion failure.

At least one single-socket Dell machine leaves a "ghost" Host-PCI bridge
device in the ACPI namespace that seems to correspond to the I/O hub in
the second socket of a two-socket machine. However, the BIOS doesn't
configure the settings for this "ghost" bridge correctly, nor does it have
any PCI devices behind it.

MFC r309400:
Fix for endless recursion in the ACPI GPE handler during boot.

When handling a GPE ACPI interrupt object the EcSpaceHandler()
function can be called which checks the EC_EVENT_SCI bit and then
recurse on the EcGpeQueryHandler() function. If there are multiple GPE
events pending the EC_EVENT_SCI bit will be set at the next call to
EcSpaceHandler() causing it to recurse again via the
EcGpeQueryHandler() function. This leads to a slow never ending
recursion during boot which prevents proper system startup, because
the EC_EVENT_SCI bit never gets cleared in this scenario.

The behaviour is reproducible with the ALASKA AMI in combination with
a newer Skylake based mainboard in the following way:

Enter BIOS and adjust the clock one hour forward. Save and exit the
BIOS. System fails to boot due to the above mentioned bug in
EcGpeQueryHandler() which was observed recursing multiple times.

This patch adds a simple recursion guard to the EcGpeQueryHandler()
function and also also adds logic to detect if new GPE events occurred
during the execution of EcGpeQueryHandler() and then loop on this
function instead of recursing.

Reviewed by: jhb

MFC r304285:
Implement userspace gettimeofday(2) with HPET timecounter.

MFC r304279:
By default, allow all to read the HPET registers pages. At the same
time, by, by default disallow writes to the mmaped HPET pages.

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Fix a minor leak in ACPI thermal

Introduced in r301518.

Reported by: Coverity
CID: 1356266
Sponsored by: EMC / Isilon Storage Division

Defer the creation of ACPI thermal kthreads to a startup sysinit.

The SYSINIT runs at SI_SUB_KICK_SCHEDULER after the scheduler is fully
initialized and timers are working. This fixes booting in the
EARLY_AP_STARTUP case.

[acpi] graphics drivers want access to acpi lid handle

the graphics drivers can benefit from access to the lid handle for querying and getting notifications

Submitted by: kmacy
Differential Revision: https://reviews.freebsd.org/D6643

Fix the deciKelvin to Celsius conversion in kernel.

After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C
reference and as result, the temperature read in sysctl(8) now exibits a
+0.1C difference.

This commit fix the kernel references to match the reference value used in
sysctl(8) after r285994.

Sponsored by: Rubicon Communications (Netgate)

Implement a proper detach method for the PCI-PCI bridge driver.

- Add a pcib_detach() function for the PCI-PCI bridge driver. It
tears down the NEW_PCIB and hotplug state including destroying
resource managers, deleting child devices, and disabling hotplug
events.
- Add a detach method to the ACPI PCI-PCI bridge driver which calls
pcib_detach() and then frees the copy of the _PRT interrupt routing
table.
- Add a detach method to the PCI-Cardbus bridge driver which frees
the PCI bus resources in addition to calling cbb_detach().
- Explicitly clear any pending hotplug events during attach to ensure
future events will generate an interrupt.
- If a the Command Completed bit is set in the slot status register
when the command completion timeout fires, treat it as if the
command completed and the completion interrupt was just lost rather
than forcing a detach.
- Don't wait for a Command Completed notification if Command Completion
interrupts are disabled. The spec explicitly says no interrupt is
enabled when clearing CCIE, and on my T400 no interrupt is generated
when CCIE is changed from cleared to set, either. In addition, the
T400 doesn't appear to set the Command Completed bit in the cases
where it doesn't generate an interrupt, so don't schedule the timer
either. (If the CC bit were always set, one could always set the timer
and rely on the logic of treating CC set as a missed interrupt.)

Reviewed by: imp (older version)
Differential Revision: https://reviews.freebsd.org/D6424

Use polling spin loops for timeouts during early boot.

Some ACPI operations such as mutex acquires and event waits accept a
timeout. The ACPI OSD layer implements these timeouts by using regular
sleep timeouts. However, this doesn't work during early boot before
event timers are setup. Instead, use polling combined with DELAY()
to spin.

This fixes booting on upcoming Intel systems with Kaby Lake processors.

Tested by: "Jeffrey E Pieper" <jeffrey.e.pieper@intel.com>
Reviewed by: jimharris
MFC after: 1 week

Add an EARLY_AP_STARTUP option to start APs earlier during boot.

Currently, Application Processors (non-boot CPUs) are started by
MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until
SI_SUB_SMP at which point they are released to run kernel threads.
SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter
the scheduler and start running threads until fairly late in the
boot.

This change moves SI_SUB_SMP up to just before software interrupt
threads are created allowing the APs to start executing kernel
threads much sooner (before any devices are probed). This allows
several initialization routines that need to perform initialization
on all CPUs to now perform that initialization in one step rather
than having to defer the AP initialization to a second SYSINIT run
at SI_SUB_SMP. It also permits all CPUs to be available for
handling interrupts before any devices are probed.

This last feature fixes a problem on with interrupt vector exhaustion.
Specifically, in the old model all device interrupts were routed
onto the boot CPU during boot. Later after the APs were released at
SI_SUB_SMP, interrupts were redistributed across all CPUs.

However, several drivers for multiqueue hardware allocate N interrupts
per CPU in the system. In a system with many CPUs, just a few drivers
doing this could exhaust the available pool of interrupt vectors on
the boot CPU as each driver was allocating N * mp_ncpu vectors on the
boot CPU. Now, drivers will allocate interrupts on their desired CPUs
during boot meaning that only N interrupts are allocated from the boot
CPU instead of N * mp_ncpu.

Some other bits of code can also be simplified as smp_started is
now true much earlier and will now always be true for these bits of
code. This removes the need to treat the single-CPU boot environment
as a special case.

As a transition aid, the new behavior is available under a new kernel
option (EARLY_AP_STARTUP). This will allow the option to be turned off
if need be during initial testing. I plan to enable this on x86 by
default in a followup commit in the next few days and to have all
platforms moved over before 11.0. Once the transition is complete,
the option will be removed along with the !EARLY_AP_STARTUP code.

These changes have only been tested on x86. Other platform maintainers
are encouraged to port their architectures over as well. The main
things to check for are any uses of smp_started in MD code that can be
simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in
the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).

PR: kern/199321
Reviewed by: markj, gnn, kib
Sponsored by: Netflix

Remove misc NULL checks after M_WAITOK allocations.

MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Add a new bus method to fetch device-specific CPU sets.

bus_get_cpus() returns a specified set of CPUs for a device. It accepts
an enum for the second parameter that indicates the type of cpuset to
request. Currently two valus are supported:

- LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to
the device when DEVICE_NUMA is enabled)
- INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core)

For systems that do not support NUMA (or if it is not enabled in the kernel
config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus'
by default. The idea is that INTR_CPUS should always return a valid set.

Device drivers which want to use per-CPU interrupts should start using
INTR_CPUS instead of simply assigning interrupts to all available CPUs.
In the future we may wish to add tunables to control the policy of
INTR_CPUS (e.g. should it be local-only or global, should it ignore
SMT threads or not).

The x86 nexus driver exposes the internal set of interrupt CPUs from the
the x86 interrupt code via INTR_CPUS.

The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable
LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and
the global INTR_CPUS set from the nexus driver with the per-domain set from
_PXM to generate a local INTR_CPUS set for child devices.

Compared to the r298933, this version uses 'struct _cpuset' in
<sys/bus.h> instead of 'cpuset_t' to avoid requiring <sys/param.h>
(<sys/_cpuset.h> still requires <sys/param.h> for MAXCPU even though
<sys/_bitset.h> does not after recent changes).

Native PCI-express HotPlug support.

PCI-express HotPlug support is implemented via bits in the slot
registers of the PCI-express capability of the downstream port along
with an interrupt that triggers when bits in the slot status register
change.

This is implemented for FreeBSD by adding HotPlug support to the
PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges
representing downstream ports on HotPlug slots. The PCI-PCI bridge
driver registers an interrupt handler to receive HotPlug events. It
also uses the slot registers to determine the current HotPlug state
and drive an internal HotPlug state machine. For simplicty of
implementation, the PCI-PCI bridge device detaches and deletes the
child PCI device when a card is removed from a slot and creates and
attaches a PCI child device when a card is inserted into the slot.

The PCI-PCI bridge driver provides a bus_child_present which claims
that child devices are present on HotPlug-capable slots only when a
card is inserted. Rather than requiring a timeout in the RC for
config accesses to not-present children, the pcib_read/write_config
methods fail all requests when a card is not present (or not yet
ready).

These changes include support for various optional HotPlug
capabilities such as a power controller, mechanical latch,
electro-mechanical interlock, indicators, and an attention button.
It also includes support for devices which require waiting for
command completion events before initiating a subsequent HotPlug
command. However, it has only been tested on ExpressCard systems
which support surprise removal and have none of these optional
capabilities.

PCI-express HotPlug support is conditional on the PCI_HP option
which is enabled by default on arm64, x86, and powerpc.

Reviewed by: adrian, imp, vangyzen (older versions)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D6136

Fix intmax_t to uintptr_t casting on 32-bit platforms. Found by GCC.

Submitted by: bde

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

Revert bus_get_cpus() for now.

I really thought I had run this through the tinderbox before committing,
but many places need <sys/types.h> -> <sys/param.h> for <sys/bus.h> now.

Add a new bus method to fetch device-specific CPU sets.

bus_get_cpus() returns a specified set of CPUs for a device. It accepts
an enum for the second parameter that indicates the type of cpuset to
request. Currently two valus are supported:

- LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to
the device when DEVICE_NUMA is enabled)
- INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core)

For systems that do not support NUMA (or if it is not enabled in the kernel
config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus'
by default. The idea is that INTR_CPUS should always return a valid set.

Device drivers which want to use per-CPU interrupts should start using
INTR_CPUS instead of simply assigning interrupts to all available CPUs.
In the future we may wish to add tunables to control the policy of
INTR_CPUS (e.g. should it be local-only or global, should it ignore
SMT threads or not).

The x86 nexus driver exposes the internal set of interrupt CPUs from the
the x86 interrupt code via INTR_CPUS.

The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable
LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and
the global INTR_CPUS set from the nexus driver with the per-domain set from
_PXM to generate a local INTR_CPUS set for child devices.

Reviewed by: wblock (manpage)
Differential Revision: https://reviews.freebsd.org/D5519

Only count CPU devices that are using the ACPI CPU driver.

Arguably we should only be doing the probe/attach to children of
these devices as well.

Tested by: Michal Stanek <mst_semihalf.com> (arm64)
Differential Revision: https://reviews.freebsd.org/D6133

Adjust prototypes for NUMA-related functions to match the style of the
rest of this file.

Merge ACPICA 20160422.

Add a pcib_attach_child() method to manage adding the child "pci" device.

This allows the PCI-PCI bridge driver to save a reference to the child
device in its softc.

Note that this required moving the "pci" device creation out of
acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to
acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI
interrupt routing table.

Differential Revision: https://reviews.freebsd.org/D6021

Optionally return the output capabilities list from _OSC.

Both of the callers were expecting the input cap_set to be modified.
This fixes them to request cap_set to be updated with the returned buffer.

Reviewed by: jkim
Differential Revision: https://reviews.freebsd.org/D6040

Queue the CPU-probing task after all acpi_cpu devices are attached.

Eventually with earlier AP startup this code will change to call the
startup function synchronously instead of queueing the task. Moving
the time we queue the task should be a no-op since taskqueue threads
don't start executing tasks until much later, but this reduces the diff
with the earlier AP startup patches.

Sponsored by: Netflix

Prefer sizeof(*pointer) over sizeof(type). No funtional change.

There is no need to use array any more. No functional change.

Remove query flag from acpi_EvaluateOSC(). This function does not support
return buffer (yet).

Invoke _OSC on Host-PCI bridges.

Tell the firmware that we support PCI-express config space access
and MSI.

Reviewed by: jkim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6023

Add a wrapper for evaluating _OSC methods.

This wrapper does not translate errors in the first word to ACPI
error status returns. Use this wrapper in the acpi_cpu(4) driver in
place of the existing _OSC code. While here, fix a bug where the wrong
count of words was passed when invoking _OSC.

Reviewed by: jkim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6022

Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.

The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.

This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.

As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.

Differential Revision: https://reviews.freebsd.org/D5891

Add more fine-grained kernel options for NUMA support.

VM_NUMA_ALLOC is used to enable use of domain-aware memory allocation in
the virtual memory system. DEVICE_NUMA is used to enable affinity
reporting for devices such as bus_get_domain().

MAXMEMDOM must still be set to a value greater than for any NUMA support
to be effective. Note that 'cpuset -gd' always works if MAXMEMDOM is
enabled and the system supports NUMA.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D5782

Associate device_t objects with ACPI handles via PCI_CHILD_ADDED().

Previously, the ACPI PCI bus driver did a single pass over the devices in
the namespace that were a child of a given PCI bus to associate the
PCI bus-enumerated device_t devices with the corresponding ACPI handles.
However, this meant that handles were only established at runtime for devices
found during the initial PCI bus scan.

PCI_IOV adds devices that show up after the initial PCI bus scan, and coming
changes to add a bus rescan can also add devices after the initial scan.

This change adds a pci_child_added() callback to the ACPI PCI bus that walks
the namespace to find the ACPI handle for each device that is added. Using
a callback means that the handle is correctly set for any device no matter
how it is added (initial scan, IOV, or a bus rescan).

Convert pci_delete_child() to a bus_child_deleted() method.

Instead of providing a wrapper around device_delete_child() that the PCI
bus and child bus drivers must call explicitly, move the bulk of the logic
from pci_delete_child() into a bus_child_deleted() method
(pci_child_deleted()). This allows PCI devices to be safely deleted via
device_delete_child().
- Add a bus_child_deleted method to the ACPI PCI bus which clears the
device_t associated with the corresponding ACPI handle in addition to
the normal PCI bus cleanup.
- Change cardbus_detach_card to call device_delete_children() and move
CardBus-specific delete logic into a new cardbus_child_deleted() method.
- Use device_delete_child() instead of pci_delete_child() in the SRIOV code.
- Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which
frees the OpenFirmware device info for each PCI device.

Reviewed by: imp
Tested on: amd64 (CardBus and PCI-e hotplug)
Differential Revision: https://reviews.freebsd.org/D5831

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544

Remove default initializations for rman, a'la r296331

Silence PVS-Studio warning (V595).

Silence PVS-Studio warning (V595).

Remove brightness notify handler before reinstalling new one.

Fix white spaces.

Fix style(9) bugs.

Some BIOSes ACPI bytecode needs to take (sleepable) acpi mutex for
acpi_GetInteger() execution. Intel DMAR interrupt remapping code
needs to know UID of the HPET to properly route the FSB interrupts
from the HPET, even when interrupt remapping is disabled, and the code
is executed under some non-sleepable mutexes.

Cache HPET UIDs in the device softc at the attach time and provide
lock-less method to get UID, use the method from the dmar hpet
handling code instead of calling GetInteger().

Reported and tested by: Larry Rosenman <ler@lerctr.org>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Switch /dev/hpet to use make_dev_s(9). Device needs si_drv1
initializated, do it correctly even though hpet cannot be loaded as
module.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.

This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.

This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.

Discussed with: jhb
Suggested by: marcel

document some ACPI related sysctls.

Submitted by: Oliver Pinter <oliver.pinter@hardenedbsd.org>
Sponsored by: HardenedBSD
Differential Revision: https://reviews.freebsd.org/D5263

Remove a bogus bzero() call.

Found by: PVS-Studio

Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075

Disable suspend when we're shutting down. This solves the "tell FreeBSD
to shut down; close laptop lid" scenario which otherwise tended to end
with a laptop overheating or the battery dying.

The implementation uses a new sysctl, kern.suspend_blocked; init(8) sets
this while rc.suspend runs, and the ACPI sleep code ignores requests while
the sysctl is set.

Discussed on: freebsd-acpi (35 emails)
MFC after: 1 week

Add domain support to PCI bus allocation

When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.

Reviewed by: jhb
Obtained from: Semihalf
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406

Merge ACPICA 20150818.

Catch up with ACPICA 20150717.

Add basic support for ACPI. It splits out the nexus driver to two new
drivers, one for fdt, one for acpi. It then uses this to decide if it will
use fdt or acpi.

The GICv2 (interrupt controller) and Generic Timer drivers have been
updated to handle both cases.

As this is early code we still need FDT to find the kernel console, and
some parts are still missing, including PCI support.

Differential Revision: https://reviews.freebsd.org/D2463
Reviewed by: jhb, jkim, emaste
Obtained from: ABT Systems Ltd
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Check status of AcpiReadBitRegister() calls.

Reported by: Coverity
CID: 1306132

CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.

Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks

Do not probe Intel PIIX4 south bridge quirks on amd64. These quirky south
bridges only supported Intel Pentium and Pentium II era processors and there
is no reason for hardware virtualizations to emulate these quirks.

MFC after: 1 week

Hide code only used on i386 and amd64.

If x86 CPU implementation of the MWAIT instruction reasonably
interacts with interrupts, query ACPI and use MWAIT for entrance into
Cx sleep states. Support C1 "I/O then halt" mode. See Intel'
document 302223-007 "Intelб╝ Processor Vendor-Specific ACPI Interface
Specification" for description.

Move the acpi_cpu_c1() function into x86/cpu_machdep.c and use
it instead of inlining "sti; hlt" sequence in several places.

In the acpi(4) man page, besides documenting the dev.cpu.N.cx_methods
sysctl, correct the names for dev.cpu.N.{cx_usage,cx_lowest,cx_supported}
sysctls.

Both jkim and avg have some other patches implementing the mwait
functionality; this work is unrelated. Linux does not rely on the
ACPI to provide correct tables describing Cx modes. Instead, the
driver has pre-defined knowledge of the CPU models, it was supplied by
Intel.

Tested by: pho (previous versions)
Sponsored by: The FreeBSD Foundation

AcpiGbl_FACS will not be defined when building using the reduced hardware
model. This may be the case on ARM.

If the power management timer is unsupported the PmTimerLength value will
be zero.

There may not be an FACS table, check for this before accessing it.

Sponsored by: The FreeBSD Foundation

Refactor out the _PXM -> VM domain lookup done in ACPI, in preparation for
its use in upcoming code.

This is inspired by something in jhb's NUMA IRQ allocation patchset.

However, the tricky bit here is that the PXM lookup for a node may
fail, requiring a lookup on the parent node. So if it doesn't
exist, don't fail - just go up to the parent. Only error out of the
lookup is the ACPI lookup returns an error.

Sponsored by: Norse Corp, Inc.

Define capabilities bits from the revision 007 of the document 302223
"Intelб╝ Processor Vendor-Specific ACPI Interface Specification",
issied Dec 2014. Previous revision 005 was from Sep 2006.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Merge ACPICA 20150410.

Move the message complaining about failed system resource allocations
under bootverbose. Every example I've seen to date has been due to
an ACPI system resource device reserving a range that overlaps with
system memory (which ram0 attempts to reserve) or a local or I/O APIC
(which apic0 attempts to reserve). These are always harmless but look
scary to users.

MFC after: 1 week

Fix a typo.

Implement interface to create SR-IOV Virtual Functions

Implement the interace to create SR-IOV Virtual Functions (VFs).
When a driver registers that they support SR-IOV by calling
pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov
for that device. An ioctl can be invoked on that device to
create VFs and have the driver initialize them.

At this point, allocating memory I/O windows (BARs) is not
supported.

Differential Revision: https://reviews.freebsd.org/D76
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

Array cannot be NULL, remove always true comparision. ACPI spec
identifies the tested condition for _PRT as "BYTE value of 0", so the
remaining part of the conditionals is sufficient.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Add a new device control utility for new-bus devices called devctl. This
allows the user to request administrative changes to individual devices
such as attach or detaching drivers or disabling and re-enabling devices.
- Add a new /dev/devctl2 character device which uses ioctls for device
requests. The ioctls use a common 'struct devreq' which is somewhat
similar to 'struct ifreq'.
- The ioctls identify the device to operate on via a string. This
string can either by the device's name, or it can be a bus-specific
address. (For unattached devices, a bus address is the only way to
locate a device.) Bus drivers register an eventhandler to claim
unrecognized device names that the driver recognizes as a valid address.
Two buses currently support addresses: ACPI recognizes any device
in the ACPI namespace via its full path starting with "\" and
the PCI bus driver recognizes an address specification of
'pci[<domain>:]<bus>:<slot>:<func>' (identical to the PCI selector
strings supported by pciconf).
- To make it easier to cut and paste, change the PnP location string
in the PCI bus driver to output a full PCI selector string rather
than 'slot=<slot> function=<func>'.
- Add a devctl(3) interface in libdevctl which provides a wrapper around
the ioctls and is the preferred interface for other userland code.
- Add a devctl(8) program which is a simple wrapper around the requests
supported by devctl(3).
- Add a device_is_suspended() function to check DF_SUSPENDED.
- Add a resource_unset_value() function that can be used to remove a
hint from the kernel environment. This is used to clear a
hint.<driver>.<unit>.disabled hint when re-enabling a boot-time
disabled device.

Reviewed by: imp (parts)
Requested by: imp (changing PCI location string)
Relnotes: yes

hook userland threads suspend + resume into acpi suspend code

Also, split power_suspend into power_suspend and power_suspend_early.

power_suspend_early is called before the userland is frozen.
power_suspend is called after the userland is frozen.

Currently only VT switching is hooked to power_suspend_early.
This is needed because switching away from X server requires its
cooperation, so obviously X server must not be frozen when that happens.

Freezing userland during ACPI suspend is useful because not all drivers
correctly handle suspension concurrent with other activity. This is
especially applicable to drivers ported from other operating systems
that suspend all software activity between placing drivers and hardware
into suspended state.
In particular drm2/radeon (radeonkms) depends on the described
procedure. The driver does not have any internal synchronization
between suspension activities and processing of userland requests.

Many thanks to kib for the code that allows to freeze and thaw all
userland threads.

Note that ideally we also need to park / inhibit (non-special) kernel
threads as well to ensure that they do not call into drivers.

MFC after: 17 days

Simplify retry loops. No functional change.

Revert r216942. This commit was premature and caused too many complaints.

PR: 162859
MFC after: 3 days

When disabling C3+ CPU states due to the CPU_QUIRK_NO_C3 quirk, don't
accidentally enable non-existent states.

This bug was triggered if ACPI advertises the presence of a C2 state
which we fail to parse via acpi_PkgGas due to our lack of support for
FFixedHW resources, and causes an immediate panic when an attempt is
made to enter the (NULL) state.

One affected platform is the EC2 c4.8xlarge VM instance type; there
may be others.

MFC after: 1 week
Thanks to: jkim, @_msw_

On some Intel CPUs with a P-state but not C-state invariant TSC the TSC
may also halt in C2 and not just C3 (it seems that in some cases the BIOS
advertises its C3 state as a C2 state in _CST). Just play it safe and
disable both C2 and C3 states if a user forces the use of the TSC as the
timecounter on such CPUs.

PR: 192316
Differential Revision: https://reviews.freebsd.org/D1441
No objection from: jkim
MFC after: 1 week

Use the correct device. Note this commit complements r274386.

PR: 194884

Use the correct device (child) when asking the bus layer about which power
state said device should go into.

This was a snafu introduced in the ACPI/PCI awareness separation.

When putting a device into a power state, the bus (and thus firmware,
eg ACPI) should be asked before hand to check whether the device
can indeed go into that power state.

There's a set of nodes in ACPI under each device - the _SxD nodes - which
state which ACPI power state to put the device into when the system is
going into power save state 'x'. So when going into S3, the existence
of an _S3D node would override whatever the system was trying to do.

By default the PCI code wants to put devices into D3 before suspending.

I have a laptop here (Asus Zenbook - check the PR) whose EHCI controller
really wants to be in D2 during suspend, not D3. So if we put it into
D3 and then try to enter S3, everything hangs. The device itself
can go into D3 - it just can't be there when the call to ACPI to enter
S3 occurs. The PCI patch fixes this.

jkim@ noticed that the same is needed for the ACPI child device
enumeration.

Thankyou to Matt Dillon (the programmer, not the actor) for buying me
this particular laptop so I could debug the issues with the Atheros
AR9485 that is in it. It's his fault that I ended up with this
laptop and was sufficiently annoyed by the lack of USB suspend
to go down this rabbit hole.

Tested:

* Thinkpad T400
* Thinkpad X230
* Thinkpad T42
* Thinkpad T60
* Asus Zenbook (see PR)
* Asus EEEPC 701
* Asus EEEPC 1001PX

TODO:

* Figure out what we should do about devices we unload drivers for
that want to be in a specific state when entering S3 / S4 -
the "put devices into D3 if they're not bound to a driver" option
may also mess with things.

PR: kern/194884
Reviewed by: jhb, jkim
MFC after: 1 week
Relnotes: yes
Sponsored by: Matt Dillon <dillon@apollo.backplane.com> (hardware)

The SYSCTL data pointers can come from userspace and must not be
directly accessed. Although this will work on some platforms, it can
throw an exception if the pointer is invalid and then panic the kernel.

Add a missing SYSCTL_IN() of "SCTP_BASE_STATS" structure.

MFC after: 3 days
Sponsored by: Mellanox Technologies

Set the caching mode for the usermode mapping of the HPET registers
page to uncached.

Reviewed by: rpaulo
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Add a sysctl to control the HPET allow_write behaviour.

Requested by: kib

HPET: avoid handling the multiple file-descriptor case.

It had two bugs: one where mmap was still allowed and another where
D_TRACKCLOSE doesn't handle all cases.

Thanks to jhb and kib for pointing them out.
MFC after: 1 week

HPET: create /dev/hpetN as a way to access HPET from userland.

In some cases, TSC is broken and special applications might benefit
from memory mapping HPET and reading the registers to count time.
Most often the main HPET counter is 32-bit only[1], so this only gives
the application a 300 second window based on the default HPET
interval.
Other applications, such as Intel's DPDK, expect /dev/hpet to be
present and use it to count time as well.

Although we have an almost userland version of gettimeofday() which
uses rdtsc in userland, it's not always possible to use it, depending
on how broken the multi-socket hardware is.

Install the acpi_hpet.h so that applications can use the HPET register
definitions.

[1] I haven't found a system where HPET's main counter uses more than
32 bit. There seems to be a discrepancy in the Intel documentation
(claiming it's a 64-bit counter) and the actual implementation (a
32-bit counter in a 64-bit memory area).

MFC after: 1 week
Relnotes: yes

Follow up to r225617. In order to maximize the re-usability of kernel code
in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv().
This fixes a namespace collision with libc symbols.

Submitted by: kmacy
Tested by: make universe

Add a bus method to fetch the VM domain for the given device/bus.

* Add a bus_if.m method - get_domain() - returning the VM domain or
ENOENT if the device isn't in a VM domain;
* Add bus methods to print out the domain of the device if appropriate;
* Add code in srat.c to save the PXM -> VM domain mapping that's done and
expose a function to translate VM domain -> PXM;
* Add ACPI and ACPI PCI methods to check if the bus has a _PXM attribute
and if so map it to the VM domain;
* (.. yes, this works recursively.)
* Have the pci bus glue print out the device VM domain if present.

Note: this is just the plumbing to start enumerating information -
it doesn't at all modify behaviour.

Differential Revision: D906
Reviewed by: jhb
Sponsored by: Norse Corp

Merge ACPICA 20140926.

Add sysctl to track the resource consumption of ACPI interrupts.

Submitted by: gibbs
MFC after: 1 month
Sponsored by: Spectra Logic
MFSpectraBSD: 636827 on 2012/09/28

msi: add Xen MSI implementation

This patch adds support for MSI interrupts when running on Xen. Apart
from adding the Xen related code needed in order to register MSI
interrupts this patch also makes the msi_init function a hook in
init_ops, so different MSI implementations can have different
initialization functions.

Sponsored by: Citrix Systems R&D

xen/interface/physdev.h:
- Add the MAP_PIRQ_TYPE_MULTI_MSI to map multi-vector MSI to the Xen
public interface.

x86/include/init.h:
- Add a hook for setting custom msi_init methods.

amd64/amd64/machdep.c:
i386/i386/machdep.c:
- Set the default msi_init hook to point to the native MSI
initialization method.

x86/xen/pv.c:
- Set the Xen MSI init hook when running as a Xen guest.

x86/x86/local_apic.c:
- Call the msi_init hook instead of directly calling msi_init.

xen/xen_intr.h:
x86/xen/xen_intr.c:
- Introduce support for registering/releasing MSI interrupts with
Xen.
- The MSI interrupts will use the same PIC as the IO APIC interrupts.

xen/xen_msi.h:
x86/xen/xen_msi.c:
- Introduce a Xen MSI implementation.

x86/xen/xen_nexus.c:
- Overwrite the default MSI hooks in the Xen Nexus to use the Xen MSI
implementation.

x86/xen/xen_pci.c:
- Introduce a Xen specific PCI bus that inherits from the ACPI PCI
bus and overwrites the native MSI methods.
- This is needed because when running under Xen the MSI messages used
to configure MSI interrupts on PCI devices are written by Xen
itself.

dev/acpica/acpi_pci.c:
- Lower the quality of the ACPI PCI bus so the newly introduced Xen
PCI bus can take over when needed.

conf/files.i386:
conf/files.amd64:
- Add the newly created files to the build process.

Convert from timeout(9) to callout(9).

Populate the device info string with _PXM (proximity domain) information.

This is primarily useful for debugging right now - it'll show up in
devinfo.

Reviewed by: jhb

Revert unrelated changes accidentally committed in r271192.

Create a separate structure for per-CPU state saved across suspend and
resume that is a superset of a pcb. Move the FPU state out of the pcb and
into this new structure. As part of this, move the FPU resume code on
amd64 into a C function. This allows resumectx() to still operate only on
a pcb and more closely mirrors the i386 code.

Reviewed by: kib (earlier version)

Fix typo when displaying the HPET timer unit number.

xen: add ACPI bus to xen_nexus when running as Dom0

Also disable a couple of ACPI devices that are not usable under Dom0.
To this end a couple of booleans are added that allow disabling ACPI
specific devices.

Sponsored by: Citrix Systems R&D
Reviewed by: jhb

x86/xen/xen_nexus.c:
- Return BUS_PROBE_SPECIFIC in the Xen Nexus attachement routine to
force the usage of the Xen Nexus.
- Attach the ACPI bus when running as Dom0.

dev/acpica/acpi_cpu.c:
dev/acpica/acpi_hpet.c:
dev/acpica/acpi_timer.c
- Add a variable that gates the addition of the devices.

x86/include/init.h:
- Declare variables that control the attachment of ACPI cpu, hpet and
timer devices.

Remove ia64.

This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation

This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h

Discussed at: BSDcan

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

These changes prevent sysctl(8) from returning proper output,
such as:

1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

Remove not needed initialisation code.

Expand r261243 even further and ignore any I/O port resources assigned to
PCI root bridges except for the one known-valid case on x86 where bridges
claim the I/O port registers used for PCI config space access.

Tested by: Hilko Meyer <hilko.meyer@gmx.de>
MFC after: 1 week

Trust the state of a power resource that get from a working _STA method
instead of trying to cache it.

Previously, we only trusted the state if we did not have a cached state.
However, once a state was cached, the _STA method was always ignored.
Specifically, once a power resource had been turned on once (e.g.
during resume), the driver assumed it was always on even if _STA said it
was off and never turned it back on. This prevented the power resource
from being turned back on if a laptop was resumed twice, for example.

To fix, just remove the cached state entirely and always use the results
of _STA. The loops already skip any resources where _STA fails.

Submitted by: trasz (initial patch to invoke _ON)
MFC after: 1 week

Remove duplicate SYSCTL_DECL(_debug_acpi) which was breaking tinderbox

MFC after: 2 weeks
X-MFC-With: r264849

Increase ACPI_MAX_TASKS to be 4 x the number of CPU's as 2 x was still
insufficient on some machines

MFC after: 2 weeks

Exposed debug.acpi.max_tasks and debug.acpi.max_threads via sysctls so their
values can be viewed.

Add a basic set of data points which count the number of sleep entries
that are being done by the OS.

For now this'll match up with the "wakeups"; although I'll dig deeper into
this to see if we can determine which sleep state the CPU managed to get
into. Most things I've seen these days only expose up to C2 or C3 via
ACPI even though the CPU goes all the way down to C6 or C7.

Turns out name was used here when ACPI_DEBUG was defined, so refine my
previous patch.

Remove instances of variables that were set, but never used. gcc 4.9
warns about these by default.

Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge
I/O windows, the default is to preserve the firmware-assigned resources.
PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
defines a PCI_RES_BUS resource type.
- Add a helper API to create top-level PCI bus resource managers for each
PCI domain/segment. Host-PCI bridge drivers use this API to allocate
bus numbers from their associated domain.
- Change the PCI bus and CardBus drivers to allocate a bus resource for
their bus number from the parent PCI bridge device.
- Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
full range of bus numbers from secbus to subbus from their parent bridge.
The drivers also always program their primary bus register. The bridge
drivers also support growing their bus range by extending the bus resource
and updating subbus to match the larger range.
- Add support for managing PCI bus resources to the Host-PCI bridge drivers
used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
- Define a PCI_RES_BUS resource type for amd64 and i386.

Reviewed by: imp
MFC after: 1 month

Some BIOSes incorrectly use standard memory resource ranges to list
the memory ranges that they decode for downstream devices rather than
creating ResourceProducer range resource entries. The result is that
we allocate the full range to the PCI root bridge device causing
allocations in child devices to all fail.

As a workaround, ignore any standard memory resources on a PCI root
bridge device. It is normal for a PCI root bridge to allocate an I/O
resource for the I/O ports used for PCI config access, but I have not
seen any PCI root bridges that legitimately allocate a memory resource.

Reviewed by: jkim
MFC after: 1 week

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.

This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.

A similar change was made in OpenBSD.

Discussed with: -arch, rdivacky
Reviewed by: cperciva

Handle case when ACPI reports HPET device, but does not provide memory
resource for it. In such case take the address range from the HPET table.

This fixes hpet(4) driver attach on Asrock C2750D4I board.

More BUS_PROBE_NOWILDCARD sweeping. Some devices here (if_ath_ahb and siba)
resist easy conversion since they implement a great deal of their attach
logic inside probe(). Some of this could be fixed by moving it to attach(),
but some requires something more subtle than BUS_PROBE_NOWILDCARD.

Import the driver for VT-d DMAR hardware, as specified in the revision
1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture
Specification. The Extended Context and PASIDs from the rev. 2.2 are
not supported, but I am not aware of any released hardware which
implements them. Code does not use queued invalidation, see comments
for the reason, and does not provide interrupt remapping services.

Code implements the management of the guest address space per domain
and allows to establish and tear down arbitrary mappings, but not
partial unmapping. The superpages are created as needed, but not
promoted. Faults are recorded, fault records could be obtained
programmatically, and printed on the console.

Implement the busdma(9) using DMARs. This busdma backend avoids
bouncing and provides security against misbehaving hardware and driver
bad programming, preventing leaks and corruption of the memory by wild
DMA accesses.

By default, the implementation is compiled into amd64 GENERIC kernel
but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is
written to work on i386, but testing there was low priority, and
driver is not enabled in GENERIC. Even with the DMAR turned on,
individual devices could be directed to use the bounce busdma with the
hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If
DMARs are capable of the pass-through translations, it is used,
otherwise, an identity-mapping page table is constructed.

The driver was tested on Xeon 5400/5500 chipset legacy machine,
Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4),
ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also
works with em(4) and igb(4), but there some fixes are needed for
drivers, which are not committed yet. Intel GPUs do not work with
DMAR (yet).

Many thanks to John Baldwin, who explained me the newbus integration;
Peter Holm, who did all testing and helped me to discover and
understand several incredible bugs; and to Jim Harris for the access
to the EDS and BWG and for listening when I have to explain my
findings to somebody.

Sponsored by: The FreeBSD Foundation
MFC after: 1 month

Add support for suspend/resume/migration operations when running as a
Xen PVHVM guest.

Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
Approved by: re (blanket Xen)
MFC after: 2 weeks

sys/amd64/amd64/mp_machdep.c:
sys/i386/i386/mp_machdep.c:
- Make sure that are no MMU related IPIs pending on migration.
- Reset pending IPI_BITMAP on resume.
- Init vcpu_info on resume.

sys/amd64/include/intr_machdep.h:
sys/i386/include/intr_machdep.h:
sys/x86/acpica/acpi_wakeup.c:
sys/x86/x86/intr_machdep.c:
sys/x86/isa/atpic.c:
sys/x86/x86/io_apic.c:
sys/x86/x86/local_apic.c:
- Add a "suspend_cancelled" parameter to pic_resume(). For the
Xen PIC, restoration of interrupt services differs between
the aborted suspend and normal resume cases, so we must provide
this information.

sys/dev/acpica/acpi_timer.c:
sys/dev/xen/timer/timer.c:
sys/timetc.h:
- Don't swap out "suspend safe" timers across a suspend/resume
cycle. This includes the Xen PV and ACPI timers.

sys/dev/xen/control/control.c:
- Perform proper suspend/resume process for PVHVM:
- Suspend all APs before going into suspension, this allows us
to reset the vcpu_info on resume for each AP.
- Reset shared info page and callback on resume.

sys/dev/xen/timer/timer.c:
- Implement suspend/resume support for the PV timer. Since FreeBSD
doesn't perform a per-cpu resume of the timer, we need to call
smp_rendezvous in order to correctly resume the timer on each CPU.

sys/dev/xen/xenpci/xenpci.c:
- Don't reset the PCI interrupt on each suspend/resume.

sys/kern/subr_smp.c:
- When suspending a PVHVM domain make sure there are no MMU IPIs
in-flight, or we will get a lockup on resume due to the fact that
pending event channels are not carried over on migration.
- Implement a generic version of restart_cpus that can be used by
suspended and stopped cpus.

sys/x86/xen/hvm.c:
- Implement resume support for the hypercall page and shared info.
- Clear vcpu_info so it can be reset by APs when resuming from
suspension.

sys/dev/xen/xenpci/xenpci.c:
sys/x86/xen/hvm.c:
sys/x86/xen/xen_intr.c:
- Support UP kernel configurations.

sys/x86/xen/xen_intr.c:
- Properly rebind per-cpus VIRQs and IPIs on resume.

acpi_thermal: Warn about insane _TMP temperature only once

A warning is emitted again if the temperature became briefly valid
meanwhile. This avoids spamming the user when the sensor is broken.

Other values (ie. not _TMP) always raise a warning.

Tidy up global locks for ACPICA. There is no functional change.

Workaround some broken BIOSes that specify edge-sensitive but active-low
settings for ACPI-enumerated serial ports by forcing any IRQs that use
an ISA IRQ value with these settings to active-high instead of active-low.

This is known to occur with the BIOS on an Intel D2500CCE motherboard.

Tested by: Robert Ames <robertames@hotmail.com>, lev
Submitted by: Juergen Weiss weiss at uni-mainz.de (original patch)

Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If
we are probing a PCI-PCI bridge it is because we found one by enumerating
the devices on a PCI bus, so the bridge is definitely present. A few
BIOSes report incorrect status (_STA) for some bridges that claimed they
were not present when in fact they were.

While here, move this check earlier for Host-PCI bridges so attach fails
before doing any work that needs to be torn down.

PR: kern/91594
Tested by: Jack Vogel @ Intel
MFC after: 1 week

Consistently cast ACPICA 64-bit integer types when we print them.

Merge ACPICA 20130517.

- Prefer ACPI_COMPARE_NAME(a, b) macro over strncmp(a, b, ACPI_NAME_SIZE).
- Make sure the predefined name is a string type.
- Return slightly more useful errors.

Fix white spaces.

- Some BIOSes use an Extended IRQ resource descriptor in _PRS for a link
that uses non-ISA IRQs but use a plain IRQ resource in _CRS. However,
a non-ISA IRQ can't fit into a plain IRQ resource. If we encounter a
link like this, build the resource buffer from _PRS instead of _CRS.
- Set the correct size of the end tag in a resource buffer.

Tested by: Benjamin Lee <ben@b1c1l1.com>
MFC after: 2 weeks

Fix a typo in a comment.

Add "else" missed at r248154.

Reduce HPET eventtimer priority on systems with 8 or more cores. Price of
the lock congestion may be too high there (2.5% on 4x4 core AMD Opteron).

MFcalloutng:
Switch eventtimers(9) from using struct bintime to sbintime_t.
Even before this not a single driver really supported full dynamic range of
struct bintime even in theory, not speaking about practical inexpediency.
This change legitimates the status quo and cleans up the code.

MFcalloutng (r247427 by mav):
We don't need any precision here. Let it be fast and dirty shift then
slow and excessively precise 64-bit division.

MFcalloutng:
When CPU becomes idle, cpu_idleclock() calculates time to the next timer
event in order to reprogram hw timer. Return that time in sbintime_t to
the caller and pass it to acpi_cpu_idle(), where it can be used as one
more factor (quite precise) to extimate furter sleep time and choose
optimal sleep state. This is a preparatory change for further callout
improvements will be committed in the next days.

The commmit is not targeted for MFC.

revert accidentally committed unneeded changes from r246250

MFC after: 7 days
X-MFC with: r246250

acpi: clear power button status bit after waking up...

so that it is not confused for a new power off request.

Learned from: Linux and ACPI specification
Tested by: gjb
MFC after: 12 days

acpi: after wakeup from a state > S1 re-enable SCI_EN with a direct write

This hack is picked up from Linux, which claims that it follows
Windows behavior.

PR: amd64/174409
Tested by: Sergey V. Dyatko <sergey.dyatko@gmail.com>,
KAHO Toshikazu <kaho@elam.kais.kyoto-u.ac.jp>,
Slawa Olhovchenkov <slw@zxy.spb.ru>
MFC after: 13 days

Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays

Reviewed by: cognet
Approved by: cognet

Fix two misusages of return_*() macros for ACPICA.

Noticed by: avg

Fix white spaces for style consistency.

Merge ACPICA 20130117.

Remove not very useful printf, that can be too chatty.

ASUS P8Z77-V board reports _AC2, _AC3 and _AC4 setpoints as 0C. With active
cooling already automatically set to _AC2, that still caused driver to print
two useless lines about temperature above _AC3 and _AC4 every ten seconds.
Three setponts of 0C is probably a board bug, but the same spam could happen
also in correct case if system is runnign not with the lowest cooling level.

acpi_cpu_notify: disable acpi_cpu_idle while updating C-state data

... to avoid any races or inconsistencies.
This should fix a regression introduced in r243404.

Also, remove a stale comment that has not been true for quite a while
now.

Pointyhat to: avg
Teested by: trociny, emaste, dumbbell (earlier version)
MFC after: 1 week

acpi_cpu: change cpu_disable_idle to be a per-cpu flag...

and make it safe to manipulate and check the flag

With help from: jhb
Tested by: trociny, emaste, dumbbell
MFC after: 1 week

acpi_cpu: use fixed resource ids for cx state i/o resources

... instead of the ever increasing ones.
Also, do free old resources when allocating new ones when cx states
change.

Tested by: Tom Lislegaard <Tom.Lislegaard@proact.no>
Obtained from: jkim
MFC after: 1 week

Update MAX_TASKS to scale a bit based on MAXCPU

This alleviates issues on newer Sandy/Ivy Bridge gear that seems to require
boatloads more ACPI resources than before.

Reviewed by: avg@
Obtained from: Yahoo! Inc.
MFC after: 2 weeks

Merge ACPICA 20121018.

This isn't functionally identical. In some cases a hint to disable
unit 0 would in fact disable all units.

This reverts r241856

Approved by: cperciva (implicit)

Now that device disabling is generic, remove extraneous code from the
device drivers that used to provide this feature.

Reviewed by: des
Approved by: cperciva
MFC after: 1 week

When checking to see if a video output's _ADR matches an entry in the
parent adapter's _DOD list, only check the low 16 bits of both _ADR and
_DOD. The language in the ACPI spec seems to indicate that the _ADR values
should exactly match the entries in _DOD. However, I assume that the
masking added to _DOD values was added to work around some known busted
machines (the commit history doesn't indicate either way), and the ACPI
spec does require that the low 16 bits are unique for all video outputs,
so only check the low 16 bits should be fine.

This fixes recognition of video outputs that use the new standardized
device ID scheme in ACPI 3.0 that set bit 31 such as certain Dell laptops.

Tested by: Juergen Lock nox jelal kn-bremen de
MFC after: 3 days

acpi_thermal: when _ACx is tripped, all _ALi i>= x should be on

... and not just _ALx as it is now.

MFC after: 20 days

Grab the softc from the ACPI host-pci bridge device instead of from the pci
endpoint device.

Reviewed by: jhb

acpi_cpu: explicitly notify userland about c-state changes

... after they are committed.
A notification is sent per CPU.

Reviewed by: imp
MFC after: 3 weeks

revert r240344: cpu_devices[] is used in other functions and must be kept

Reported by: gjb, glebius
Pointyhat to: avg
MFC after: 1 day
X-MFC note: fake MFC, reminder to never MFC r240344

acpi_cpu: free result of device_get_children

MFC after: 1 week

At least from A70M FCH chipsets AMD started to use their real vendor ID
(1022) in HPET. But according to report they still haven't fixed problem
with level-triggered interrupts.
Make workaround used for earlier chipsets apply to this new ID also.

PR: amd64/171355
MFC after: 3 days

Merge ACPICA 20120816.

Add several performance optimizations to acpi_cpu_idle().

For C1 and C2 states use cpu_ticks() to measure sleep time instead of much
slower ACPI timer. We can't do it for C3, as TSC may stop there. But it is
less important there as wake up latency is high any way.

For C1 and C2 states do not check/clear bus mastering activity status, as
it is important only for C3. As side effect it can make CPU enter C2 instead
of C3 if last BM activity was two sleeps back (unlike one before), but
that may be even good because of collecting more statistics. Premature BM
wakeup from C3, entered because of overestimation, can easily be worse then
entering C2 from both performance and power consumption points of view.

Together on dual Xeon E5645 system on sequential 512 bytes read test this
change makes cpu_idle_acpi() as fast as simplest cpu_idle_hlt() and only
few percents slower then cpu_idle_mwait(), while deeper states are still
actively used during idle periods.

To help with diagnostics, add C-state type into dev.cpu.X.cx_supported.

Sponsored by: iXsystems, Inc.

acpi_cpu: separate a notion of current deepest allowed+available Cx level

... from a user-set persistent limit on the said level.
Allow to set the user-imposed limit below current deepest available level
as the available levels may be dynamically changed by ACPI platform
in both directions.
Allow "Cmax" as an input value for cx_lowest sysctls to mean that there
is not limit and OS can use all available C-states.
Retire global cpu_cx_count as it no longer serves any meaningful
purpose.

Reviewed by: jhb, gianni, sbruno
Tested by: sbruno, Vitaly Magerya <vmagerya@gmail.com>
MFC after: 2 weeks

acpi_cpu: we are able to handle _CST change notifications...

so un-ifdef code that is supposed to tell ACPI platform about that

Tested by: Taku YAMAMOTO <taku@tackymt.homeip.net>
MFC after: 2 weeks

Remove variables which are initialized but never used thereafter
reported by gcc46 warning

Approved by: cperciva
MFC after: 1 week

acpi_cpu_generic_cx_probe: for consistency set cpu_non_c3 here too

although by default only C1 is enabled (cx_lowest=0) and enabling deeper
states goes through acpi_cpu_set_cx_lowest which re-evaluates cpu_non_c3

MFC after: 2 weeks

acpi_cpu_cx_list: there is no need to re-evaluate cpu_non_c3 here

cpu_non_c3 is already evaluated in acpi_cpu_cx_cst and in
acpi_cpu_set_cx_lowest.
Besides acpi_cpu_cx_list is not protected by any locking.

As a result also move setting of cpu_can_deep_sleep to more appropriate
places.

MFC after: 2 weeks

acpi_cpu_cx_cst: consistently use cpu_cx_count during state enumeration

cpu_cx_count is an index into accepted states, while i is an index into
original _CST states

MFC after: 1 week

Revert r238004 as more review has come in and there is now a discussion
on how to best proceed.

Cosmetic display change of Cx states via cx_supported sysctl entries.

Adjust power_profile script to handle the new world order as well.

Some vendors are opting out of a C2 state and only defining C1 & C3. This
leads the acpi_cpu display to indicate that the machine supports C1 & C2
which is caused by the (mis)use of the index of the cx_state array as the
ACPI_STATE_CX value.

e.g. the code was pretending that cx_state[i] would
always convert to i by subtracting 1.

cx_state[2] == ACPI_STATE_C3
cx_state[1] == ACPI_STATE_C2
cx_state[0] == ACPI_STATE_C1

however, on certain machines this would lead to
cx_state[1] == ACPI_STATE_C3
cx_state[0] == ACPI_STATE_C1

This didn't break anything but led to a display of:
* dev.cpu.0.cx_supported: C1/1 C2/96

Instead of
* dev.cpu.0.cx_supported: C1/1 C3/96

MFC after: 2 weeks

Resotre LCD brightness level on resuming.

MFC after: 3 days

Add x86/acpica/acpi_wakeup.c for amd64 and i386. Difference of
suspend/resume procedures are minimized among them.

common:
- Add global cpuset suspended_cpus to indicate APs are suspended/resumed.
- Remove acpi_waketag and acpi_wakemap from acpivar.h (no longer used).
- Add some variables in acpi_wakecode.S in order to minimize the difference
among amd64 and i386.
- Disable load_cr3() because now CR3 is restored in resumectx().

amd64:
- Add suspend/resume related members (such as MSR) in PCB.
- Modify savectx() for above new PCB members.
- Merge acpi_switch.S into cpu_switch.S as resumectx().

i386:
- Merge(and remove) suspendctx() into savectx() in order to match with
amd64 code.

Reviewed by: attilio@, acpi@

Consistently use ACPI_SUCCESS() and ACPI_FAILURE() macros wherever possible.

Execute AcpiLeaveSleepStatePrep() for S1 and reduce code duplication.

MFC after: 3 days

Call AcpiLeaveSleepStatePrep() in interrupt disabled context
(described in ACPICA source code).

- Move intr_disable() and intr_restore() from acpi_wakeup.c to acpi.c
and call AcpiLeaveSleepStatePrep() in interrupt disabled context.
- Add acpi_wakeup_machdep() to execute wakeup MD procedures and call
it twice in interrupt disabled/enabled context (ia64 version is
just dummy).
- Rename wakeup_cpus variable in acpi_sleep_machdep() to suspcpus in
order to be shared by acpi_sleep_machdep() and acpi_wakeup_machdep().
- Move identity mapping related code to acpi_install_wakeup_handler()
(i386 version) for preparation of x86/acpica/acpi_wakeup.c
(MFC candidate).

Reviewed by: jkim@
MFC after: 2 days

Reorder resume procedures.

DEVICE_RESUME() should be done before AcpiLeaveSleepState() because
PCI config space evaluation can be occurred during control method
executions.

This should fix one of the hang up problems on resuming.

MFC after: 3 days

Fix the problem acpi_sleep_force() hang.

Suspending from callout cause the freeze in DEVICE_SUSPEND().
Suspend from acpi_task thread in stead.

MFC after: 3 days

Merge ACPICA 20120518.

Restore Processor object path for verbose boot message.

Rework the previous change to honor MADT processor IDs when probing
processor objects. Instead of forcing the new-bus CPU objects to use
a unit number equal to pc_cpuid, adjust acpi_pcpu_get_id() to honor the
MADT IDs by default. As with the previous change, setting
debug.acpi.cpu_unordered to 1 in the loader will revert to the old
behavior.

Tested by: jimharris
MFC after: 1 month

Ignore the power button press event for resuming rather than starting
shutdown.

MFC after: 2 days

Don't start the sleep state transition procedure while sleep is
disabled or the system is in shutdown procedure.

This should fix the problem which kernel never response to the sleep
button press events after the message `suspend request ignored (not
ready yet)'.

MFC after: 3 days

Centralize declaration of the debug.acpi sysctl node.

Complete commit message for r235024:

Use MADT to match ACPI Processor objects to CPUs. MADT and DSDT/SSDTs may
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems, 'debug.acpi.cpu_unordered' tunable is added.
Set this to a non-zero value to restore the old behavior.
Many thanks to jhb for pointing me to the right direction and the manual
page change.

Reported by: Harris, James R (james dot r dot harris at intel dot com)
Tested by: Harris, James R (james dot r dot harris at intel dot com)
Reviewed by: jhb
MFC after: 1 month

Use MADT to match ACPI Processor objects to CPUs. MADT and DSDT/SSDTs may
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems

Use a more proper fix for enabling HT MSI mapping windows on Host-PCI
bridges. Rather than blindly enabling the windows on all of them, only
enable the window when an MSI interrupt is enabled for a device behind
the bridge, similar to what already happens for HT PCI-PCI bridges.

To implement this, each x86 Host-PCI bridge driver has to be able to
locate it's actual backing device on bus 0. For ACPI, use the _ADR
method to find the slot and function of the device. For the non-ACPI
case, the legacy(4) driver already scans bus 0 looking for Host-PCI
bridge devices. Now it saves the slot and function of each bridge that
it finds as ivars that the Host-PCI bridge driver can then use in its
pcib_map_msi() method.

This fixes machines where non-MSI interrupts were broken by the previous
round of HT MSI changes.

Tested by: bapt
MFC after: 1 week

Restore interrupt state after executing AcpiEnterSleepState().

Add ACPI_LV_REPAIR debug level, available since ACPICA 20091214 (r200553).

MFC after: 3 days

Merge ACPICA 20120320.

ServerWorks HT1000 HPET reported to have problems with IRQs >= 16.
Lower (ISA) IRQs are working, but allowed mask is not set correctly.
Block both by default to allow HP BL465c G6 blade system to boot.

Reported by: Attila Nagy <bra@fsn.hu>
MFC after: 1 week

- Add a bus_dma tag to each PCI bus that is a child of a Host-PCI bridge.
The tag enforces a single restriction that all DMA transactions must not
cross a 4GB boundary. Note that while this restriction technically only
applies to PCI-express, this change applies it to all PCI devices as it
is simpler to implement that way and errs on the side of caution.
- Add a softc structure for PCI bus devices to hold the bus_dma tag and
a new pci_attach_common() routine that performs actions common to the
attach phase of all PCI bus drivers. Right now this only consists of
a bootverbose printf and the allocate of a bus_dma tag if necessary.
- Adjust all PCI bus drivers to allocate a PCI bus softc and to call
pci_attach_common() from their attach routines.

MFC after: 2 weeks

Fix a long-standing bug for AcpiOsGetTimer(). time_t is 32-bit on i386 and
it needs proper casting before multiplication.

MFC after: 3 days

Merge ACPICA 20120215.

De-obfuscate acpi_acquire_global_lock(). It seems the function was directly
translated from i386 assembly version.

Refine r231226. Swap timecounters before suspending any device drivers.

Reset clock after atrtc(4) is properly resumed.

Revert r211288 and move the logic to the acpi_timer itself.

- Give all clocks and timers on acpi0 the equal probing order.
- Increase probing order for ECDT table to match HID-based probing.
- Decrease probing order for HPET table to match HID-based probing.
- Decrease probing order for CPUs and system resources.
- Fix ACPI_DEV_BASE_ORDER to reflect the reality.

Further relax the strictness of enforcing allocations to only come from
decoded ranges. Pass any request for a specific range that fails because
it is not in a decoded range for an ACPI Host-PCI bridge up to the parent
to see if it can still be allocated. This is based on the assumption that
many BIOSes are inconsistent/broken and that settings programmed into BARs
or resources assigned to other built-in components are more trustworthy than
the list of decoded resource ranges in _CRS. This effectively limits the
decoded ranges to only being used for "wildcard" ranges when allocating
fresh resources for a BAR, etc. At some point I would like to only be
this permissive during an early scan of firmware-assigned resources during
boot and to be strict about all later allocations, but that isn't viable
currently.

MFC after: 2 weeks

Prevent a division by zero with some broken batteries

This problem was seen on a laptop with a dead battery.

- There's no need to overwrite the default device method with the default
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.

- be more precise about the unit of measurement

Approved by: jhb
MFC after: 3 days

- be more precise about the unit of measurement

Submitted by: Oliver Pinter <oliver.pntr@gmail.com>
Approved by: jhb
MFC after: 3 days

Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.

The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.

Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.

This means that their use is restricted to a single C file.

If an allocation for a specific resource range fails because it is not in
a decoded range for an ACPI Host-PCI bridge, try to allocate it from the
ACPI system resource range. If that works, permit the resource allocation
regardless.

MFC after: 1 week

Improve the sleep_delay sysctl description by specifying which unit
the number is in.

PR: 159975
Submitted by: gcooper
Approved by: re (kib)
MFC after: 1 week

Always check current HPET counter value after comparator programming to
avoid lost timer interrupts. Previous optimization attempt doing it only
for intervals less then 5000 ticks (~300us) reported to be unreliable by
some people. Probably because of some heavy SMI code on their boards.
Introduce additional safety interval of 128 counter ticks (~9us) between
programmed comparator and counter values to cover different cases of
delayed write found on some chipsets.

Approved by: re (kib)

Allow non-fixed endpoints for a producer address range if the length of
the resource covers the entire range. Some BIOSes appear to mark
endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to
be used in _PRS when OSPM is allowed to allocate a certain chunk of
address space within a larger range, I don't believe it is supposed to be
used for _CRS).

Approved by: re (kib)

Don't ignore negatively decoded address ranges.

Reported by: scottl

Respect the BIOS/firmware's notion of acceptable address ranges for PCI
resource allocation on x86 platforms:
- Add a new helper API that Host-PCI bridge drivers can use to restrict
resource allocation requests to a set of address ranges for different
resource types.
- For the ACPI Host-PCI bridge driver, use Producer address range resources
in _CRS to enumerate valid address ranges for a given Host-PCI bridge.
This can be disabled by including "hostres" in the debug.acpi.disabled
tunable.
- For the MPTable Host-PCI bridge driver, use entries in the extended
MPTable to determine the valid address ranges for a given Host-PCI
bridge. This required adding code to parse extended table entries.

Similar to the new PCI-PCI bridge driver, these changes are only enabled
if the NEW_PCIB kernel option is enabled (which is enabled by default on
amd64 and i386).

Approved by: re (kib)

Remove duplicate header includes

Now that ia64 has been switched to the event timers, remove the
conditional compilation work-arounds.

Typo.

Fix build on ia64 after r223426.

Set negative quality to TSC timecounter when C3 state is enabled for Intel
processors unless the invariant TSC bit of CPUID is set. Intel processors
may stop incrementing TSC when DPSLP# pin is asserted, according to Intel
processor manuals, i. e., TSC timecounter is useless if the processor can
enter deep sleep state (C3/C4). This problem was accidentally uncovered by
r222869, which increased timecounter quality of P-state invariant TSC, e.g.,
for Core2 Duo T5870 (Family 6, Model f) and Atom N270 (Family 6, Model 1c).

Reported by: Fabian Keil (freebsd-listen at fabiankeil dot de)
Ian FREISLICH (ianf at clue dot co dot za)
Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de)
- Core2 Duo T5870 (C3 state available/enabled)
jkim - Xeon X5150 (C3 state unavailable)

Add a helper routine to conditionally modify the start address of a
resource allocation from an x86 Host-PCI bridge driver so that it can be
reused by the ACPI Host-PCI bridge driver (and eventually the MPTable
Host-PCI bridge driver) instead of duplicating the same logic. Note that
this means that hw.acpi.host_mem_start is now replaced with the
hw.pci.host_mem_start tunable that was already used in the non-ACPI case.
This also removes hw.acpi.host_mem_start on ia64 where it was not
applicable (the implementation was very x86-specific).

While here, adjust the logic to apply the new start address on any
"wildcard" allocation even if that allocation comes from a subset of
the allowable address range.

Reviewed by: imp (1)

Fix build with ACPI_DEBUG defined.

Submitted by: jkim
Pointy hat to: jhb

Use AcpiWalkResources() to parse the resource list from _CRS rather than
using a home-rolled loop. While here, add support for 64-bit address
range resources.

Silence on: acpi@ (older version)

Don't create a device_t object or parse current resources (via _CRS) for
ACPI Device() objects that do not have any device IDs available via the
_HID or _CID methods. Without a device ID a device driver cannot attach
to the device anyway. Namespace objects that are devices but not of
type ACPI_TYPE_DEVICE are not affected.

A few BIOSes have also attached a _CRS method to a PCI device to
allocate resources that are not managed via a BAR. With the previous
code those resources are allocated from acpi0 directly which can interfere
with the new PCI-PCI bridge driver (since the PCI device in question may
be behind a bridge and its resources should be allocated from that
bridge's windows instead). The resources were also orphaned and
and would end up associated with some other random device whose device_t
reused the pointer of the original ACPI-enumerated device (after it was
free'd by the ACPI PCI bus driver) in devinfo output which was confusing.
If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus
driver to do that in the future and associate the resources with the
proper device object respecting PCI-PCI bridges, etc.

Note that with this change the ACPI PCI bus driver no longer has to
delete ACPI-enumerated device_t devices that mirror PCI devices since
they should in general not exist. There are rare cases when a BIOS
will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given
a _HID for a system resource device). In that case we leave both the
ACPI and PCI-enumerated device_t objects around just as in the previous
code.

Implement BUS_ADJUST_RESOURCE() for the x86 drivers that sit between the
Host-PCI bridge drivers and nexus.

Merge ACPICA 20110527.

Decrease ACPI-fast timecounter quality to 900 and increase HPET timecounter
quality to 950. HPET on modern platforms usually have better resolution and
lower latency than ACPI timer. Effectively this changes default timecounter
hardware from ACPI-fast to HPET by default when both are available.

Discussed with: avg

Reimplement how PCI-PCI bridges manage their I/O windows. Previously the
driver would verify that requests for child devices were confined to any
existing I/O windows, but the driver relied on the firmware to initialize
the windows and would never grow the windows for new requests. Now the
driver actively manages the I/O windows.

This is implemented by allocating a bus resource for each I/O window from
the parent PCI bus and suballocating that resource to child devices. The
suballocations are managed by creating an rman for each I/O window. The
suballocated resources are mapped by passing the bus_activate_resource()
call up to the parent PCI bus. Windows are grown when needed by using
bus_adjust_resource() to adjust the resource allocated from the parent PCI
bus. If the adjust request succeeds, the window is adjusted and the
suballocation request for the child device is retried.

When growing a window, the rman_first_free_region() and
rman_last_free_region() routines are used to determine if the front or
end of the existing I/O window is free. From using that, the smallest
ranges that need to be added to either the front or back of the window
are computed. The driver will first try to grow the window in whichever
direction requires the smallest growth first followed by the other
direction if that fails.

Subtractive bridges will first attempt to satisfy requests for child
resources from I/O windows (including attempts to grow the windows). If
that fails, the request is passed up to the parent PCI bus directly
however.

The PCI-PCI bridge driver will try to use firmware-assigned ranges for
child BARs first and only allocate a "fresh" range if that specific range
cannot be accommodated in the I/O window. This allows systems where the
firmware assigns resources during boot but later wipes the I/O windows
(some ACPI BIOSen are known to do this) to "rediscover" the original I/O
window ranges.

The ACPI Host-PCI bridge driver has been adjusted to correctly honor
hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge
makes a wildcard request for an I/O window range.

The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option
is enabled. This is a transition aide to allow platforms that do not
yet support bus_activate_resource() and bus_adjust_resource() in their
Host-PCI bridge drivers (and possibly other drivers as needed) to use the
old driver for now. Once all platforms support the new driver, the
kernel option and old driver will be removed.

PR: kern/143874 kern/149306
Tested by: mav

The ACPI Host-PCI bridge driver actually supports multiple domains via
the optional _SEG function. Return that value (ap->segment) rather than
0 for the pcib domain ivar.

Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,
generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge
drivers.

Correctly output the entire array for hw.acpi.thermal._ACx.

Reported by: Taku YAMAMOTO < taku AT tackymt DOT homeip DOT net >
Tested by: Nick Ulen < uncle AT wolfman DOT devio DOT us >

Do not assume PM timer GAS type is I/O or memory. It may be an unsupported
type, i. e., a broken table. Also, do not hardcode ACPI timer frequency in
device description.

Fix a few acpi sysctls that want "IK" formatting to specify CTLTYPE_INT.
This got broken after r217586.

Pointy hat: to me
Tested by: David Wolfskill < davit AT catwhisker DOT org >

Add event handlers for (ACPI) suspend/resume events. Suspend event handlers
are invoked right before device drivers go into sleep state and resume event
handlers are invoked right after all device drivers are waken up.

Add some tunable descriptions about x86 timers.

Requested by: arundel

Use atomic load & store for TSC frequency. It may be overkill for amd64 but
safer for i386 because it can be easily over 4 GHz now. More worse, it can
be easily changed by user with 'machdep.tsc_freq' tunable (directly) or
cpufreq(4) (indirectly). Note it is intentionally not used in performance
critical paths to avoid performance regression (but we should, in theory).
Alternatively, we may add "virtual TSC" with lower frequency if maximum
frequency overflows 32 bits (and ignore possible incoherency as we do now).

Lower the bar for ACPI-fast on real machines slightly. Empirical evidences
show that there are perfectly working PM timers with occasional "hiccups",
probably because of an SMI. Now we ignore the maximum if it happens once in
the test loop and the width is small enough. Also, relax normal width a bit
to count in a boundary case.

Move a trivial acpi_TimerDelta() to acpivar.h to make it inlineable.

Always check the current minimum value to make the test more predictable.
Use INT32_MAX instead of an arbitrary big number for the initial minimum.

Fix bogus logic to calculate delta between two values from ACPI timers.

Lower the bar for ACPI-fast on virtual machines. The current logic depends
on the fact that real hardware has almost fixed cost to read the ACPI timer.
It is virtually always false for hardware emulation and it makes no sense to
read it multiple times, which is already quite expensive for full emulation.

Add inline to acpi_timer_read() to reduce unnecessary jumps and calls.

Add more definitions for vendor-specific CPU capability bits to the last
revision, which is renamed to "Intel Processor Vendor-Specific ACPI".

Rework r218685. Copy just enough data for the resource type.

Reviewed by: jhb, mdf

Prevent reading from the ACPI_RESOURCE past its actual end. For
paranoia limit to the size of the ACPI_RESOURCE as well.

Reviewd by: jhb (in spirit)
MFC after: 1 week

Use the preload_fetch_addr() and preload_fetch_size() convenience
functions to obtain the address and size of the overriding DSDT.

Sponsored by: Juniper Networks.

Fix a few more SYSCTL_PROC() that were missing a CTLFLAG type specifier.

Remove bogus check. pcib_get_bus() (like other BUS_ACCESSOR() methods)
doesn't "fail", it may merely return garbage if it is not a valid ivar
for a given device. Our parent device must be a 'pcib' device, so we
can just assume it implements pcib IVARs, and all pcib devices have a
bus number.

Submitted by: clang via rdivacky

Work around a witness(4) panic introduced in r217238.

Reported by: jh

Fix a witness(4) warning introduced in r217238.

Remove impossible error conditions.

Add forgotten free(9) in the previous commit for an error case.

Allow AcpiOsInstallInterruptHandler() and AcpiOsRemoveInterruptHandler() to
install or remove non-SCI interrupt handlers per ACPI Component Architecture
User Guide and Programmer Reference. ACPICA may install such interrupt
handler when a GPE block device is found, for example. Add a wrapper for
ACPI_OSD_HANDLER, convert its return values to ours, and make it a filter.
Prefer KASSERT(9) over panic(9) as we have never seen those in reality.
Clean up some style(9) nits and add my copyright.

Prefer KASSERT(9) over panic(9) as it was never seen in reality.

Clarify the previous commit. AcpiFinishGpe() will not clear GPE for us
because we set it to edge-trigger.

Clear GPE from a query handler if the task was deferred.

Fix parameters for wakeup(9) and tsleep(9).

MFC after: 3 days

Don't try to reserve a resource that is already allocated. If the ECDT
table is present, then the acpi_ec(4) driver will allocate its resources
from nexus0 before the acpi0 device reserves resources for child devices.

Reviewed by: jkim

Use resource_list_reserve() to reserve I/O port and memory resources for
ACPI devices even if they are not allocated by a device driver since the
resources are in use and should not be allocated to another device.

small cleanup of acpi battery status setting and checking

This is based on the patch submitted by Yuri Skripachov.
Overview of the changes:
- clarify double-use of some ACPI_BATT_STAT_* definitions
- clean up undefined/extended status bits returned by _BST
- warn about charging+discharging bits being set at the same time

PR: kern/124744
Submitted by: Yuri Skripachov <y.skripachov@gmail.com>
Tested by: Yuri Skripachov <y.skripachov@gmail.com>
MFC after: 2 weeks

Small style fixes:
- Avoid side-effect assignments in if statements when possible.
- Don't use ! to check for NULL pointers, explicitly check against NULL.
- Explicitly check error return values against 0.
- Don't use INTR_MPSAFE for interrupt handlers with only filters as it is
meaningless.
- Remove unneeded function casts.

Spelling fix.

Merge ACPICA 20101209.

Stop lying about supporting cpu_est_clockrate() when TSC is invariant. This
function always returned the nominal frequency instead of current frequency
because we use RDTSC instruction to calculate difference in CPU ticks, which
is supposedly constant for the case. Now we support cpu_get_nominal_mhz()
for the case, instead. Note it should be just enough for most usage cases
because cpu_est_clockrate() is often times abused to find maximum frequency
of the processor.

Use proper resource ID's for HPET IRQ resources. This mostly consists of
looking to see if there is an existing IRQ resource for a given IRQ
provided by the BIOS and using that RID if so. Otherwise, allocate a new
RID for the new IRQ.

Reviewed by: mav (a while ago)

Various small typos and grammar nits in comments.

Create C1 state when _CST is valid but _CST does not have one. Some BIOSes
do not report C1 state in _CST object, probably because it is a mandatory
state with or without existence of the optional _CST.

Reviewed by: avg

Make APM emulation look more closer to its origin. Use device_get_softc(9)
instead of hardcoding acpi(4) unit number as we have device_t for it.

Refactor acpi_machdep.c for amd64 and i386, move APM emulation into a new
file acpi_apm.c, and place it on sys/x86/acpica.

Consistently use padding `_' in the comment.

Add a forgotten change from the previous commit.

Fix a use-after-free bug for extended IRQ resource[1]. When _PRS buffer is
copied as a template for _SRS, a string pointer for descriptor name is also
copied and it becomes stale as soon as it gets de-allocated[2]. Now _CRS is
used as a template for _SRS as ACPI specification suggests if it is usable.
The template from _PRS is still utilized but only when _CRS is not available
or broken. To avoid use-after-free the problem in this case, however, only
mandatory fields are copied, optional data is removed, and structure length
is adjusted accordingly.

Reported by: hps[1]
Analyzed by: avg[2]
Tested by: hps

Adjust a comment to clarify why \_SB_ and \_TZ_ are defined as device type
in ACPICA. Reshuffle the code a bit to make sure this kludge only applies
to these two specical cases and to make it cleaner.

Add two new loader tunables 'hw.acpi.install_interface' and
'hw.acpi.remove_interface'. hw.acpi.install_interface lets you install new
interfaces. Conversely, hw.acpi.remove_interface lets you remove OS
interfaces from the pre-defined list in ACPICA. For example,

hw.acpi.install_interface="FreeBSD"

lets _OSI("FreeBSD") method to return 0xffffffff (or success) and

hw.acpi.remove_interface="Windows 2009"

lets _OSI("Windows 2009") method to return zero (or failure). Both are
comma-separated lists and leading white spaces are ignored. For example,
the following examples are valid:

hw.acpi.install_interface="Linux, FreeBSD"
hw.acpi.remove_interface="Windows 2006, Windows 2006.1"

Introduce a new tunable 'hw.pci.do_power_suspend'. This tunable lets you
avoid PCI power state transition from D0 to D3 for suspending case. Default
is 1 or enabled.

Remove undocumented and stale debug.acpi.do_powerstate tunable. It was
added with hw.pci.do_powerstate but the PCI version was splitted into two
separate tunables later and now this is completely stale. To make it worse,
PCI devices enumerated in ACPI tree ignore this tunable as it is handled by
a function in acpi_pci.c instead.

Remove PCI_SET_POWERSTATE method from acpi.c and eradicate all PCI-specific
knowledges from the file. All PCI devices enumerated in ACPI tree must use
correct one from acpi_pci.c any way. Reduce duplicate codes as we did for
pci.c in r213905. Do not return ESRCH from PCIB_POWER_FOR_SLEEP method.
When the method is not found, just return zero without modifying the given
default value as it is completely optional. As a side effect, the return
state must not be NULL. Note there is actually no functional change by
removing ESRCH because acpi_pcib_power_for_sleep() always returns zero.
Adjust debugging messages and add new ones under bootverbose to help
debugging device power state related issues.

Reviewed by: jhb, imp (earlier versions)

Make any PCI devices enumerated in ACPI tree honor do_power_resume as well.

Clean up unused headers.

Remove acpi_bus_number() completely. It had to be removed in r212761.

Pointed out by: jhb

Mark acpi_bus_number() as __unused. This allows clang to this file
without any warnings.

Use AcpiReset() from ACPICA instead of rolling our own, which is actually
incomplete. If FADT says the register is available, enable the capability
by default. Remove the previous default value from acpi(4).

acpi_ec: changes in communication with hardware

Short description of the changes:
- attempt to retry some commands for which it is possible (read, query)
- always make a short sleep before checking EC status in polled mode
- periodically poll EC status in interrupt mode
- change logic for detecting broken interrupt delivery and falling back
to polled mode
- check that EC is ready for input before starting a new command, wait
if necessary

This commit is based on the original patch by David Naylor.

PR: kern/150517
Submitted by: David Naylor <naylor.b.david@gmail.com>
Reviewed by: jkim
MFC after: 3 weeks

Do not use regular interrupts on NVidia HPETs. NVidia MCP5x chipsets have
number of unexplained interrupt problems. For some reason, using HPET
interrupts there breaks HDA sound. Legacy route mode interrupts reported
to work fine there.

Quick fix for unmotivated C2 state usage during boot, introduced at r212541.
That caused LAPIC timer failure and huge delays during boot on some systems.

acpi_attach: do not explicitly install default handlers for default
address spaces

There has been no need to do that starting with ACPICA 20040427 as
AcpiEnableSubsystem() installs the handlers automatically.
Additionaly, explicitly calling AcpiInstallAddressSpaceHandler before
AcpiEnableSubsystem is not supported by ACPICA and leads to too early
execution of _REG methods in some DSDTs, which may result in problems.

Big thanks to Robert Moore of ACPICA/Intel for explaining the above.

Reported by: Daniel Bilik <daniel.bilik@neosystem.cz>
Tested by: Daniel Bilik <daniel.bilik@neosystem.cz>
Reviewed by: jkim
Suggested by: "Moore, Robert" <robert.moore@intel.com>
MFC after: 1 week

Merge ACPICA 20100915.

acpi_cpu: do not apply P_LVLx_LAT rules to latencies returned by _CST

ACPI specification sates that if P_LVL2_LAT > 100, then a system doesn't
support C2; if P_LVL3_LAT > 1000, then C3 is not supported.
But there are no such rules for Cx state data returned by _CST. If a
state is not supported it should not be included into the return
package. In other words, any latency value returned by _CST is valid,
it's up to the OS and/or user to decide whether to use it.

Submitted by: nork
Suggested by: mav
MFC after: 1 week

Refactor timer management code with priority to one-shot operation mode.
The main goal of this is to generate timer interrupts only when there is
some work to do. When CPU is busy interrupts are generating at full rate
of hz + stathz to fullfill scheduler and timekeeping requirements. But
when CPU is idle, only minimum set of interrupts (down to 8 interrupts per
second per CPU now), needed to handle scheduled callouts is executed.
This allows significantly increase idle CPU sleep time, increasing effect
of static power-saving technologies. Also it should reduce host CPU load
on virtualized systems, when guest system is idle.

There is set of tunables, also available as writable sysctls, allowing to
control wanted event timer subsystem behavior:
kern.eventtimer.timer - allows to choose event timer hardware to use.
On x86 there is up to 4 different kinds of timers. Depending on whether
chosen timer is per-CPU, behavior of other options slightly differs.
kern.eventtimer.periodic - allows to choose periodic and one-shot
operation mode. In periodic mode, current timer hardware taken as the only
source of time for time events. This mode is quite alike to previous kernel
behavior. One-shot mode instead uses currently selected time counter
hardware to schedule all needed events one by one and program timer to
generate interrupt exactly in specified time. Default value depends of
chosen timer capabilities, but one-shot mode is preferred, until other is
forced by user or hardware.
kern.eventtimer.singlemul - in periodic mode specifies how much times
higher timer frequency should be, to not strictly alias hardclock() and
statclock() events. Default values are 2 and 4, but could be reduced to 1
if extra interrupts are unwanted.
kern.eventtimer.idletick - makes each CPU to receive every timer interrupt
independently of whether they busy or not. By default this options is
disabled. If chosen timer is per-CPU and runs in periodic mode, this option
has no effect - all interrupts are generating.

As soon as this patch modifies cpu_idle() on some platforms, I have also
refactored one on x86. Now it makes use of MONITOR/MWAIT instrunctions
(if supported) under high sleep/wakeup rate, as fast alternative to other
methods. It allows SMP scheduler to wake up sleeping CPUs much faster
without using IPI, significantly increasing performance on some highly
task-switching loads.

Tested by: many (on i386, amd64, sparc64 and powerc)
H/W donated by: Gheorghe Ardelean
Sponsored by: iXsystems, Inc.

Add tunable 'hint.hpet.X.per_cpu' to specify how much per-CPU timers driver
should provide if there is sufficient hardware. Default is 1.

Instead of storing last event timestamp, store the next event timestamp.
It corrects handling of the first event offset in emulated periodic mode.

bus_add_child: change type of order parameter to u_int

This reflects actual type used to store and compare child device orders.
Change is mostly done via a Coccinelle (soon to be devel/coccinelle)
semantic patch.
Verified by LINT+modules kernel builds.

Followup to: r212213
MFC after: 10 days

During SMP startup there is time window, when SMP started, but interrupts
are still bound to BSP. It confuses timer management logic in per-CPU mode
and may cause timer not being reloaded. Check such cases on interrupt
arival and reload timer to give system some more time to manage proper
binding.

Several improvements to HPET driver:
- Add special check for case when time expires before being programmed.
This fixes interrupt loss and respectively timer death on attempt to
program very short interval. Increase minimal supported period to more
realistic value.
- Add support for hint.hpet.X.allowed_irqs tunable, allowing manually
specify which interrupts driver allowed to use. Unluckily, many BIOSes
program wrong allowed interrupts mask, so driver tries to stay on safe
side by not using unshareable ISA IRQs. This option gives control over
this limitation, allowing more per-CPU timers to be provided, when FSB
interrupts are not supported. Value of this tunable is bitmask.
- Do not use regular interrupts on virtual machines. QEMU and VirtualBox
do not support them properly, that may cause problems. Stay safe by default.
Same time both QEMU and VirtualBox work fine in legacy_route mode.
VirtualBox also works fine if manually specify allowed ISA IRQs with above.

acpi: update stale comments about order of cpu devices probing

These comments should have been updated in r203776 when the order was
changed.

Pointyhat to: avg
MFC after: 3 days

Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This
method is used by the PCI bus driver to query the power management system
to determine the proper device state to be used for a device during suspend
and resume. For the ACPI PCI bridge drivers this calls
acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from
the PCI and PCI-PCI bridge drivers.

Reviewed by: jkim

When EC burst mode is activated and multiple bytes are accessed, do not
disable and enable repeatedly, just do it once per call. It also reduces
code duplication. Check all parameters early and fail immediately.

Merge ACPICA 20100806.

- Retire acpi_pcib_resume(). It is has just been an alias for
bus_generic_resume() since the pci_link(4) driver was added.
- Change the ACPI PCI-PCI bridge driver to inherit most of its methods
from the generic PCI-PCI bridge driver. In particular, this will now
restore PCI config registers for ACPI PCI-PCI bridges.

Tested by: Oleg Sharoyko osharoiko of gmail

Fix several un-/signedness bugs of r210290 and r210293. Add one more check.

Extend timer driver API to report also minimal and maximal supported period
lengths. Make MI wrapper code to validate periods in request. Make kernel
clock management code to honor these hardware limitations while choosing hz,
stathz and profhz values.

Simplify AcpiOsReadPort() and AcpiOsWritePort() with iodev_read_*() and
iodev_write_*(). This removes unnecessary uses of temporary macros as well.
There is no functional change after this (verified with md5(1) on amd64).

Use pmap_mapdev()/pmap_unmapdev() to map device memory instead of using
AcpiOsMapMemory()/AcpiOsUnmapMemory() (-> pmap_mapbios()/pmap_unmapbios())
for AcpiOsReadMemory() and AcpiOsWriteMemory(). Although they do not sound
too obvious, these functions are exclusively used to access memory mapped
IO in ACPICA.

If there is any pending sleep request, disallow entering S5 state.
Otherwise, bad things may happen. ;-)

- AcpiOsReadPciConfiguration() needs similar fixes as r209965 and r210129.
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 64-bit return value even if the bit width of
the location is less than 64.
- Return error when 64-bit access is requested as we do not support 64-bit
PCI register access (yet). XXX We may have to split it up into two 32-bit
accesses if it is really required.

- AcpiOsReadMemory() needs similar fixes as r209965. [1]
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.
- Remove 64-bit read/write from AcpiOsReadMemory() and AcpiOsWriteMemory().
These functions do not support 64-bit access (yet). Clean up style nits
and unnecessary bit masking while I am here.

Reported by: Liu, Jinsong (jinsong dot liu at intel dot com) via
Lin Ming (ming dot m dot lin at intel dot com) [1]

Make SMP code path conditional at run-time.

Rise knowledge about curthread->td_intr_frame by one step. Make timer
callback argument really opaque. Not repeat interrupt handler's problem
in case somebody will ever need to have both argument and frame.

Fix white spaces.

According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.

Fix mis-merges in the previous commit.

Merge ACPICA 20100702.

Add "legacy route" support to HPET driver. When enabled, this mode makes
HPET to steal IRQ0 from i8254 and IRQ8 from RTC timers. It can be suitable
for HPETs without FSB interrupts support, as it gives them two unshared
IRQs. It allows them to provide one per-CPU event timer on dual-CPU system,
that should be suitable for further tickless kernels.

To enable it, such lines may be added to /boot/loader.conf:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.0.legacy_route=1

Do not set level-triggered interrupt mode if we are not going to use it.
This fixes QEMU crash due to unsupported level-triggered HPET interrupts.

Reported by: kib@

Fix ia64 build broken by r209371.
ia64, same as amd64 has ACPI and always has APIC.

Submitted by: jhb@

Implement new event timers infrastructure. It provides unified APIs for
writing event timer drivers, for choosing best possible drivers by machine
independent code and for operating them to supply kernel with hardclock(),
statclock() and profclock() events in unified fashion on various hardware.

Infrastructure provides support for both per-CPU (independent for every CPU
core) and global timers in periodic and one-shot modes. MI management code
at this moment uses only periodic mode, but one-shot mode use planned for
later, as part of tickless kernel project.

For this moment infrastructure used on i386 and amd64 architectures. Other
archs are welcome to follow, while their current operation should not be
affected.

This patch updates existing drivers (i8254, RTC and LAPIC) for the new
order, and adds event timers support into the HPET driver. These drivers
have different capabilities:
LAPIC - per-CPU timer, supports periodic and one-shot operation, may
freeze in C3 state, calibrated on first use, so may be not exactly precise.
HPET - depending on hardware can work as per-CPU or global, supports
periodic and one-shot operation, usually provides several event timers.
i8254 - global, limited to periodic mode, because same hardware used also
as time counter.
RTC - global, supports only periodic mode, set of frequencies in Hz
limited by powers of 2.

Depending on hardware capabilities, drivers preferred in following orders,
either LAPIC, HPETs, i8254, RTC or HPETs, LAPIC, i8254, RTC.
User may explicitly specify wanted timers via loader tunables or sysctls:
kern.eventtimer.timer1 and kern.eventtimer.timer2.
If requested driver is unavailable or unoperational, system will try to
replace it. If no more timers available or "NONE" specified for second,
system will operate using only one timer, multiplying it's frequency by few
times and uing respective dividers to honor hz, stathz and profhz values,
set during initial setup.

Oops! Add " / hz" missed in r209328. Assume interrupt rate hz/2, not 1/2.

While we indeed can't precisely measure time spent in C1, we can consider
measured interval as upper bound. It should be more precise then just
assuming hz/2. For idle CPU it should be quite precise, for busy - not
worse then before.

When updating individual CPU's lowest Cx state to use, never set it to a
state lower than the lowest one supported by the current CPU. This closes
some races with changes to the hw.acpi.cpu_cx_lowest sysctl while Cx
states for individual CPUs were changing (e.g. unplugging the AC adapter
of a laptop) that could result in panics.

Submitted by: Giovanni Trematerra
Tested by: David Demelier demelier dot david of gmail
MFC after: 3 days

Simplify a function for getting brightness levels.

Remove unused assignment.

Found by: clang static analyzer
Found by: Coverity Prevent[tm] (CID 4537, 4538, 4539)

fix a few cases where a string is passed via format argument instead of
via %s

Most of the cases looked harmless, but this is done for the sake of
correctness. In one case it even allowed to drop an intermediate buffer.

Found by: clang
MFC after: 2 week

Update several places that iterate over CPUs to use CPU_FOREACH().

The lock associated with the /dev/apm knote is already held, so use
KNOTE_LOCKED() instead of KNOTE_UNLOCKED().

Reported by: mav
MFC after: 3 days

Remove unnecessary pointer type castings, shift operations and dead code.

Oops, HPET ID optionally stored in _UID, not in _ADR.

Make table-based HPET identification more clever. Before creating fake
device, make sure we have no real HPET device entry with same ID.
As side effect, it potentially allows several HPETs to be attached.
Use first of them for timecounting, rest (if ever present) could later
be used as event sources.

Merge ACPICA 20100428.

Merge ACPICA 20100331 (and four additional upstream patches).

Fix white spaces.

- Allow users to enable dumping Debug objects without ACPI debugger.
Setting the new sysctl MIB "debug.acpi.enable_debug_objects" to a non-zero
value enables us to print Debug object when something is written to it.
- Allow users to disable interpreter slack mode. Setting the new tunable
"debug.acpi.interpreter_slack" to zero disables some workarounds for common
BIOS mistakes and enables strict ACPI implementations by the specification.

Merge ACPICA 20100304.

Rename some macros to clarify their intentions and fix style nits.

Add support for `cycle' and `zero' events for LCD brightness control.

Submitted by: Daniel Walter (d dot walter at 0x90 dot at) (intial version)

Make sanity check slightly more useful and tweak an error message.

Implement LCD brightness control notify handler.

Submitted by: Daniel Walter(d dot walter at 0x90 dot at) (intial version)

acpi: drop the second bus_generic_attach pass

It is belived that that pass s not needed anymore.
Specifically it is not required now for the reasons that were given
in the removed comment.

Discussed with: jhb
MFC after: 4 weeks

acpi cpu: probe+attach before all other enumerated children on acpi bus

Some current systems dynamically load SSDT(s) when _PDC/_OSC method
of Processor is evaluated. Other devices in ACPI namespace may access
objects defined in the dynamic SSDT. Drivers for such devices might
have to have a rather high priority, because of other dependencies.
Good example is acpi_ec driver for EC.
Thus we attach to Processors as early as possible to load the SSDTs
before any other drivers may try to evaluate control methods.
It also seems to be a natural order for a processor in a device
hierarchy.

On the other hand, some child devices on acpi cpu bus need to access
other system resources like PCI configuration space of chipset devices,
so they need to be probed and attached rather late.
For this reason we probe and attach the cpu bus at
SI_SUB_CONFIGURE:SI_ORDER_MIDDLE SYSINIT level.
In the future this could be done more elegantly via multipass.

Please note that acpi drivers that might access ACPI namespace from
device_identify will do that before _PDC/_OSC of Processors are evaluated.

Legacy cpu driver is not affected by this change.

PR: kern/142561 (in part)
Reviewed by: jhb
Silence from: acpi@
MFC after: 5 weeks