| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This creates separate domains for each PCI device and can provide protection
against invalid memory access. Needed for Passthrough PCI from vmd.
ok deraadt@, kettenis@
: ----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cpu is specified by a struct cpu_info *, which should generally
come from an intrmap.
this is adapted from a diff that patrick@ sent round a few years
ago for a pci_intr_map_msix_cpuid, where you asked for an msi vector
on a specific cpu, and then called pci_intr_establish with the
handle you get. kettenis pointed out that it's hard on some archs
to carry cpu on a pci interrupt handle, so i tweaked it to turn it
into a pci_intr_establish_cpu instead.
jmatthew@ and i (but mostly jmatthew@ to be honest) have been
experimenting with this api on multiple archs and it is working out
well. i'm putting this diff in now on amd64 so people can kick the
tyres a bit.
tested with hacked up vmx(4), ix(4), and mcx(4)
|
|
|
|
|
|
| |
information on ACPI 5.0 and later.
ok krw@, patrick@
|
|
|
|
| |
after 6.6 as been released. The acpireg.h change stays behind.
|
|
|
|
|
|
|
|
|
|
|
| |
few additional quirks though, and attaching the PCI busses is delayed to
replicate the existing code more closely. That may be changed in the
future. Also tweak how we handle MSI support and respect to ACPI flag
that says we shouldn't attempt to use MSIs.
Some fallout is expected.
ok patrick@
|
|
|
|
|
|
| |
an earlier diff from sf@.
ok jmatthew@, also ok mlarkin@, sf@ for a slightly different earlier version
|
|
|
|
|
|
|
|
|
| |
message address into an MSI-X table entry. The RTL8168/RTL8111 hardware
does not respond to 64-bit access (reads return all-ones, writes are
ignored) and the PCI specification documents separate 32-bit "DWORD"
fields for message address and message upper address.
ok mlarkin@, jmatthew@
|
|
|
|
|
|
|
| |
for now as amd64/i386 firmware still caters for legacy OSes that only
support a single PCI segment.
ok patrick@
|
|
|
|
|
|
|
| |
acpimcfg(4) to call an MD initialization functions that sets up a tag for
PCI ECAM.
ok guenther@, mlarkin@, krw@
|
|
|
|
| |
ok mpi@ deraadt@
|
| |
|
|
|
|
|
|
|
| |
register. Second, correctly decode the table sizefromits contents.
First issue pointed out by David Hill (with the help of clang). Second
issue spotted after seeing a diff from Christiano Hasbaert.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
actually use this in em(4) and xhci(4), but I'm not committing those yet
because we almost certainly need to save and restore the MSI-X registers
during suspend/resume. However, this allows mpi@ to play with multiple-vector
support in networking hardware.
Requested by mpi@
ok mlarkin@, mikeb@
|
|
|
|
|
|
|
| |
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.
ok tedu@ deraadt@
|
|
|
|
|
|
| |
within a range that is more (or less) restrictive than the default range.
ok deraadt@, stsp@
|
|
|
|
|
|
|
|
| |
They have devices outside the 36 bit range that their firmware needs to talk
to, and they get constant acpi interrupts if it can't. We should get the
necessary ranges via ACPI, but for now just make the allowed range bigger.
ok kettenis@ deraadt@
|
|
|
|
| |
tested by & ok mlarkin@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for PCI devices. This hook should be called twice, before and after
changing the power state of a PCI device.
Before setting the device to the new state, the ACPI layer will notify
every power resources linked to the device for that state and make sure
they are turned "_ON". After changing the state of the device, it will
decrement the reference of every power resources linked to that device
for the old state and turn them "_OFF" if they are no longer referenced.
This fixes the no-USB after resume problem seen on various ThinkPad,
problem initialy diagnosed with Alexander Polakov.
ok kettenis@, deraadt@
|
|
|
|
|
| |
is should return D3. It should return the current power state.
ok kettenis mlarkin
|
|
|
|
|
|
|
|
|
| |
but reserve everything above 36 bits so that the erroneous extent
allocation will fail but not panic the system. Fixes the notorious
IBM x3100 panic where one of the PCI BARs is programmed with an
incorrect 64 bit address.
Idea and OK kettenis@, tested by Walter Souza, thanks!
|
| |
|
| |
|
|
|
|
|
|
| |
busses.
tested by krw@
|
|
|
|
|
|
| |
space and not noticing because they only test on amd64. So enforce alignment
there as well, at least for a little while such that we find those bugs and
force people to fix them.
|
|
|
|
|
| |
separate functions and install them as route/unroute functions for the
MIS pseudo-PIC.
|
|
|
|
| |
From Brad.
|
| |
|
| |
|
|
|
|
| |
behind a prehistoric Intel host bridge. Disable MSI on these contortion.
|
|
|
|
|
|
|
|
| |
chipsets. All of those that support 64-bit CPUs should support MSI as well.
Explicitly disable MSI on chipsets that connect to the CPU over HyperTransport.
Enabling MSI on those systems is handled by the HyperTransport support code
in our PCI subsystem.
|
| |
|
|
|
|
|
| |
this code differs somewhat from the i386 code because the amd64 interrupt
subsystem is quite different. Still disabled like on i386.
|
|
|
|
|
|
|
| |
interrupts. It is irreleveant, confuses people and the information is
available in pcidump(8) output anyway.
ok oga@, jsg@, deraadt@
|
|
|
|
|
|
|
|
| |
addresses >4GB to 64-bit BARs have started to appear. But as long as machines
still support running 32-bit operating systems we don't expect to see BARs
that aren't addressable using PAE. Fixes a panic reported by william@.
ok deraadt@
|
|
|
|
|
|
|
|
|
| |
With current strategies to put memory in the ``correct'' place it isn't
needed. There's also the problem that it did not work on all machines,
failing completely on some and utterly breaking DMA. So just remove it.
If anyone needs it it will be in the Attic.
ok deraadt@
|
| |
|
|
|
|
|
| |
advertised in the MCFG table, and fall back on the traditional method for
other busses. Fixes issue reported by henning@.
|
|
|
|
|
| |
access to PCIe extended configuration space access on modern i386 and amd64
machines.
|
|
|
|
|
|
|
| |
given pcitag_t configuration address space. Currently, all pci controllers
will return the usual 0x100 bytes of PCI configuration space, but this will
eventually change on PCIe-capable controlers.
ok kettenis@
|
|
|
|
|
|
|
|
| |
compiler from doing stupid things like reordering stores around it. There is
some debate whether this will be enough for newer versions of GCC and LLVM.
If this is indeed deemed necessary, this will be addressed in a future diff.
ok miod@, oga@
|
|
|
|
|
|
| |
Simplify resource parsing function to use buffer argument
Convert namespace linked lists to use queue macros
ok marco@, deraadt@
|
| |
|
|
|
|
| |
ok kettenis, deraadt
|
|
|
|
|
|
|
| |
This should prevent problems on systems where these areas are not reserved in
the BIOS memory map.
ok miod@, oga@, marco@
|
|
|
|
|
|
|
|
|
| |
Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.
ok kettenis
(Manpage follows shortly.)
|
|
|
|
|
| |
logic to be chipset dependent; no functional change yet.
ok kettenis@
|
|
|
|
|
| |
can only address the first 64K but BARs can contain garbage and addresses
beyond the end of the extent would cause a panic.
|
|
|
|
|
|
| |
see the ancient mode 2 on machines capable of running OpenBSD/amd64.
ok deraadt@, toby@, oga@
|