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.
gets used if nothing else is defined in MD headers,
introduce a "PCI_MACHDEP_ENUMERATE_BUS" CPP definition which can
be used by MD headers (just 1 port atm) to plug in special code
- defer access to interrupt configuration register, as its existence depends on
HDRTYPE.
- add "skip particular funtion in multifunction device" functionality
to quirk table.
- add GEODE/NS SC1100 quirk (now boots on soekris Net4801).
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.
int pci_set_powerstate(pci_chipset_tag_t pc, pcitag_t tag, int newstate)
set power state of the device to newstate.
int pci_get_powerstate(pci_chipset_tag_t pc, pcitag_t tag)
get current power state of the device.
In the future, these functions will be used for ACPI support.
pci-pci bridge (and thus needs its interrupts "swizzled").
Formerly, pci_probe_device() assumed pci busses other than bus zero
were bridged; however, much recent x86 hardware supports multiple
primary pci busses differently -- there is a system-wide bus numbering
scheme. Now, we instead look at the (newly introduced) sc_bridgetag
value in the parent bus to figure out if there's a ppb or equivalent
in the way.
This fixed at least one case where the i386 MP branch gets interrupt
mapping wrong.
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.
for a device into two functions:
* pci_probe_device() actually probes/attaches the device specified
by the provide pcitag_t.
* pci_enumerate_bus() enumerates the bus, and calls pci_probe_device()
for each device on the bus. A pci_enumerate_bus_generic() is provided
which implements the old method of doing this: If something found at
dev0/func0, determine number of functions and probe each one.
Machine-dependent code will be able to specify the bus enumeration
routine in the future.
If __PCI_DEV_FUNCORDER is defined, don't do the song-and-dance to check if
a device is multi-function; machdep code is going to tell us exactly which
functions to probe.
Note this required changing how pci_func_devorder() works in the
sparc64 PCI machdep code; now the "curnode" is assumed to point
to the bus, rather than some function (typically 0) on the device,
just as pci_bus_devorder() makes that assumption.
All this should allow the PCI code to actually locate the second
HME device on a Sun Netra t1, which is at 3,1 -- previously, the
PCI code would have missed it because there is no device at 3,0.
(Sun deserves a brick to the head for this one -- this seems clearly
out of line with the PCI spec.)
function on all (probed) PCI buses:
int pci_find_device(struct pci_attach_args *pa,
int (*match)(struct pci_attach_args *));
The pci_attach_args structure pointed to by pa is filled in if the
device is found, and 1 is returned. Otherwise 0 is returned.
This function is, unfortunately, needed by the i810 agp code. It's
also of use for LKMs.
Also frob pci_probe_bus to take 2 extra args when used by pci_find_device.
pci_dev_funcorder() that have the following signatures:
int pci_bus_devorder(pci_chipset_tag_t pc, int bus, char list[32]);
int pci_dev_funcorder(pci_chipset_tag_t pc, int bus, int device, char list[8]);
they control the order of PCI bus probe at the device and function level,
by filling in a value from 0 to 31 for pci_bus_devorder() or 0 to 7 for
pci_dev_funcorder, with a value of -1 to signify no more entries.
when device properties arrive, these will be replaced with some facility
based on properties (design/implementation unknown currently.)
pci_config_dump variable to 1. otherwise, it gets set to 0. If
that's set, when configuring PCI devices spew the very verbose
configuration space header dump that was previously "#if 0"'d.
If you use this option, or patch the variable to 1, it's strongly
encouraged that you have used the MSGBUFSIZE option to enlarge the
kernel message buffer.
perry