summaryrefslogtreecommitdiffstats
path: root/sys/i386/pci
Commit message (Collapse)AuthorAgeFilesLines
* MFC r258779,r258780,r258787,r258822:eadler2014-02-041-1/+1
| | | | | | | | | | | | | 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. Similar to the (1 << 31) case it is not defined to do (2 << 30). 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.
* Replace kernel virtual address space allocation with vmem. This providesjeff2013-08-071-1/+1
| | | | | | | | | | | | | transparent layering and better fragmentation. - Normalize functions that allocate memory to use kmem_* - Those that allocate address space are named kva_* - Those that operate on maps are named kmap_* - Implement recursive allocation handling for kmem_arena in vmem. Reviewed by: alc Tested by: pho Sponsored by: EMC / Isilon Storage Division
* Remove duplicate code. Reduce diff between amd64 and i386.jkim2012-12-011-25/+19
|
* Use volatile keywords properly.jkim2012-11-301-11/+11
|
* Tidy up inline assembly. No functional change.jkim2012-11-301-8/+8
|
* pciereg_cfg*: use assembly to access the mem-mapped cfg spaceavg2012-10-141-6/+20
| | | | | | | | | AMD BKDG for CPU families 10h and later requires that the memory mapped config is always read into or written from al/ax/eax register. Discussed with: kib, alc Reviewed by: kib (earlier version) MFC after: 25 days
* Move {amd64,i386}/pci/pci_bus.c and {amd64,i386}/include/pci_cfgreg.h tojhb2011-06-221-700/+0
| | | | | the x86 tree. The $PIR code is still only enabled on i386 and not amd64. While here, make the qpi(4) driver on conditional on 'device pci'.
* Use uintXX_t instead of u_intXX_t.jhb2011-06-221-5/+5
|
* Add a helper routine to conditionally modify the start address of ajhb2011-06-221-22/+32
| | | | | | | | | | | | | | | | 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)
* On multi-core, multi-threaded PPC systems, it is important that the threadsnwhitehorn2011-05-311-1/+1
| | | | | | | | | | | | be brought up in the order they are enumerated in the device tree (in particular, that thread 0 on each core be brought up first). The SLIST through which we loop to start the CPUs has all of its entries added with SLIST_INSERT_HEAD(), which means it is in reverse order of enumeration and so AP startup would always fail in such situations (causing a machine check or RTAS failure). Fix this by changing the SLIST into an STAILQ, and inserting new CPUs at the end. Reviewed by: jhb
* Reimplement how PCI-PCI bridges manage their I/O windows. Previously thejhb2011-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,jhb2011-05-021-0/+1
| | | | | generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge drivers.
* Add device IDs for two more ServerWorks Host-PCI bridges so that we canjhb2010-11-251-0/+5
| | | | | | | | read their starting PCI bus number for older systems that do not support ACPI (or have a broken _BBN method). PR: kern/148108 MFC after: 1 week
* Change the MPTable and $PIR PCI-PCI bridge drivers to inherit from thejhb2010-08-051-25/+2
| | | | | generic PCI-PCI bridge driver and only override specific methods. This should fix suspend/resume of PCI-PCI bridges using these drivers.
* number of cleanups in i386 and amd64 pci md codeavg2009-09-241-7/+7
| | | | | | | | | | | | | o introduce PCIE_REGMAX and use it instead of ad-hoc constant o where 'reg' parameter/variable is not already unsigned, cast it to unsigned before comparison with maximum value to cut off negative values o use PCI_SLOTMAX in several places where 31 or 32 were explicitly used o drop redundant check of 'bytes' in i386 pciereg_cfgread() - valid values are already checked in the subsequent switch Reviewed by: jhb MFC after: 1 week
* Match PCI Express root bridge _HID directly instead ofjkim2009-07-131-0/+1
| | | | | | | relying on _CID. Reviewed by: jhb Approved by: re (kib)
* strict kobj signatures: fix legacy i386 pcib_write_config implavg2009-06-111-4/+4
| | | | | Reviewed by: imp, current@ Approved by: jhb (mentor)
* Add a read-only sysctl hw.pci.mcfg to mirror the tunable by the same name.jhb2009-05-181-0/+5
| | | | MFC after: 1 week
* Fall back to using configuration type 1 accesses for PCI config requests ifjhb2009-03-241-0/+2
| | | | | | | | the requested PCI bus falls outside of the bus range given in the ACPI MCFG table. Several BIOSes seem to not include all of the PCI busses in systems in their MCFG tables. It maybe that the BIOS is simply buggy and does support all the busses, but it is more conservative to just fall back to the old method unless it is certain that memory accesses will work.
* Add a 'hw.pci.mcfg' tunable. It can be set to 0 to disable memory-mappedjhb2008-09-111-0/+6
| | | | PCI config access.
* Some K8 chipsets don't expose all of the PCI devices on bus 0 via PCIejhb2008-09-101-14/+44
| | | | | | | | | | memory-mapped config access. Add a workaround for these systems by checking the first function of each slot on bus 0 using both the memory-mapped config access and the older type 1 I/O port config access. If we find a slot that is only visible via the type 1 I/O port config access, we flag that slot. Future PCI config transactions to flagged slots on bus 0 use type 1 I/O port config access rather than memory mapped config access.
* Extend the support for PCI-e memory mapped configuration space access:jhb2008-08-221-36/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | - Rename pciereg_cfgopen() to pcie_cfgregopen() and expose it to the rest of the kernel. It now also accepts parameters via function arguments rather than global variables. - Add a notion of minimum and maximum bus numbers and reject requests for an out of range bus. - Add more range checks on slot/func/reg/bytes parameters to the cfg reg read/write routines. Don't panic on any invalid parameters, just fail the request (writes do nothing, reads return -1). This matches the behavior of the other cfg mechanisms. - Port the memory mapped configuration space access to amd64. On amd64 we simply use the direct map (via pmap_mapdev()) for the memory mapped window. - During acpi_attach() just after loading the ACPI tables, check for a MCFG table. If it exists, call pciereg_cfgopen() on each subtable (memory mapped window). For now we only support windows for domain 0 that start with bus 0. This removes the need for more chipset-specific quirks in the MD code. - Remove the chipset-specific quirks for the Intel 5000P/V/Z chipsets since these machines should all have MCFG tables via ACPI. - Updated pci_cfgregopen() to DTRT if ACPI had invoked pcie_cfgregopen() earlier. MFC after: 2 weeks
* - Add support for memory mapped PCI config space access on Intel 915GMjhb2008-08-201-3/+23
| | | | | | | | | | | and 5000P/V/Z chipsets. - If the base address of the config space BAR is above 4GB for some reason and this isn't a PAE kernel, then warn about this (under bootverbose) and don't use the BAR. PR: kern/126525 Submitted by: Arthur Hartwig @ Nokia MFC after: 2 weeks
* Use switch statements instead of if-else for enabling PCI-express configjhb2008-08-201-3/+9
| | | | | | space support. MFC after: 1 week
* Integrate support for xen in to i386 common code.kmacy2008-08-152-1/+18
| | | | MFC after: 1 month
* More properly handle links who only have 1 valid IRQ in their bitmask. Thejhb2007-12-211-13/+12
| | | | | | | | | | | | | | | | | | | | | old code special cased them too early which caused a few differences for these sort of links relative to other PCI links: - They were always re-routed via the BIOS call instead of assuming that they were already routed if the BIOS had programmed the IRQ into a matching device during POST. - If the BIOS did route that link to a different IRQ that was marked as invalid, we trusted the $PIR table rather than the BIOS IRQ. This change moves the special casing for "unique IRQ" links to only take that into account when picking an IRQ for an unrouted link so that these links will now not be routed if the BIOS appears to have routed it already (some BIOSen have problems with that) and so that if the BIOS uses a different IRQ than the $PIR, we trust the BIOS routing instead (this is what we do for all other links as well). Reported by: Bruce Walter walter of fortean com MFC after: 1 week
* MFamd64: 1.109 of pci_cfgreg.c which changes pci_cfgdisable() into a nopjhb2007-11-281-2/+6
| | | | | | for type #1 similar to what other OS's do. MFC after: 3 days
* Adjust the code to probe for the PCI config mechanism to use.jhb2007-11-281-25/+25
| | | | | | | | | | | | | | - On amd64, just assume type #1 is always used. PCI 2.0 mandated deprecated type #2 and required type #1 for all future bridges which was well before amd64 existed. - For i386, ignore whatever value was in 0xcf8 before testing for type #1 and instead rely on the other tests to determine if type #1 works. Some newer machines leave garbage in 0xcf8 during boot and as a result the kernel doesn't find PCI at all (which greatly confuses ACPI which expects PCI to exist when PCI busses are in the namespace). MFC after: 3 days Discussed with: scottl
* Make the PCI code aware of PCI domains (aka PCI segments) so we canmarius2007-09-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
* Revamp the MSI/MSI-X code a bit to achieve two main goals:jhb2007-05-021-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
* Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.jhb2007-01-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
* Give Host-PCI bridge drivers their own pcib_alloc_msi() andjhb2006-12-121-2/+24
| | | | | | pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
* Replace a few magic numbers.jhb2006-12-121-2/+2
|
* MD support for PCI Message Signalled Interrupts on amd64 and i386:jhb2006-11-131-0/+8
| | | | | | | | | | | | | | | | | | | - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
* Don't dump the $PIR table under bootverbose. The pirtool program injhb2006-11-091-39/+0
| | | | | | src/tools/tools works fine, and dumping this table can add a lot of noise. MFC after: 1 week
* - Make pcib_devclass private to sys/dev/pci/pci_pci.c and change all thejhb2006-01-061-17/+7
| | | | | | | various pcib drivers to use their own private devclass_t variables for their modules. - Use the DEFINE_CLASS_0() macro to declare drivers for the various pcib drivers while I'm here.
* Move the hostb driver out of the i386 and amd64 PCI code (where it wasjhb2005-12-201-58/+0
| | | | | | | duplicated anyways) and into a single MI driver. Extend the driver a bit to implement the bus and PCI kobj interfaces such that other drivers can attach to it and transparently act as if their parent device is the PCI bus (for the most part).
* Add support for 7320 and 915 PCIe chipsets.rodrigc2005-12-081-7/+11
| | | | | | Submitted by: Gavin Atkinson <gavin.atkinson at ury dot york dot ac dot uk> PR: kern/79139 Reviewed by: scottl
* Provide a dummy NO_XBOX option that lives in opt_xbox.h for pc98.imp2005-11-141-2/+0
| | | | This allows us to eliminate a three ifdef PC98 instances.
* Fix pc98 build.nyan2005-11-091-0/+2
|
* Add support for XBOX to the FreeBSD port. The xbox architecture isimp2005-11-091-0/+39
| | | | | | | | | | | | | | | | | | | | nearly identical to wintel/ia32, with a couple of tweaks. Since it is so similar to ia32, it is optionally added to a i386 kernel. This port is preliminary, but seems to work well. Further improvements will improve the interaction with syscons(4), port Linux nforce driver and future versions of the xbox. This supports the 64MB and 128MB boxes. You'll need the most recent CVS version of Cromwell (the Linux BIOS for the XBOX) to boot. Rink will be maintaining this port, and is interested in feedback. He's setup a website http://xbox-bsd.nl to report the latest developments. Any silly mistakes are my fault. Submitted by: Rink P.W. Springer rink at stack dot nl and Ed Schouten ed at fxq dot nl
* MFamd64: indent with tabs instead of spaces.peter2005-11-041-1/+1
|
* Undo the change to pci_cfgdisable() on i386 for now. It seems to fixwpaul2005-10-251-6/+2
| | | | the amd64 case, but makes the i386 case fail even more often.
* Modify the pci_cfgdisable() routine to bring it more in line withwpaul2005-10-251-3/+7
| | | | | | | | | | | | | other OSes (Solaris, Linux, VxWorks). It's not necessary to write a 0 to the config address register when using config mechanism 1 to turn off config access. In fact, it can be downright troublesome, since it seems to confuse the PCI-PCI bridge in the AMD8111 chipset and cause it to sporadically botch reads from some devices. This is the cause of the missing USP ports problem I was experiencing with my Sun Opteron system. Also correct the case for mechanism 2: it's only necessary to write a 0 to the ENABLE port.
* Expose legacy_pcib_alloc_resource, and use it in the mptable pci busimp2005-09-171-1/+1
| | | | | | | implementation, like other routines in the legacy bus. This should fix problems with resource allocation on MP systems without ACPI enabled.
* Commit a workaround to a problem with resource allocation. This helpsimp2005-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | with some Dell servers that booted w/o a problem[*] on 5.4, but failed with 6.0-BETA. On the PCI bus, when we do lazy resource allocation, we narrow the range requested as we pass through bridges to reflect how the bridges are programmed and what addresses they pass. However, when we're doing an allocation on a bus that's directly connected to a host bridge, no such translation can take place. We already had a fallback range for memory requests, but none for ioports. As such, provide a fallback for I/O ports so we don't allocate location 0, which will have undesired side effects when the resources are actually used. This fixes a problem with booting a Dell server with usb in the kernel. However, it is an unsatisfying solution. I don't like the hard coded value, and I think we should start narrowing the resources returned to not be in the so-called isa alias area (where the ranage & 0x0300 must be 0 iirc). Doing such filtering will have to wait for another day. This may be a good 6 candidate, maybe after its had a chance to be refined. Tested by: glebius@
* Note that pc98 specific defines maybe would be better in a header file.imp2005-09-081-0/+1
|
* - Ignore BIOS IRQs (that is, IRQ settings left by the BIOS or a previous OSjhb2005-07-131-1/+10
| | | | | | | | | in the PCI config registers) that are > 15 as $PIR can only route PCI interrupts to ISA IRQs which are limited to the 0 to 15 range. - Remove an extra word from a printf. Reported by: othermark atkin901 at yahoo dot com MFC after: 3 days
* Trust the settings programmed by the BIOS over what the $PIR says.jhb2005-04-141-18/+48
| | | | | | | | Specifically, if the BIOS has programmed an IRQ for a device that doesn't match the list of valid IRQs for the link, use it anyway as some BIOSes don't correctly list the valid IRQs in the $PIR. Also, allow the user to specify an IRQ that $PIR claims is invalid as an override, but emit a warning in that case.
* Add code to read the primary PCI bus number out of the Compaq/HP 6010jhb2005-03-251-0/+6
| | | | | hotplug Host to PCI bridge. This is only needed for the non-ACPI case as the BIOS includes a proper _BBN method in ACPI.
OpenPOWER on IntegriCloud