summaryrefslogtreecommitdiffstats
path: root/sys/arch/amd64/pci/pci_machdep.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* spellingjsg2021-03-111-2/+2
|
* Adding IOMMU support for AMD Vi and Intel VTD (disabled)jordan2020-10-271-2/+17
| | | | | | | 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@ : ----------------------------------------------------------------------
* pci_intr_establish_cpu() for establishing an interrupt no a specific cpu.dlg2020-06-171-4/+13
| | | | | | | | | | | | | | | | | | | 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)
* Bring back the acpi(4) changes. This time around only use the ACPI _CRSkettenis2020-05-141-59/+1
| | | | | | information on ACPI 5.0 and later. ok krw@, patrick@
* Revert acpipci(4) changes. Too many systems are broken. We'll try againkettenis2019-09-071-4/+17
| | | | after 6.6 as been released. The acpireg.h change stays behind.
* Use ACPI information to attach PCI busses like we do on arm64. There are akettenis2019-08-281-17/+4
| | | | | | | | | | | 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@
* Implement suspend/resume support for MSI-X interrupts. Loosely based onkettenis2019-06-251-29/+54
| | | | | | an earlier diff from sf@. ok jmatthew@, also ok mlarkin@, sf@ for a slightly different earlier version
* Use two 32-bit writes instead of a single 64-bit write to write thekettenis2019-05-301-2/+3
| | | | | | | | | 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@
* Add support for multiple PCI segments. Only really implemented for arm64kettenis2018-08-191-7/+15
| | | | | | | for now as amd64/i386 firmware still caters for legacy OSes that only support a single PCI segment. ok patrick@
* Properly pass around the PCI "chipset tag" in acpi(4) and refactorkettenis2018-07-041-3/+13
| | | | | | | acpimcfg(4) to call an MD initialization functions that sets up a tag for PCI ECAM. ok guenther@, mlarkin@, krw@
* reduce the amount of includes in arch/amd64jsg2017-10-141-6/+1
| | | | ok mpi@ deraadt@
* If you use sys/param.h, you don't need sys/types.hderaadt2017-09-081-2/+1
|
* Fix two issues in the MSI-X code. First, actually read the MSI-X capabilitykettenis2016-06-021-5/+5
| | | | | | | 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.
* Fix typo; M_NOWAIT should be EX_NOWAIT. Fortunately this was harmless.kettenis2016-05-141-2/+2
|
* Initial support for MSI-X. Only supported on amd64 for now. I have diffs tokettenis2016-05-041-1/+144
| | | | | | | | | | 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@
* Remove some includes include-what-you-use claims don'tjsg2015-03-141-2/+1
| | | | | | | have any direct symbols used. Tested for indirect use by compiling amd64/i386/sparc64 kernels. ok tedu@ deraadt@
* Add bus_dmamem_alloc_range(9) to allow drivers to allocate DMA'able memorykettenis2015-01-241-1/+2
| | | | | | within a range that is more (or less) restrictive than the default range. ok deraadt@, stsp@
* Temporarily expand the pci memory range to suit Dell 13G servers.jmatthew2014-12-161-3/+7
| | | | | | | | 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@
* Don't panic if we're trying to disestablish an MSI but the hardware is gone.kettenis2014-04-191-4/+3
| | | | tested by & ok mlarkin@
* Add support for Power Resources for Dx states and the necessary hookmpi2013-11-061-5/+11
| | | | | | | | | | | | | | | | 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@
* If ACPI is not compiled in, pci_min_powerstate() has no facts to supportderaadt2013-05-301-2/+2
| | | | | is should return D3. It should return the current power state. ok kettenis mlarkin
* Change the PCI memory extent to cover the whole 64-bit memory spacemikeb2012-10-161-3/+5
| | | | | | | | | 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!
* Set up PCI bus number resource accounting for the main PCI bus hierarchy.kettenis2012-09-191-1/+7
|
* Implement pci_min_powerstate().kettenis2012-09-071-1/+15
|
* Make sure we don't accidentally use ISA or EISA interrupt mappings on PCIkettenis2011-10-291-17/+39
| | | | | | busses. tested by krw@
* I'm sick and tired of people doing misalgned reads and writes to PCI configkettenis2011-10-131-1/+5
| | | | | | 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.
* Cleanup MSI code a bit by moving the code to eanble/disable MSIs intokettenis2011-06-181-48/+39
| | | | | separate functions and install them as route/unroute functions for the MIS pseudo-PIC.
* QEMU pretends to emulate a different prehistoric Intel host bridge.kettenis2011-06-161-5/+7
| | | | From Brad.
* Disable MSIs in pci_intr_disestablish() when appropriate.kettenis2011-06-051-1/+18
|
* Direct MSIs at the appropriate CPU.kettenis2011-06-051-4/+5
|
* In the land of VMWare you can have the latest 64-bit AMD multicore CPUkettenis2011-06-021-1/+14
| | | | behind a prehistoric Intel host bridge. Disable MSI on these contortion.
* Enable MSI on selected hardware. For now this means all Intel, AMD and NVIDIAkettenis2011-05-301-1/+44
| | | | | | | | 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.
* Don't attempt to use MSI if we're not running in APIC mode.kettenis2011-05-291-2/+2
|
* First stab at suporting Message Signaled Interrupts on amd64. Unfortunatelykettenis2011-05-211-1/+83
| | | | | this code differs somewhat from the i386 code because the amd64 interrupt subsystem is quite different. Still disabled like on i386.
* Stop printing the PCI interrupt line programmed by the BIOS for APICkettenis2011-04-221-5/+3
| | | | | | | interrupts. It is irreleveant, confuses people and the information is available in pcidump(8) output anyway. ok oga@, jsg@, deraadt@
* Extend the PCI memory address space to 36-bit. The first BIOSen that assignkettenis2011-04-101-2/+8
| | | | | | | | 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@
* Remove the AMD GART based iommu code.oga2011-04-021-7/+1
| | | | | | | | | 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@
* Only use MMCFG extended PCIe config space. Gets us back the on-CPU PCI devices on AMD Family 0Fh processors.kettenis2011-01-101-3/+3
|
* Only use memory mapped extended PCIe config space access for the busseskettenis2011-01-091-34/+32
| | | | | advertised in the MCFG table, and fall back on the traditional method for other busses. Fixes issue reported by henning@.
* Add support for Memory Mapped Configuration space access. This gives uskettenis2011-01-041-1/+59
| | | | | access to PCIe extended configuration space access on modern i386 and amd64 machines.
* Introduce a new pci routine, pci_conf_size(), which returns the size of amiod2010-12-041-1/+7
| | | | | | | 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@
* Make sure bus_dmamap_sync() always involves a function call, to prevent thekettenis2010-09-061-2/+2
| | | | | | | | 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@
* Add mapping for ACPI device to PCI bdf (match autoconf tree)jordan2010-07-081-2/+2
| | | | | | Simplify resource parsing function to use buffer argument Convert namespace linked lists to use queue macros ok marco@, deraadt@
* Backout recent AML changes, breaks on R210 and othersjordan2010-07-011-2/+2
|
* Add support for mapping ACPI to PCI devicesjordan2010-06-291-1/+14
| | | | ok kettenis, deraadt
* Make video buffer area and BIOS areas unavailable for PCI resource allocation.kettenis2009-09-281-1/+5
| | | | | | | This should prevent problems on systems where these areas are not reserved in the BIOS memory map. ok miod@, oga@, marco@
* Constify the what/name parameter of pci_intr_establish().mk2009-08-221-2/+2
| | | | | | | | | Tested by myself, sthen, oga, kettenis, and jasper. Input from sthen and jasper. ok kettenis (Manpage follows shortly.)
* Pass a pci_chipset_tag_t to pci_intr_line(), to eventually allow themiod2009-07-201-4/+5
| | | | | logic to be chipset dependent; no functional change yet. ok kettenis@
* Extend pciio extents to cover the while 32-bit address space. The processorkettenis2009-04-291-4/+14
| | | | | can only address the first 64K but BARs can contain garbage and addresses beyond the end of the extent would cause a panic.
* Simplify PCI config space access code. There is no way we're ever going tokettenis2009-04-211-211/+19
| | | | | | see the ancient mode 2 on machines capable of running OpenBSD/amd64. ok deraadt@, toby@, oga@