summaryrefslogtreecommitdiffstats
path: root/sys/amd64/pci
Commit message (Collapse)AuthorAgeFilesLines
* 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-5/+5
|
* MFi386: sync with latest updatespeter2004-10-111-3/+36
|
* Add missing <sys/module.h> instances which were shadowed by the nestedphk2004-06-031-0/+1
| | | | include in <sys/kernel.h>
* MFi386: numerous interrupt and acpi updatespeter2004-05-161-1/+1
|
* Drastically clean up the legacy host-pci bridge table. We don't needpeter2004-03-131-208/+5
| | | | | | | all the ancient Intel/VIA/SIS/etc chipsets on amd64 systems. Even the newer intel stuff won't need this since we use acpi by default and we don't have all their magic programming information. Just use a generic "Host to PCI bridge" name if we ever hit this code.
* MFi386: nuke pci_cfgintrpeter2004-03-131-22/+1
|
* MFi386: change an outb to a DELAY()peter2004-01-281-1/+1
|
* Various whitespace and cosmetic sync-up's with i386.peter2003-12-062-2/+3
| | | | Approved by: re (scottl)
* Initial landing of SMP support for FreeBSD/amd64.peter2003-11-171-1/+1
| | | | | | | | | | | | | | | | - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
* GC unused child variablepeter2003-09-231-2/+1
|
* MFi386 pci_bus.c 1.102 legacyvar.h 1.4: rename nexus_pcib to legacy_pcibpeter2003-09-231-51/+53
| | | | | However, leave legacy_pcib_route_interrupt() since there is no pcibios to call.
* - Rename PCIx_HEADERTYPE* to PCIx_HDRTYPE* so the constants aren't so long.jhb2003-08-281-2/+10
| | | | | | | | | | | - Add a new PCIM_HDRTYPE constant for the field in PCIR_HDRTYPE that holds the header type. - Replace several magic numbers with appropriate constants for the header type register and a couple of PCI_FUNCMAX. - Merge to amd64 the fix to the i386 bridge code to skip devices with unknown header types. Requested by: imp (1, 2)
* Prefer new location of pci include files (which have only been in theimp2003-08-221-3/+3
| | | | | tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
* Use __FBSDID().obrien2003-07-252-6/+6
| | | | Brought to you by: a boring talk at Ottawa Linux Symposium
* Commit MD parts of a loosely functional AMD64 port. This is based onpeter2003-05-012-558/+18
| | | | | | | | | | | | | | | | | | | | | | a heavily stripped down FreeBSD/i386 (brutally stripped down actually) to attempt to get a stable base to start from. There is a lot missing still. Worth noting: - The kernel runs at 1GB in order to cheat with the pmap code. pmap uses a variation of the PAE code in order to avoid having to worry about 4 levels of page tables yet. - It boots in 64 bit "long mode" with a tiny trampoline embedded in the i386 loader. This simplifies locore.s greatly. - There are still quite a few fragments of i386-specific code that have not been translated yet, and some that I cheated and wrote dumb C versions of (bcopy etc). - It has both int 0x80 for syscalls (but using registers for argument passing, as is native on the amd64 ABI), and the 'syscall' instruction for syscalls. int 0x80 preserves all registers, 'syscall' does not. - I have tried to minimize looking at the NetBSD code, except in a couple of places (eg: to find which register they use to replace the trashed %rcx register in the syscall instruction). As a result, there is not a lot of similarity. I did look at NetBSD a few times while debugging to get some ideas about what I might have done wrong in my first attempt.
* Initiate de-orbit burn for USE_PCI_BIOS_FOR_READ_WRITE. This has beenpeter2003-02-182-147/+28
| | | | | | | | | | | | | | #if'ed out for a while. Complete the deed and tidy up some other bits. We need to be able to call this stuff from outer edges of interrupt handlers for devices that have the ISR bits in pci config space. Making the bios code mpsafe was just too hairy. We had also stubbed it out some time ago due to there simply being too much brokenness in too many systems. This adds a leaf lock so that it is safe to use pci_read_config() and pci_write_config() from interrupt handlers. We still will use pcibios to do interrupt routing if there is no acpi.. [yes, I tested this] Briefly glanced at by: imp
* Outdent the string rather than use concatenation.phk2002-12-231-2/+2
|
* MFp4:imp2002-11-141-1/+1
| | | | | o Fix small style nit. This was supposed to be part of the last batch of style fixes, but somehow didn't get merged.
* Recognize the Serverworks CIOB30 host to pci bridge.peter2002-11-131-0/+5
|
* MFp4:imp2002-11-021-10/+34
| | | | | | | | | | | | | | | o It turns out that we always need to try to route the interrupts for the case where the $PIR tells us there can be only one. Some machines require this, while others fail when we try to do this (bogusly, imho). Since we have no apriori way of knowing which is which, we always try to do the routing and hope for the best if things fail. o Add some additional comments that state the obvious, but amplify it in non-obvious ways (judging from the questions I've gotten). This should un-break older laptops that still have to use PCIBIOS to route interrupts. Tested by: sam
* Use 0xffffffff instead of -1 for id to compare against.imp2002-11-021-10/+11
| | | | | | | Use exact width types, since this is a MD file and won't be used elsewhere. Fix a couple of resulting printf breakages Bug found by: phk using Flexlint
* Revert last commit, there actually was a -1 waaaaay down in pcireg_cfgread().phk2002-10-201-0/+2
|
* "id" is never going to be -1 when it is unsigned.phk2002-10-201-2/+0
| | | | Spotted by: FlexeLint
* Use the global pcib devclass instead of our own static copy.jhb2002-10-161-2/+0
|
* o go ahead and route the interupt, even if it is supposedly unique.imp2002-10-071-7/+12
| | | | | | | | | | | there are some strange machines that seem to need this. o delete bogus comment. o don't use the the bios for read/writing config space. They interact badly with SMP and being called from ISR. This brings -current in line with -stable. # make the latter #ifdef on USE_PCI_BIOS_FOR_READ_WRITE in case we # need to go back in a hurry.
* Add 2 Ids for new ServerWorks host to PCI bridge chipset.iwasaki2002-10-021-0/+8
| | | | | | | | | These are still unknown name but these are working as well as the other ServerWorks chipset. Description strings should be corrected when the chipsets are known. MFC after: 1 week
* Don't call function in return() for a void function.phk2002-09-281-3/+5
|
* Now that we only probe host-PCI bridges once, we no longer have to check tojhb2002-09-231-10/+0
| | | | see if we have been probed before by checking for a pciX bus device.
* Put verbose printf's in the PCI BIOS interrupt routing code underjhb2002-09-231-1/+4
| | | | if (bootverbose).
* Change the nexus_pcib driver (eventually to be renamed to legacy_pcib) tojhb2002-09-231-7/+7
| | | | hang off of the legacy driver instead of the nexus.
* 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
OpenPOWER on IntegriCloud