summaryrefslogtreecommitdiffstats
path: root/sys/amd64/pci
Commit message (Collapse)AuthorAgeFilesLines
* Axe unused include.jhb2002-09-201-1/+0
|
* Make sure a $PIR table header has a valid length before accepting the tablejhb2002-09-091-1/+2
| | | | | | as valid. Submitted by: Michal Mertl <mime@traveller.cz>
* #include "opt_bla.h" goes first says Bruce.phk2002-09-091-2/+2
|
* Fix style(9) bugs.phk2002-09-081-2/+2
| | | | Brucified by: bde
* Add a subclass of the PCI-PCI bridge driver that uses the PCIBIOS tojhb2002-09-061-2/+69
| | | | | | | | | | route interrupts if the child bus is described in the PCIBIOS interrupt routing table. For child busses that are in the routing table, they do not necessarily use a 'swizzle' on their pins on the parent bus to route interrupts for child devices. If the child bus is an embedded device then the pins on the child devices can be (and usually are) directly connected either to a PIC or to a Interrupt Router. This fixes PCIBIOS interrupt routing across PCI-PCI bridges for embedded devices.
* Add a function pci_probe_route_table() that returns true if our PCI BIOSjhb2002-09-061-0/+19
| | | | | supports interrupt routing and if the specified PCI bus is present in the routing table.
* Dump the $PIR table if booting verbose.jhb2002-09-061-0/+3
|
* - Add a pci_cfgintr_valid() function to see if a given IRQ is a validjhb2002-09-062-2/+35
| | | | | | | | | | | | IRQ for an entry in a PCIBIOS interrupt routing ($PIR) table. - Change pci_cfgintr() to except the current IRQ of a device as a fourth argument and to use that IRQ for the device if it is valid. - If an intpin entry in a $PIR entry has a link of 0, it means that that intpin isn't connected to anything that can trigger an interrupt. Thus, test the link against 0 to find invalid entries in the table instead of implicitly relying on the irqs field to be zero. In the machines I have looked at, intpin entries with a link of 0 often have the bits for all possible interrupts for PCI devices set.
* Add support for printing out the contents of a PCI BIOS $PIR interruptjhb2002-09-061-2/+54
| | | | | routing table on the console. Eventually it will be printed during verbose boots.
* Prefer the physical bus number of the PCI bus as the unit of the pciXjhb2002-09-061-1/+1
| | | | device created.
* Test PCIbios.ventry against 0 to see if we found a PCIbios entry point,jhb2002-09-051-2/+2
| | | | | | | | | not the 'entry' member. The entry point is formed from both a base and a relative entry point. 'entry' is that relative offset. It is perfectly valid to have an entry point with a relative offset of 0. PCIbios.ventry is the virtual address of the entry point that takes both 'base' and 'entry' into account, thus it is the proper variable to test to see if we have an entry point or not.
* Change the support for AMDs ElanSC520 CPU from being a device driver tophk2002-09-041-0/+7
| | | | | | | | be options CPU_ELAN (NB: Soekris.com users!) It is cleaner this way. We still recognize the cpu on the host-pci bridge.
* Move a prototype to the least wrong place.phk2002-08-021-0/+1
| | | | Suggested by: bde
* style(9)ize the whole fileimp2002-07-211-474/+492
| | | | Approved in concept a long time ago by: msmith
* Add support for probing secondary buses on the ServerWorks Grand Championgallatin2002-07-191-0/+11
| | | | | | | | chipset used for P4-Xeon machines PR: kern/38894 Tested-by: "Marc G. Fournier" <scrappy@hub.org> Submitted-by: Mark Tinguely (partially)
* Add initialization code for the AMD Elan sc520 which maps the MMCRphk2002-07-181-0/+2
| | | | into KVM and sets the i8254 frequency to the correct value.
* Add an entry for the AMD Elan SC520 hostbridge. I do not belive we canphk2002-07-181-0/+3
| | | | | | identify this gadget on the CPUID result alone, so I intend to activate the necessary magic (i8254 frequency for instance) for it based on the precense of the on-chip host to PCI bridge.
* Use a common function to map the bogus intlines.imp2002-06-011-11/+17
| | | | | | | Don't require pin be non-zero before we map bogus intlines, always do it. This fixes a number of problems on HP Omnibook computers. Tested/Reviewed by: Brooks Davis
* Restore the irq=0 => irq=255 hack to pci_cfgintr_search(). Just havingbrooks2002-05-291-0/+8
| | | | | | it in pci_cfgregread() wasn't sufficent on at least the HP Omnibook 500. Reviewed by: imp
* o Work around bugs in the powerof2 macro: It thinks that 0 is a power ofimp2002-04-241-12/+18
| | | | | | | | | | | | | | | | 2, but that's not the case. This fixes the case where there were slots in the PIR table that had no bits set, but we assumed they did and used strange results as a result. o Map invalid INTLINE registers to 255 in pci_cfgreg.c. This should allow us to remove the bogus checks in MI code for non-255 values. I put these changes out for review a while ago, but no one responded to them, so into current they go. This should help us work better on machines that don't route interrupts in the traditional way. MFC After: 4286 millifortnights
* Fix a PNPID in a commentimp2002-04-241-1/+1
| | | | Submitted by: David Xu
* Major rework of the iicbus/smbus framework:nsouch2002-03-231-0/+13
| | | | | | | | - VIA chipset SMBus controllers added - alpm driver updated - Support for dynamic modules added - bktr FreeBSD smbus updated but not tested - cleanup
* Don't call the bios if the interrupt appaers to be already routed. Someimp2002-03-161-3/+3
| | | | | | older PCI BIOSes hate this and this leads to panics when it is done. Also, assume that a uniquely routed interrupt is already routed. This also seems to help some older laptops with feable BIOSes cope.
* The Libretto L series has no $PIR table, but does have a _PIR table.imp2002-01-201-13/+22
| | | | | | | | | | | | | This typo keeps us from properly routing an interrupt for CardBus bridges on this machine. So, now we look for $PIR and then _PIR to cope. With these changes, the Libretto L1 now works properly. Evidentally, the idea comes from patch that the Japanese version of RedHat (or against a Japanese version of Red Hat), but my Japanese isn't good enough to to know for sure. Reported by: Hiroyuki Aizu-san <eyes@navi.org> # This may be an MFC candidate, but I'm not yet sure.
* Add identification string for AMD-761 host to PCI bridge.murray2001-12-101-0/+3
| | | | PR: kern/32255
* MFS: I was confused. This code wasn't in -current after all.imp2001-11-261-5/+14
| | | | | | | Merge in the irq 0 detection. Add comment about why. If we have irq 0, ignore it like we do irq 255. Some BIOS writers aren't careful like they should be.
* It turns out that while Toshiba laptops don't want to route interruptsimp2001-08-281-17/+10
| | | | | | | | | | | | | | | | | | multiple times, others do. The last strategy, which was to assume that already routed interrupts were good and just return them doesn't work for some laptops. So, instead, we have a new strategy: we notice that we have an interrupt that's already routed. We go ahead and try to route it, none the less. We will assume that it is correctly routed, even if the route fails. We still assume that other failures in the bios32 call are because the interrupt is NOT routed. Note: some laptops do not support the bios32 interface to PCI BIOS and we need to call it via the INT 2A interface. That is another windmill to till at later. Also correct a minor typo and minor whitespace nits. Strong MFC candidate.
* MFS: IRQ ordering, PRVERB and more whining in pcibios_get_version on failure.imp2001-08-271-30/+60
| | | | | | | Check return value from bios32. [[ Yes, I was bad and committed this to stable first. I should have done the commit in the other order. ]]
* The general conesnsus on irc was that pci bios for config registersimp2001-08-211-2/+25
| | | | | | | | | and such was just a bad idea and one that users should be forced to enable if they want it. This patch introduces a hw.pci.enable_pcibios tunable for those people. This does not impact the pcibios interrupt routing at all. Approved by: peter, msmith
* Detect a certain type of PCIBIOS brain damage. For some reason,peter2001-08-212-0/+31
| | | | | | | | | | | | some bios vendors took it apon themselves to "censor" the host->pci bridges from PCIBIOS callers, even when the caller explicitly asks for them. This includes certain Compaq machines (eg: DL360) and some laptops. If we detect this, shut down pcibios and revert to using IO port bashing. Under -current, apcica does a better job anyway.
* Un-swap irq/link byte values so that printf works.msmith2001-05-111-1/+1
|
* Free the memory we get from devclass_get_devices and device_get_children.msmith2001-02-081-3/+8
| | | | Submitted by: wpaul
* Fix a warning due to missing prototype.peter2001-01-191-1/+1
|
* Remove declaration of airq variable from outer block. There were twobmilekic2001-01-121-1/+1
| | | | | | declarations of a variable of the same name. The one in the outer block was unused and probably just slipped in at one point or another. This silences a compiler warning.
* Next phase in the PCI subsystem cleanup.msmith2000-12-082-4/+54
| | | | | | | | | | | | | | | | | | | | - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
* Hack to work around a probe which will lock up at least some i450GX-basedmsmith2000-11-081-1/+5
| | | | | | | | | | | | | systems. From the PR: When 'probe.slot' is PCI_SLOTMAX (== 31) and 'probe.func' is 7, call to 'pci_cfgread()' here and machine suddenly hangs up. I don't know why... (or 450GX chipset's bug?) PR: i386/20379 Submitted by: Masayuki FUKUI <fukui@sonic.nm.fujitsu.co.jp>
* Improve the PCI interrupt routing code. Now the process is as follows:msmith2000-11-021-16/+162
| | | | | | | | | | | | - Look for a hardwired interrupt in the routing table for this bus/device/pin (we already did this). - Look for another device with the same link byte which has a hardwired interrupt. - Look for a PCI device matching an entry with the same link byte which has already been assigned an interrupt, and use that. - Look for a routable interrupt listed in the "PCI only" interrupts field and use that. - Pick the first interrupt that's marked as routable and use that.
* Return -10000 in pci_hostb_probe to allow agp driver (disabled otherwise)ache2000-10-201-1/+1
|
* Add i815 Host to Hubache2000-10-201-0/+3
|
* Call the BIOS to route the selected interrupt. Correctly calculate themsmith2000-10-191-4/+22
| | | | | interrupt from the PCI routing table (ffs returns 1 for the rightmost bit, not 0).
* Remove debug writes introduced in prior commitimp2000-10-161-5/+2
|
* Add the ability to use the $PIR table in the BIOS to route interruptsimp2000-10-162-3/+74
| | | | | | on demand. Submitted by: msmith
* Change the text for the ServerWorks north bridge chips. RCC is nowalc2000-10-141-4/+4
| | | | officially listed as ServerWorks by www.pcisig.com.
* When testing for PCI bus overlap with another enumerator, make sure wemsmith2000-10-111-1/+1
| | | | | | | check for the right bus number. This is still not quite right, but fixes things for multi-bus machines again. Submitted by: tegge
* Only attach "legacy" PCI busses if none have been attached via any othermsmith2000-10-091-3/+23
| | | | method.
* Move the i386 PCI attachment code out of i386/isa back into i386/pci.msmith2000-10-022-1028/+255
| | | | | Split out the configuration space access primitives, as these are needed elsewhere as well.
* Get out the roto-rooter and clean up the abuse of nexus ivars by thepeter2000-09-282-38/+12
| | | | | | | | | | | | i386/isa/pcibus.c. This gets -current running again on multiple host->pci machines after the most recent nexus commits. I had discussed this with Mike Smith, but ended up doing it slightly differently to what we discussed as it turned out cleaner this way. Mike was suggesting creating a new resource (SYS_RES_PCIBUS) or something and using *_[gs]et_resource(), but IMHO that wasn't ideal as SYS_RES_* is meant to be a global platform property, not a quirk of a given implementation. This does use the ivar methods but does so properly. It also now prints the physical pci bus that a host->pci bridge (pcib) corresponds to.
* Catch a few more bogosities in certain chipsets before they mess us up.peter2000-09-052-38/+178
| | | | | | | | | | | | | Some have dual host->PCI bridges for the same logical pci bus (!), eg: some of the RCC chipsets. This is a 32/64 bit 33/66MHz and dual pci voltage motherboard so persumably there are electical or signalling differences but they are otherwise the same logical bus. The new PCI probe code however was getting somewhat upset about it and ended up creating two pci bridges to the same logical bus, which caused devices on that logical bus to appear and be probed twice. The ACPI data on this box correctly identifies this stuff, so bring on ACPI! :-)
* Take a shot at fixing multiple pci busses on i386.peter2000-08-312-20/+100
| | | | | | | | pcib_set_bus() cannot be used on the new child because it is meant to be used on the *pci* device (it looks at the parent internally) not the pcib being added. Bite the bullet and use ivars for the bus number to avoid any doubts about whether the softc is consistant between probe and attach. This should not break the Alpha code.
* * Completely rewrite the alpha busspace to hide the implementation fromdfr2000-08-282-96/+168
| | | | | | | | | | | | the drivers. * Remove legacy inx/outx support from chipset and replace with macros which call busspace. * Rework pci config accesses to route through the pcib device instead of calling a MD function directly. With these changes it is possible to cleanly support machines which have more than one independantly numbered PCI busses. As a bonus, the new busspace implementation should be measurably faster than the old one.
OpenPOWER on IntegriCloud