to avoid references to EISA variables if "pceb" is not defined in
kernel configurations, and save some bytes
tested by Havard Eidnes (or his colleague:-)
which bustype should be attached with a specific call to config_found()
(from a "mainbus" or a bus bridge).
Do it for isa/eisa/mca and pci/agp for now. These buses all attach to
an mi interface attribute "isabus", "eisabus" etc., and the autoconf
framework now allows to specify an interface attribute on config_found()
and config_search(), which limits the search of matching config data
to these which attach to that specific attribute.
So we basically have to call config_found_ia(..., "foobus", ...) where
such a bus is attached.
As a consequence, where a "mainbus" or alike also attaches other
devices (eg CPUs) which do not attach to a specific attribute yet,
we need at least pass an attribute name (different from "foobus") so
that the foo bus is not found at these places. This made some minor
changes necessary which are not obviously related to the mentioned buses.
non-specific EOIs. This really shouldn't matter so much, but I'm guessing
there's a strange interaction with the PALcode (possibly related to the fact
that the PALcode itself may be sending an EOI itself on some systems).
I have tested this on a Multia, and it appears to work just fine without the
INITIALLY_{ENABLED,LEVEL_TRIGGERED}() stuff now, so I'm also removing that.
enabled on amd64). Add a dmat64 field to various PCI attach structures,
and pass it down where needed. Implement a simple new function called
pci_dma64_available(pa) to test if 64bit DMA addresses may be used.
This returns 1 iff _PCI_HAVE_DMA64 is defined in <machine/pci_machdep.h>,
and there is more than 4G of memory.
NULL for root PCI busses. For busses behind a bridge, it points to
a persistent copy of the bridge's pcitag_t. This can be very useful
for machine-dependent PCI bus enumeration code.
* Implement a machine-dependent pci_enumerate_bus() for sparc64 which
uses OFW device nodes to enumerate the bus. When a PCI bus that is
behind a bridge is attached, pci_attach_hook() allocates a new PCI
chipset tag for the new bus and sets it's "curnode" to the OFW node
of the bridge. This is used as a starting point when enumerating
that bus. Root busses get the OFW node of the host bridge (psycho).
* Garbage-collect "ofpci" and "ofppb" from the sparc64 port.
some MI PCI code that uses it, and soon there will be more. (The rationale
for not making it available previously was that it could be mis-used, but
that's true of a lot of things.)
(SCB_VECTOIDX(vec) - SCB_IOVECBASE] -> SCB_VECTOIDX(vec - SCB_IOVECBASE))
Sigh. This is all very good work- this new interrupt stuff. Yet like the
last time my good friend Jason 'simplified' things, we lost information.
It used to be you could tell which specific slot an interrupt was frame
based upon the vector. Now you can't because they're allocated dynamically.
Oh well- it's not all that important.
Rather than an "iointr" routine that decomposes a vector into an
IRQ, we maintain a vector table directly, hooking up each "iointr"
routine at the correct vector. This also allows us to hook device
interrupts up to specific vectors (c.f. Jensen).
We can shave even more cycles off, here, and I will, but it requires
some changes to the alpha_shared_intr stuff.
the kernel to panic since it is recognised as a TGA and the TGA driver
doesn't [yet] know what to do with it.
This patch fixes that by:
o making tgamatch() try to actually figure out what kind
of TGA card is there, rather than simply relying on the
vendor/product ids.
o creating a tga_cnmatch() so that the console code in
arch/alpha/pci/pci_machdep.c can cause the same to occur.
o breaking up some of tga_getdevconfig() into a few different
functions to re-use code that would have been duplicated.
o changed arch/alpha/pci/pci_machdep.c so that it calls out
to tga_cnmatch() if DEVICE_IS_TGA() matches before it decides
to attach the console as a TGA.
Addresses PR: port-alpha/12923
reserving RAM in the bus_mem extent map. Problem pointed
out by Artur Grabowski.
- Work around a slightly annoying bit of behavior exhibited by
the UP1000 firmware. The UP1000 firmware reports the space
consumed by the "ISA hole" in the same MDDT entry as two
chunks of RAM (on either side of the hole) used by the PALcode,
all as one "reserved for PALcode" chunk. We must take this
into account when reserving RAM in the bus_mem extent map.
