This is required when two or more bridges on the same bus, and some of
them are incompletely initialized by BIOS.
Reported by NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp>
Do not initialize global variables 'pciintr_icu_tag' to NULL.
Its type is 'const struct pciintr_icu *' (typedef'ed) and gcc sometimes(!)
put it in Text region. So force arrrange it to BSS.
-remove the check for i810's internal graphics completely: we'll attach
AGP whether in GFX or AGP mode anyway, and the SMRAM register test
was of questionable value (should have masked with 0xc0, but even then
the builtin graphics appeared enabled although I used an external
PCI card)
be spread over several devices, and the phcb is usually the main one.
Add agp_machdep.c file which implements MD agp functions (currently
just agp_flush_cache).
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
setting for the "Idle/Pipeline DRAM Leadoff Timing (IPLDT)" parameter
(bits 9:8) is 01. Unfortunately, some BIOSs do not set these bits properly.
Based on a hint from OpenBSD.
Under this option, if only one IRQ is available for the link,
we assumes that the IRQ is already connected, and configure
PCI Interrupt Configuration Register accordingly.
This is what Linux pcmcia-cs-3.1.19 does by default.
This fixes unconfigured pccbb interrupt problem of
Sharp Mebius MN-5500. It's interrupt router is ITExpress Inc. IT8330G.
(http://www.ite.com.tw/, vendor=0x1283, product=0x8330)
Problem reporeted by Kitagawa <sk@kiu.ac.jp> in
http://www.kaynet.or.jp/~kay/ml/netbsd-pcmcia/msg/msg00608.html
Avoid interpreting the upper 32 bits of 64-bit BARs as a 32-bit BAR.
Otherwise, the code would assume that the value 0 was incorrect and either:
(a) [on bus 0] "fix up" the address to some nonzero value, thus placing
the decoded address range outside of 32-bit address space, or
(b) [elsewhere] completely disable the device.
The fact that this behaviour depends on the bus number of the device is
already XXX'd.
XXX: This will need revisiting if and when we ever want to handle a PCI bus
XXX: with more than 32 bits of address space on an i386.
The onboard Adaptec 7890 on my Dell Precision Workstation 410 works again.
thorpej