remove prototypes with no matching function and externs with no var

Add arm64 lid_action sysctl for Apple Silicon laptops.

ok kettenis@

Split out the code that collects data from acpiac(4), acpibat(4) and
acpisbs(4) for apm(4) and hook it up to the arm64 version of apm(4) on
systems with ACPI.

ok kn@

*** empty log message ***

oops, a typo snuck in

The suspend/resume code is a sticky mess of MI, MD, and ACPI sequencing.
This splits out the MI sequencing, backing it with per-architecture helper
functions. Further steps will be neccesary because

The suspend/resume code is a sticky mess of MI, MD, and ACPI sequencing.
This splits out the MI sequencing, backing it with per-architecture helper
functions. Further steps will be neccesary because ACPI and MD are too
tightly coupled, but soon we'll be able to use this code for more architectures
(which depends on figuring out the lowest-level cpu sleeping method)
ok kettenis

show more ...

Constify struct cfattach.

ok visa@ a long time ago, ok patrick@

Rename some MD structs by giving them an architecture-neutral name in
preparation for sharing PCIe host bridge drivers between arm64 and riscv64.

ok mpi@, mlarkin@, patrick@

acpi_intr_disestablish() should free its own cookie.

ok kettenis@

Add code to acpiiort(4) to look up named components in the IORT and
map them. This makes ACPI's call to acpi_iommu_device_map() do work
through acpiiort(4).

ok kettenis@

Add acpi_iommu_device_map(), which replaces the DMA tag with one that
is blessed with IOMMU magic, if available. This is mainly for arm64,
since on amd64 and i386 the IOMMU only captures PCIe device

Add acpi_iommu_device_map(), which replaces the DMA tag with one that
is blessed with IOMMU magic, if available. This is mainly for arm64,
since on amd64 and i386 the IOMMU only captures PCIe devices, as far
as I know, which uses the pci_probe_device_hook(). This though is for
non-PCI devices attached through ACPI.

ok kettenis@

show more ...

Apply r1.86 of amd64 acpi_machdep.c to arm64 and i386, converting a few
uvm_km_valloc(9) to km_alloc(9).

tested on arm64 by bluhm@, i386 by me
ok kettenis@

Implement acpi_intr_disestablish() for arm64.

ok patrick@

Add support for edge-triggered interrupts in acpi_intr_establish(). So
far we have always passed level-high, but now we can check the irq flags
and pass the device-tree compatible values. This make

Add support for edge-triggered interrupts in acpi_intr_establish(). So
far we have always passed level-high, but now we can check the irq flags
and pass the device-tree compatible values. This makes my powerbutton
not flood the system with interrupts after a single press.

ok kettenis@

show more ...

Re-work intr_barrier(9) on arm64 to remove layer violation. So far we
have stored the struct cpu_info * in the wrapper around the interrupt
handler cookie, but since we can have a few layers inbetwe

Re-work intr_barrier(9) on arm64 to remove layer violation. So far we
have stored the struct cpu_info * in the wrapper around the interrupt
handler cookie, but since we can have a few layers inbetween, this does
not seem very nice. Instead have each and every interrupt controller
provide a barrier function. This means that intr_barrier(9) will in the
end be executed by the interrupt controller that actually wired the pin
to a core. And that's the only place where the information is stored.

ok kettenis@

show more ...

Store struct cpu_info * in arm64's interrupt wrap. intr_barrier() can
already assume every cookie is wrapped and simply retrieve the pointer
from it. It's a bit of a layer violation though, since o

Store struct cpu_info * in arm64's interrupt wrap. intr_barrier() can
already assume every cookie is wrapped and simply retrieve the pointer
from it. It's a bit of a layer violation though, since only the intc
should actually store that kind of information. This is good enough for
now, but I'm already cooking up a diff to resolve this.

ok dlg@

show more ...

To be able to have intr_barrier() on arm64, we need to be able to
somehow gain access to the struct cpu_info * used to establish the
interrupt. One possibility is to store the pointer in the cookie

To be able to have intr_barrier() on arm64, we need to be able to
somehow gain access to the struct cpu_info * used to establish the
interrupt. One possibility is to store the pointer in the cookie
returned by the establish methods. A better way would be to ask
the interrupt controller directly to do barrier.

This means that all external facing interrupt establish functions
need to wrap the cookie in a common way. We already do this for
FDT-based interrupts. Also most PCI controllers already return
the cookie from the FDT API, which is already wrapped. So arm64's
acpi_intr_establish() and acpipci(4) now need to explicitly wrap
it, since they call ic->ic_establish directly, which does not wrap.

ok dlg@

show more ...

Extend the interrupt API on arm64 and armv7 to be able to pass around
a struct cpu_info *. From a driver point of view the fdt_intr_establish_*
API now also exist same functions with a *_cpu suffix.

Extend the interrupt API on arm64 and armv7 to be able to pass around
a struct cpu_info *. From a driver point of view the fdt_intr_establish_*
API now also exist same functions with a *_cpu suffix. Internally the
"old" functions now call their *_cpu counterparts, passing NULL as ci.
NULL will be interpreted as primary CPU in the interrupt controller code.

The internal framework for interrupt controllers has been changed so that
the establish methods provided by an interrupt controller function always
takes a struct cpu_info *.

Some drivers, like imxgpio(4) and rkgpio(4), only have a single interrupt
line for multiple pins. On those we simply disallow trying to establish
an interrupt on a non-primary CPU, returning NULL.

Since we do not have MP yet on armv7, all armv7 interrupt controllers do
return NULL if an attempt is made to establish an interrupt on a different
CPU. That said, so far there's no way this can happen. If we ever gain
MP support, this is a reminder that the interrupt controller drivers have
to be adjusted.

Prompted by dlg@
ok kettenis@

show more ...

Add support for the _CCA method. This method indicates whether DMA is
cache-coherent or not. To implement this, acpi(4) gets two bus_dma tags
and passes the appropriate one when attaching devices b

Add support for the _CCA method. This method indicates whether DMA is
cache-coherent or not. To implement this, acpi(4) gets two bus_dma tags
and passes the appropriate one when attaching devices based on _CCA.
On i386/amd64, where for all practical purpose DMA is always cache-coherent,
the two tags are the same. But on arm64 they are distinct.

ok patrick@

show more ...

On amd64 the bootup and resume paths for SP/BP/SP were not performing
msr/pat, clock-startup, firmware upgrade, fpu initialization, and cpu
soft-state initialization in the same order. That kind of

On amd64 the bootup and resume paths for SP/BP/SP were not performing
msr/pat, clock-startup, firmware upgrade, fpu initialization, and cpu
soft-state initialization in the same order. That kind of chaos is
crazy and fragile. Improve the acpi resume call sequence and unify order
of the operations.

show more ...

Add a pwraction sysctl that controls what the power button does on acpi.
By default, nothing changes -- shutdown is initiated. But allows turning
power button into a sleep button if desired.
(grudgin

Add a pwraction sysctl that controls what the power button does on acpi.
By default, nothing changes -- shutdown is initiated. But allows turning
power button into a sleep button if desired.
(grudging) ok from a few parties

show more ...

Hook up acpi(4) on arm64. Various bits of driver glue are still missing
but this is enough to boot multi-user on the mcbin with suitable firmware.

ok mlarkin@