The Peripheral Component Interconnect (PCI) is a bus architecture that is generally cheaper and faster than some older bus architectures (see ``Bus'').
Specifications for the PCI architecture are available from the PCI Special Interest Group. Telephone 1-800-433-5177 within the United States, or 1-503-696-8448 from other locations. The following specifications are available:
DDI supports PCI devices through the autoconfiguration feature; see ``Autoconfiguration''. The cm_params(D5) manual page lists several autoconfiguration parameters that query information about the PCI bus. The pci(D5) manual page describes the layout for the configuration space of PCI devices.
Drivers should use the cm_getval(D3) function to access information about the parameters documented on the cm_params(D5) manual page; drivers written for DDI 8 and later versions must enclose the call to cm_getval( ) with calls to the cm_begin_trans(D3) and cm_end_trans(D3) functions. To access information about parameters that are not listed on cm_params(D5) (typically vendor-specific parameters), use the cm_read_devconfig(D3) function.
Drivers for PCI devices are expected to be able to share interrupts with other drivers for other PCI devices and should be coded appropriately. Consequently, they must specify ITYPE=4 in their System(DSP/4dsp) files. See ``Interrupt sharing''.
To dump the PCI configuration space for all configured devices from the SVR5 command line, use the ndcfg command as in the following:
echo resmgr | ndcfg -qIf you have the NFB packages from the HDK installed, you can also use the following command:
echo pcilong | ndcfg -q
Pure DDI drivers can only access the board IDs and CLASSxx information from their Drvmap(DSP/4dsp) files. MDI drivers for LAN and ISDN network devices specify the BOARD_ID s= field, which ndcfg uses when autodetecting the device, so both the board IDs and the subsystem board IDs are accessed. ndcfg then passes this information to the netcfg utility, which displays the configuration information to the user.
ODDI versions 3 and later (for SCO OpenServer 5 Release 5.0.0 and later) provides new kernel functions that are used to obtain hardware configuration information from devices on the PCI bus:
|pci_buspresent(D3oddi)||determine the presence of a PCI bus.|
|pci_findclass(D3oddi)||find a PCI device given its class code.|
|pci_finddevice(D3oddi)||find a PCI device given its vendor and device IDs.|
|pci_readbyte(D3oddi)||read a byte from PCI configuration space.|
|pci_readword(D3oddi)||read a word from PCI configuration space.|
|pci_readdword(D3oddi)||read a 32-bit (double word) from PCI configuration space.|
|pci_search(D3oddi)||search PCI busses for a device matching specified fields.|
|pci_specialcycle(D3oddi)||generate a PCI special cycle.|
|pci_writebyte(D3oddi)||write a byte to PCI configuration space.|
|pci_writeword(D3oddi)||write a word to PCI configuration space.|
|pci_writedword(D3oddi)||write a 32-bit (double word) to PCI configuration space.|
|pci(D4oddi)||pci structure definitions|
Use the archtobus(D3oddi) function to extract the bus type (AT/EISA or MCA) from the current architecture or the pci_buspresent(D3oddi) function to determine if a PCI bus is configured. Because a system can have a PCI bus in combination with any other bus type, driver writers must use both functions in drivers that support both PCI and non-PCI cards.
To support PCI buses on operating systems that only support ODDI versions prior to version 3, you must supply your own interface routines.
Note that the acronym ``PCI'' is also used for the SCO OpenServer 5 libpc.a API, which is in no way related to the PCI bus.