PATH ADC Home > Documentation > Hardware > Device Managers and Drivers > PCI Card Services > Designing PCI Cards and Drivers for Power Macintosh Computers

Interrupt Model

Interrupt dispatching and control hardware may be designed in a variety of styles and capabilities. In some hardware systems, software must do most of the work of determining which devices that generate interrupts need to be serviced and in what order the system must service them. Other hardware systems may contain specific vectorization and priority schemes that force the software to respond in predetermined ways.

Designing a driver so that it can respond to the details of every interrupt mechanism in every hardware system limits the driver's portability and increases its complexity. As a result, the native driver interrupt model for PCI-based Macintosh computers was introduced and replaces the traditional interrupt-handling mechanisms used in previous Macintosh computers without a PCI bus. This new model provides a more standardized execution environment for interrupt processing by using two key strategies:

The native driver model formalizes the concept of hardware and secondary interrupt levels for processing interrupts. Hardware interrupt level execution happens as a direct result of a hardware interrupt request. Secondary interrupt level provides a way to defer noncritical interrupt processing until after all hardware interrupts have been serviced, thereby reducing hardware interrupt latency.
The control and propagation of hardware interrupts are abstracted from the driver software. An interrupt source for a device is represented by a node in a hierarchical tree, called an interrupt source tree (IST). Generally the leaf nodes of the tree represent interrupt sources for devices and the parent nodes represent dispatching or demultiplexing points. This removes the need for drivers to respond in detail to hardware interrupt mechanisms; they need only contain interrupt-handling code specific to the devices they control. Driver writers no longer need to know how interrupts are multiplexed by a particular hardware platform (such as through versatile interface adapters [VIAs), or handle CPU-specific low memory interrupt vectors.

IMPORTANT

A consequence of abstracting the interrupt-handling process from its hardware implementation is that interrupt service routines (ISRs) may be called when their devices did not cause the interrupt. To minimize processing overhead, each interrupt service routine must quickly determine if it is needed and return immediately if it is not.

A rule that native drivers can follow to minimize interrupt processing overhead is as follows: When a driver determines that its associated device did not generate an interrupt, return kIsrIsNotComplete. If a driver does not know if its device generated an interrupt, return kIsrIsComplete. The interrupt dispatch handler will determine if the device is still issuing and interrupt and continue searching until is finds a match to service the interrupt. A discussion about how kIsrIsComplete and kIsrIsNotComplete are used can be found in Interrupt Dispatching.

A more detailed description of interrupt concepts follows.