summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci
Commit message (Collapse)AuthorAgeFilesLines
* Include <machine/stdarg.h> for va_*(). I'm not sure how this compiledjhb2009-06-021-0/+1
| | | | on amd64 without this.
* Add an internal pci_printf() routine similar to device_printf() exceptjhb2009-06-011-7/+18
| | | | that it prefixes the output with 'pci<domain>:<bus>:<device>:<function>: '.
* Adjust some comments.jhb2009-06-011-4/+4
|
* Revert junk from last commit. These are WIP and not ready (and don'timp2009-05-203-116/+0
| | | | match the description of the last commit).
* We no longer need to use d_thread_t, migrate to struct thread *.imp2009-05-203-0/+116
|
* - Add a few more register defintions for the PCI express capabilityjhb2009-04-171-0/+28
| | | | | | | | | | registers. - Cleanup PCI-X capability printf to not leave a dangling "supports" for some PCI-X bridges. - Display additional PCI express details including the negotiated and max link width and the actual and maximum supported max payload. MFC after: 1 month
* - Consolidate duplicated code for reading and sizing BARs and writing basejhb2009-04-141-121/+98
| | | | | | | | | | addresses to BARs into new pci_read_bar() and pci_write_bar() routines. pci_add_map(), pci_alloc_map(), and pci_delete_resource() now use these routines to work with BARs. - Just pass the device_t for the new PCI device to various routines instead of passing the device, bus, slot, and function. Reviewed by: imp
* - Fix spacing in the comment.stas2009-04-031-1/+1
| | | | Reported by: jhb
* - Correct the comment.stas2009-04-031-3/+4
| | | | MFC after: 3 days
* Don't adjust ranges at all for subtractive bridges. The simple-mindedimp2009-03-151-0/+4
| | | | stuff we're doing is too simple-minded, so back it out for now.
* Two fixes:imp2009-03-142-18/+14
| | | | | | | | | | | | | | (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
* Fix a buglet in revision 189401: when restoring a 64-bit BAR,marcel2009-03-101-1/+1
| | | | | write the upper 32-bits in the adjacent bar. The consequences of the buglet were severe enough though: a machine check.
* Invert the logic error for the MSI/MSIX vs INTx case.rnoland2009-03-061-1/+1
| | | | | | Pointyhat to: me MFC after: 3 days
* Always read/write the full 64-bit value of 64-bit BARs. Specifically,jhb2009-03-052-23/+34
| | | | | | | | when determining the size of a BAR by writing all 1's to the BAR and reading back the result, always operate on the full 64-bit size. Reviewed by: imp MFC after: 1 month
* Honor the prefetchable flag in memory BARs by setting the RF_PREFETCHABLEjhb2009-03-051-2/+6
| | | | | | | | | | | flag when calling bus_alloc_resource() to allocate resources from a parent PCI bridge. For PCI-PCI bridges this asks the bridge to satisfy the request using the prefetchable memory range rather than the normal memory range. Reviewed by: imp Reported by: scottl MFC after: 1 week
* The recent PCI resource allocation fixes exposed a bug where the samejhb2009-03-041-1/+60
| | | | | | | | BAR could be allocated twice by different children of a vgapci0 device. To fix this, change the vgapci0 device to track references on its associated resources so that they are only allocated once from the parent PCI bus and released when no children are using them. Previously this leaked a small amount of KVA on at least some architectures.
* Extend the management of PCIM_CMD_INTxDIS.rnoland2009-03-041-18/+35
| | | | | | | | | | | We now explicitly enable INTx during bus_setup_intr() if it is needed. Several of the ata drivers were managing this bit internally. This is better handled in pci and it should work for all drivers now. We also mask INTx during bus_teardown_intr() by setting this bit. Reviewed by: jhb MFC after: 3 days
* Further refine the handling of resources for BARs in the PCI bus driver.jhb2009-03-032-82/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A while back, Warner changed the PCI bus code to reserve resources when enumerating devices and simply give devices the previously allocated resources when they call bus_alloc_resource(). This ensures that address ranges being decoded by a BAR are always allocated in the nexus0 device (or whatever device the PCI bus gets its address space from) even if a device driver is not attached to the device. This patch extends this behavior further: - To let the PCI bus distinguish between a resource being allocated by a device driver vs. merely being allocated by the bus, use rman_set_device() to assign the device to the bus when it is owned by the bus and to the child device when it is allocated by the child device's driver. We can now prevent a device driver from allocating the same device twice. Doing so could result in odd things like allocating duplicate virtual memory to map the resource on some archs and leaking the original mapping. - When a PCI device driver releases a resource, don't pass the request all the way up the tree and release it in the nexus (or similar device) since the BAR is still active and decoding. Otherwise, another device could later allocate the same range even though it is still in use. Instead, deactivate the resource and assign it back to the PCI bus using rman_set_device(). - pci_delete_resource() will actually completely free a BAR including attemping to disable it. - Disable BAR decoding via the command register when sizing a BAR in pci_alloc_map() which is used to allocate resources for a BAR when the BIOS/firmware did not assign a usable resource range during boot. This mirrors an earlier fix to pci_add_map() which is used when to size BARs during boot. - Move the activation of I/O decoding in the PCI command register into pci_activate_resource() instead of doing it in pci_alloc_resource(). Previously we could actually enable decoding before a BAR was initialized via pci_alloc_map(). Glanced at by: bsdimp
* Disable INTx when enabling MSI/MSIXrnoland2009-03-022-0/+5
| | | | | | | | | | | | | | | This addresses interrupt storms that were noticed after enabling MSI in drm. I think this is due to a loose interpretation of the PCI 2.3 spec, which states that a function using MSI is prohibitted from using INTx. It appears that some vendors interpretted that to mean that they should handle it in hardware, while others felt it was the drivers responsibility. This fix will also likely resolve interrupt storm related issues with devices other than drm. Reviewed by: jhb@ MFC after: 3 days
* Don't throw away upper 32-bits of the HT MSI address window. In practicejhb2009-02-261-1/+1
| | | | | | | | this is harmless since the address window for MSI on x86 is in the lower 4 GB. Submitted by: mav MFC after: 1 week
* Add SATA and PCI Advanced Features capabilities constants.mav2009-02-151-0/+11
|
* - Add a new ioctl to /dev/pci to fetch details on an individual BAR of ajhb2009-02-022-4/+73
| | | | | | | | | | | | | | device. The details include the current value of the BAR (including all the flag bits and the current base address), its length, and whether or not it is enabled. Since this operation is not invasive, non-root users are allowed to use it (unlike manual config register access which requires root). The intention is that userland apps (such as Xorg) will use this interface rather than dangerously frobbing the BARs from userland to obtain this information. - Add a new sub-mode to the 'list' mode of pciconf. The -b flag when used with -l will now list all the active BARs for each device. MFC after: 1 month
* Change the probe priority for PCI and I2C generic bus modules fromnwhitehorn2009-01-201-1/+1
| | | | | | numerical constants to BUS_PROBE_GENERIC. Suggested by: jhb
* Disable decoding of BARs by devices before we trash the value in the BARjhb2009-01-161-0/+18
| | | | | | | | | | | | | by writing all 1's to it to determine its length. This fixes issues with MCFG on at least some machines where a trashed BAR claimed subsequent attempts at PCI config transactions because the addresses in the MCFG window fell in the decoding range of the BAR. In general it is a bad idea to leave the BARs enabled while we are frobbing with them in this manner. Sleuthing by: tegge MFC after: 1 week
* Add ADMA, SATA and SAS mass storage subclasses reporting.mav2008-11-131-0/+3
|
* Nit: Add a few leading zeros to make this match other mask constantsimp2008-11-031-1/+1
| | | | in this file. Also to make sure that I got other ASI constants right.
* Add HDA multimedia subclass.mav2008-10-212-0/+2
|
* Add "SD host controller" subclass name.mav2008-10-211-0/+1
|
* pci_setup_intr() will only enable MSI/MSI-X for direct children. Add methodsrnoland2008-09-191-2/+18
| | | | | | | to vga_pci.c to request on behalf of it's children. This causes vgapci to show up as the interrupt owner in vmstat -i, rather than the child device. Approved by: jhb(mentor)
* Allow child devices of vgapci(4) to query VPD strings and use MSI/MSI-Xjhb2008-09-161-1/+99
| | | | | | | interrupts. For the MSI/MSI-X case, we only allow 1 child device to use MSI or MSI-X at a time. Tested by: rnoland
* Style nit. Continued lines are indented 2 spaces in this file.imp2008-09-031-4/+4
|
* Cope with errors from device_get_children(). These errors can happenimp2008-08-231-4/+7
| | | | | | | only in low memory situations, so the error fork of these fixes is lightly tested, but they should do the least-wrong thing... Submitted by: Hans Petter Selasky
* Cosmetic nit.imp2008-08-231-2/+0
|
* The config space registers holding the upper 32-bits of the prefetchablejhb2008-08-202-4/+19
| | | | | | | | | | | | | memory area's base and limit are optional. The low 4-bits of the "low" prefetchable registers indicates whether or not a 32-bit or 64-bit region is supported. The PCI-PCI driver had been assuming that all bridges supported a 64-bit region (and thus the two upper 32-bit registers). Fix the driver to only use those registers if the low 4-bits of the "low" registers indicate that a 64-bit region is supported. The PCI-PCI bridge in the XBox happens to be a bridge that only supports a 32-bit region. Reported by: rink MFC after: 1 week
* Update a comment about not numbering pci busses. This may soon beimp2008-08-171-7/+9
| | | | OBE, but was sitting around in one of my trees for a while...
* Remove useless #if 1.imp2008-08-161-2/+0
|
* Add some sysctl reporting for most pci_pci bridges. We now reportimp2008-08-162-3/+21
| | | | | | | | | | | | | domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
* Change -1 to 0xfffffffful since the interface returns uint32_t.imp2008-08-091-1/+1
|
* Remove the second check for a 64-bit BAR value on a 32-bit system injhb2008-08-051-19/+1
| | | | | | | | | | pci_add_map(). First, this condition is already handled earlier in the function. Second, as written the check would never fire as the 'start' value was overwritten with a long value (rman_get_start() returns long) before the comparison was done. Discussed with: imp MFC after: 2 weeks
* If the kernel fails to allocate resources for the initial value of a BARjhb2008-08-051-13/+33
| | | | | | | | | | | | | for a PCI device during the boot-time probe of the parent PCI bus, then zero the BAR and clear the resource list entry for that BAR. This forces the PCI bus driver to request a valid resource range from the parent bridge driver when the device driver tries to allocate the BAR. Similarly, if the initial value of a BAR is a valid range but it is > 4GB and the current OS only has 32-bit longs, then do a full teardown of the initial value of the BAR to force a reallocation. Reviewed by: imp MFC after: 1 week
* SATA device on some nForce based boards could get confused if MSI is notluoqi2008-07-233-5/+59
| | | | | | | | | | | | | | | used but MSI to HyperTransport IRQ mapping is enabled, and would act as if MSI is turned on, resulting in interrupt loss. This commit will, 1. enable MSI mapping on a device only when MSI is enabled for that device and the MSI address matches the HT mapping window. 2. enable MSI mapping on a bridge only when a downstream device is allocated an MSI address in the mapping window PR: kern/118842 Reviewed by: jhb MFC after: 1 week
* Remove some remnant alpha hacks.marius2008-04-261-7/+0
| | | | Approved by: PCI-maintainers (imp, jhb)
* Remove a trailing comma which FlexeLint whines about.phk2008-04-121-1/+1
|
* Relax the check for a PCI-express chipset by assuming the system is ajhb2008-02-011-5/+2
| | | | | | | | | | | | | | | | PCI-express chipset (and thus has functional MSI) if there are any PCI-express devices in the system, not requiring a root port device. With PCI-X the chipset detection has to be very conservative because there are known systems with PCI-X devices that do not appear to have PCI-X chipsets. However, with PCI-express I'm not sure it is possible to have a PCI-express device in a system with a non-PCI-express chipset. If we assume that is the case then this change is valid. It is also required for at least some PCI-express systems that don't have any devices with a root port capability (some ICH9 systems). MFC after: 1 week Reported by: jfv
* Don't cache the new-bus name of a PCI device in the PCI conf structure,jhb2008-01-151-1/+4
| | | | | | | | | | | but reread it from the device_t every time the device list is fetched. Previously the device name in pciconf -l would not be updated when a driver was unloaded or if a device was detached and attached to a different driver. MFC after: 1 week PR: kern/104777 Submitted by: "Iasen Kostoff" tbyte | otel net
* Fix some bugs in the FreeBSD 4/5/6 pci(4) IOCTLs compatibility code:marius2007-12-261-12/+9
| | | | | | | | | | | | | | | | - Use the correct offsets when copying out the results of PCIOCGETCONF_OLD. This happened to not affect the 64-bit architectures because there the addition of pc_domain to struct pcisel didn't change the overall size of struct pci_conf. [1] - Always copy the name and unit information to conf_old so it's also part of the output once this information is cached in dinfo. - Use the correct type for flags in struct pci_match_conf_old. This change is more or less cosmetic though. Reported and tested by: bde [1] Reviewed by: imp MFC after: 3 days Committed from: 24C3
* Make VPD register access more robust:jkim2007-11-161-69/+121
| | | | | | | | | | | | | - Implement timing out of VPD register access.[1] - Fix an off-by-one error of freeing malloc'd space when checksum is invalid. - Fix style(9) bugs, i.e., sizeof cannot be followed by space. - Retire now obsolete 'hw.pci.enable_vpd' tunable. Submitted by: cokane (initial revision)[1] Reviewed by: marius (intermediate revision) Silence from: jhb, jmg, rwatson Tested by: cokane, jkim MFC after: 3 days
* Simplify the old compat #ifdefs.imp2007-10-261-22/+12
|
* Add ABI backwards compatibility to the FreeBSD 4/5/6 versions ofmarius2007-10-241-51/+295
| | | | | | | | | | | | | | the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs, which was broken with the introduction of PCI domain support. As the size of struct pci_conf_io wasn't changed with that commit, this unfortunately requires the ABI of PCIOCGETCONF to be broken again in order to be able to provide backwards compatibility to the old version of that IOCTL. Requested by: imp Discussed with: re (kensmith) Reviewed by: PCI maintainers (imp, jhb) MFC after: 5 days
* Make the PCI code aware of PCI domains (aka PCI segments) so we canmarius2007-09-306-41/+89
| | | | | | | | | | | | | | | | | | | | | | | | 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)
OpenPOWER on IntegriCloud