summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci
Commit message (Collapse)AuthorAgeFilesLines
* Small whitespace fixes.jhb2010-03-111-2/+1
|
* Add pci_get|set_max_read_req() helper functions to control maximum PCIemav2010-02-052-0/+37
| | | | | | read request size. Reviewed by: jhb@
* Add more bit definitions to PCI express device control and deviceyongari2010-02-011-0/+8
| | | | | | status register. Reviewed by: jhb
* Move the PCI-specific logic of removing a cardbus device into ajhb2010-01-052-0/+41
| | | | | | | | | pci_delete_child() function called by the cardbus driver. The new function uses resource_list_unreserve() to release the BARs decoded by the device being removed. Reviewed by: imp Tested by: brooks
* Teach the PCI bus driver to handle PCIR_BIOS BARs properly and remove specialjhb2009-12-302-4/+81
| | | | | | | | | handling for the PCIR_BIOS decoding enable bit from the cardbus driver. The PCIR_BIOS BAR does include type bits like other BARs. Instead, it is always a 32-bit non-prefetchable memory BAR where the low bit is used as a flag to enable decoding. Reviewed by: imp
* Remove no longer used pci_release_resource().jhb2009-12-302-21/+0
|
* Implement a rudimentary suspend/resume methods for PCI P2P bridge.jkim2009-12-102-57/+200
| | | | Reviewed by: jhb, imp
* For some buses, devices may have active resources assigned even though theyjhb2009-12-091-62/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are not allocated by the device driver. These resources should still appear allocated from the system's perspective so that their assigned ranges are not reused by other resource requests. The PCI bus driver has used a hack to effect this for a while now where it uses rman_set_device() to assign devices to the PCI bus when they are first encountered and later assigns them to the actual device when a driver allocates a BAR. A few downsides of this approach is that it results in somewhat confusing devinfo -r output as well as not being very easily portable to other bus drivers. This commit adds generic support for "reserved" resources to the resource list API used by many bus drivers to manage the resources of child devices. A resource may be reserved via resource_list_reserve(). This will allocate the resource from the bus' parent without activating it. resource_list_alloc() recognizes an attempt to allocate a reserved resource. When this happens it activates the resource (if requested) and then returns the reserved resource. Similarly, when a reserved resource is released via resource_list_release(), it is deactivated (if it is active) and the resource is then marked reserved again, but is left allocated from the bus' parent. To completely remove a reserved resource, a bus driver may use resource_list_unreserve(). A bus driver may use resource_list_busy() to determine if a reserved resource is allocated by a child device or if it can be unreserved. The PCI bus driver has been changed to use this framework instead of abusing rman_set_device() to keep track of reserved vs allocated resources. Submitted by: imp (an older version many moons ago) MFC after: 1 month
* Disable interrupts after doing early takeover of the usb controller in case usbthompsa2009-11-251-0/+17
| | | | | | | isnt actually compiled in (or kldloaded) as the controller could cause spurious interrupts. Tested by: Florian Smeets
* - Partially revert hackish r198964 and r199002.jkim2009-11-121-13/+0
| | | | | | | - Add a proxy driver vgapm to help vgapci to save/load VGA state. - Move device_set_desc() to the right place while we are here. Reviewed by: jhb
* Remove duplicate suspend/resume code from vga_pci.c and let vga(4) registerjkim2009-11-061-76/+11
| | | | | | itself to an associated PCI device if it exists. It is little bit hackish but it should fix build without frame buffer driver since r198964. Fix some style(9) nits in vga_isa.c while we are here.
* Save/restore VGA state from vga_pci.c instead of relying on vga_isa.c.jkim2009-11-051-2/+80
| | | | | It was not working because we were saving its state after the device was powered down. Simplify vesa_load_state() as the culprit is fixed now.
* BIOSes, buggy or otherwise, are i386 or amd64 specific.marcel2009-10-231-0/+4
| | | | | | | | Have the early USB takeover enabled for i386 and amd64 by default. This also avoids a panic on PowerPC where the resource isn't released properly and we find a busy resource when the USB host controller wants to allocate it...
* Rewrite x86bios and update its dependent drivers.jkim2009-10-191-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4).
* Workaround buggy BIOS code in USB regard. By doing the BIOS to OS handover forthompsa2009-10-151-0/+121
| | | | | | | | | all host controllers at the same time, we avoid problems where the BIOS will actually write to the USB registers of all the USB host controllers every time we handover one of them, and consequently reset the OS programmed values. Submitted by: avg Reviewed by: jhb
* number of cleanups in i386 and amd64 pci md codeavg2009-09-241-0/+1
| | | | | | | | | | | | | 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
* Don't reread the command register to see if enabling I/O or memoryjhb2009-09-221-25/+1
| | | | | | | | | | decoding "took". Other OS's that I checked do not do this and it breaks some amdpm(4) devices. Prior to 7.2 we did not honor the error returned when this failed anyway, so this in effect restores previous behavior. PR: kern/137668 Tested by: Aurelien Mere aurelien.mere amc-os.com MFC after: 3 days
* pci(4): don't perform maximum register number checkavg2009-09-111-2/+1
| | | | | | | | | | | | | Different sub-kinds of PCI buses may have different rules and thus it is up for the bus backends to do proper input checks. For example, PCIe allows configuration register numbers < 0x1000, while for PCI proper the limit is 0x100. And, in fact, the buses already do the checks. Reviewed by: jhb MFC after: 1 week X-ToDo: add check for negative value to bus backends X-ToDo: use named constant for maximum PCIe register
* pci: remove definitions of duplicate constantsavg2009-09-102-12/+5
| | | | | | Suggested by: jhb Reviewed by: jhb MFC after: 1 week
* Add a MD __PCI_BAR_ZERO_VALID which denotes that BARs containing 0marius2009-07-211-8/+15
| | | | | | | | | | | | | actually specify valid bases that should be treated just as normal. The PCI specifications have no indication that 0 would be a magic value indicating a disabled BAR as commonly used on at least amd64 and i386 but not sparc64. It's unclear what to do in pci_delete_resource() instead of writing 0 to a BAR though as there's no (other) way do disable individual BARs so its decoding is left enabled in case of __PCI_BAR_ZERO_VALID for now. Approved by: re (kib), jhb MFC after: 1 week
* Enable MSI in the MSI capability registers any time that the first messagejhb2009-06-221-1/+3
| | | | | | | | in an MSI group is enabled, not just if the address/data pair are not initialized. Reported by: rnoland MFC after: 1 week
* Import ACPICA 20090521.jkim2009-06-051-1/+1
|
* 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
|
OpenPOWER on IntegriCloud