Configuration Information

In contrast to many of its predecessors, the PCI bus is a jumper-free system. In other words, expansion devices can be fully configured by software means and without user intervention.22 To support such configuration, each PCI device has a 256-byte-long configuration space with information on the special characteristics and requirements of the device. Even though 256 bytes may at first appear to be a paltry figure given current memory configuration levels, a large amount of information can be stored, as shown in Figure 6-23, which illustrates the layout of the configuration space as required by the PCI specification.





Figure 6-23: Layout of the PCI configuration space.

Although the structure must be 256 bytes in length, only the first 64 bytes are standardized. The remainder are freely available and are typically used to exchange additional information between the device and the driver. The structure of this information is (or should be) defined in the hardware documentation. It should also be noted that not all information in the first 64 bytes is mandatory; some items are optional and may be filled with zeros if they are not required by a device. The mandatory items are highlighted in darker gray in the figure.

The vendor ID and device ID uniquely identify the vendor and device type. Whereas the former is assigned by the PCI Special Interest Group (an industry consortium) to identify individual companies,23 the latter can be freely selected by the vendors — they alone are responsible for ensuring that there are no overlaps in their address space. Taken together the two IDs are often referred to as the signature of a device. Two additional fields with similar names — subsystem vendor ID and subsystem device ID — may also be used to more accurately describe generic interfaces. The revision ID enables a distinction to be made between various device revision levels. This helps users select device driver versions where known hardware faults have been eliminated or where new features have been added.

The class code field is used to assign devices to various function groups and is split into two parts. The first 8 bits indicate the base class and the remaining 16 bits a subclass of the base class. Examples of base classes and their subclasses are given below (I use the names of the corresponding constants in <pci_ids.h>).

22Some readers may well remember the ISA ''game'' where the cards, mostly miserably documented, were configured by manually adjusting resources by means of jumpers.

Vendor Device ID ID

Cmd Status Reg Reg

CO S —t

Base address 0

Base address 1

Base address 2

Base address 3

Base address 4

Base address 5

CardBus CIS Pointer

Subsystem Vendor ID

Subsystem Device ID




Expansion ROM






base address





Figure 6-23: Layout of the PCI configuration space.

□ Mass storage (pci_base_class_storage)

□ SCSI controller (pci_class_storage_scsi)

□ IDE controller (pci_class_storage_ide)

□ RAID controller (to combine multiple disk drives) (pci_class_storage_raid)

□ Network (pci_base_class_network)

□ Ethernet (pci_base_network_ethernet)


□ System components (pci_base_class_system)

□ DMA controller (pci_class_system_dma)

□ Real-time clock (pci_class_system_rtc)

The six base address fields each comprise 32 bits and are used to define the addresses for communication between the PCI device and the rest of the system. When 64-bit devices are involved (as can happen on Alpha and Sparc64 systems), two base address fields are always merged to describe the position in memory; this halves the number of possible base addresses to three. As far as the kernel is concerned, the only remaining field of any relevance is the IRQ number, which can accept any value between 0 and 255 to specify the interrupt used by the device. A value of 0 indicates that the device does not use interrupts.

Even though the PCI standard supports up to 255 interrupts, the number that can actually be used is generally limited by the specific architecture. Methods such as interrupt sharing (discussed in Chapter 5) must then be employed on such systems to support the use of more devices than there are IRQ lines.

The remaining fields are used by the hardware and not by the software so I won't bother explaining their meanings.

Continue reading here: Implementation in the Kernel

Was this article helpful?

0 0