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.
of functions on a given device. Also, clean up the #if 0'd
major-debugging-spew code so that it's all one piece, so that
it's a bit prettier, and so that it prints out quirk information.
lots of data, e.g. ~18k on a PCI system with few add-in devices; use
with MSGBUFSIZE=...). Useful to have here so that people who want as
much data about the PCI configuration in a machine can get it without
having to craft their own code. Also, clean up a few of the other
#if 0'd printfs.
ID) when determining if the Vendor ID is invalid. The spec says that
Vendor ID of 0xffff is invalid, so, it doesn't _matter_ what the product
ID is in that case. Treat Vendor ID 0 as invalid because we always have.
arguments, so that a device can tell if its memory and I/O spaces are
enabled. The flags are cleared, depending on the contents of devices CSR
registers, in the machine-independent PCI bus code.
that their child busses can be attached after the PCI bus
autoconfiguration for their parent bus is done.
This works because:
(1) there can be at most one ISA/EISA bridge per PCI bus, and
(2) any ISA/EISA bridges must be attached to primary PCI
busses (i.e. bus zero).
That boils down to: there can only be one of these outstanding
at a time, it is cleared when configuring PCI bus 0 before any
subdevices have been found, and it is run after all subdevices
of PCI bus 0 have been found.
This (or something like it) is needed because there are some (legacy)
PCI devices which can show up as ISA/EISA devices as well (the prime
example of which are VGA controllers). If you attach ISA from a
PCI-ISA/EISA bridge, and the bridge is seen before the video board is,
the board can show up as an ISA device, and that can (bogusly)
complicate the PCI device's attach code, or make the PCI device not be
properly attached at all.
This could be done with machine-dependent code, but as more ports
add support for PCI (and PCI-ISA/EISA bridges) more will need it.
The i386 port could (perhaps should) be converted to use it as well.
perry