summaryrefslogtreecommitdiffstats
path: root/sys/i386/pci
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Make a bunch of malloc types static.phk2005-02-101-1/+1
| | | | Found by: src/tools/tools/kernxref
* /* -> /*- for copyright notices, minor format tweaks as necessaryimp2005-01-063-3/+3
|
* Remove a stray critical_exit().scottl2004-12-131-1/+0
| | | | Submitted by: johan
* Expand the scope of the critical section in the PCIe read and write methodsscottl2004-12-101-4/+14
| | | | on the advice of Alan Cox.
* Due to a significant addition of code, add my copyright to this file. Alsoscottl2004-12-061-0/+1
| | | | | note that the PCIe work was made possible due to hardware donations from the FreeBSD Foundation and Intel. Thanks!
* Add support for the memory-mapped PCI Express configuration mechanism. Thisscottl2004-12-061-8/+211
| | | | | | | | | | | | | | actually is a property of the northbridge and applies to all PCI/PCI-X/PCIe devices in the system, though only PCIe devices will respond to registers higher than 256. This uses per-CPU pools of temporary mappings so that the whole 256MB of configuration space doesn't have to be mapped all at once. While the sf_buf API was considered for this, the fact that it requires sleep locks and can return failure made it unsuitable for this use. For now only the Intel Grantsdale and Lindenhurst (925 and 752x) chipsets are supported. Since there doesn't appear to be a compatible way to determine northbridge support, new chipsets will have to be explicitely added in the future.
* Add TUNABLE_LONG and TUNABLE_ULONG, and use the latter for thedes2004-10-311-4/+3
| | | | | | | hw.pci.host_mem_start tunable. Add comments to TUNABLE_INT and TUNABLE_QUAD recommending against their use. MFC after: 3 weeks
* Whitespace cleanupdes2004-10-311-8/+8
|
* Make the lower range of the memory area 0x80000000 again. Alsoimp2004-10-111-1/+15
| | | | | | introduce hw.{pci,acpi}.host_mem_start tunable to change this. MFC: ASAP
* Add missing 'static'imp2004-10-061-2/+1
|
* For legacy PCI bridges, limit memory allocation to the top 32MB ofimp2004-10-061-4/+24
| | | | | | | | | | | RAM. Many older, legacy bridges only allow allocation from this range. This only appies to devices who don't have their memory assigned by the BIOS (since we allocate the ranges so assigned exactly), so should have minimal impact. Hoewver, for CardBus bridges (cbb), they rarely get the resources allocated by the BIOS, and this patch helps them greatly. Typically the 'bad Vcc' messages are caused by this problem.
* Consistently use __inline instead of __inline__ as the former is an empty macrostefanf2004-07-041-1/+1
| | | | in <sys/cdefs.h> for compilers without support for inline.
* Trim a few things from the dmesg output and stick them under bootverbose tojhb2004-07-012-4/+5
| | | | | | | cut down on the clutter including PCI interrupt routing, MTRR, pcibios, etc. Discussed with: USENIX Cabal
* Remove atdevbase and replace it's remaining uses with direct references tojhb2004-06-101-0/+1
| | | | KERNBASE instead.
OpenPOWER on IntegriCloud