Adapter Objects

Adapter Objects

Just as multiple devices on the same controller need to coordinate their hardware access, so it is that devices that perform DMA need an orderly way to share system DMA resources. The I/O Manager uses adapter objects to prevent arguments over DMA hardware. There is one adapter object for each DMA data transfer channel on the system.

Like a controller object, an adapter object can be owned by only one device at a time. Before starting a DMA transfer, the Start I/O routine asks for ownership of the adapter object. If the hardware is free, ownership is granted. If not, the device's request is put on hold until the current owner releases the hardware. Obviously, if the device supports only programmed I/O, it has no need for an adapter object. The life cycle of the adapter object is described below.

1. The HAL creates Adapter objects for any DMA data channels detected at boot time.

2. The DriverEntry or AddDevice routine locates the adapter object for its device and stores that pointer in the device or controller extension. Adapter objects for nonsystem (i.e., bus master) DMA hardware may be created on the fly.

3. The Start I/O routine requests ownership of the adapter object on behalf of a specific device.

4. When ownership is granted, the I/O Manager calls the driver's adapter Control routine. This routine then uses the adapter object to set up a DMA transfer.

5. The driver's DpcForIsr routine may use the adapter object to perform additional operations in the case of a split transfer. When a transfer is finished, DpcForIsr releases the adapter object.

Another important function of the adapter object is to manage mapping registers. The HAL uses these registers to map the standard physical pages of a user's buffer onto the contiguous range of addresses required by most DMA hardware. The complete mechanics of DMA transfers are covered in detail in chapter 12.

Layout of an Adapter Object

Figure 4.5 illustrates the relationship of adapter objects to other structures. As the diagram shows, the adapter object is completely opaque and has no externally visible fields. When working with DMA devices, the pointer to the adapter object, as well as the number of mapping registers it supports, should be stored in the device extension or controller extension structure.

Figure 4.5. The adapter object

Manipulating Adapter Objects

Both the HAL and the I/O Manager export functions that can be used to manipulate adapter objects. Table 4.9 lists the more common adapter functions.

Interrupt Objects

The last kernel object described in this chapter is the interrupt object. Interrupt objects simply give the kernel's interrupt dispatcher a way to find the right service routine when an interrupt occurs. The life cycle of an interrupt object is described below.

1. The DriverEntry or AddDevice routine creates an interrupt object for each interrupt vector supported by the device or the controller.

2. When an interrupt occurs, the kernel's interrupt dispatcher uses the Interrupt object to locate the Interrupt Service routine.

3. The Unload or RemoveDevice routine deletes the interrupt object after disabling interrupts from the device.

A driver does not interact with interrupt objects other than to create and delete them. A pointer to the interrupt object is typically stored in the device extension or controller extension.

Layout of an Interrupt Object

Figure 4.6 illustrates the structure of an interrupt object. Like adapter objects, they are completely opaque and have no externally visible fields.

Figure 4.6. The interrupt object.

Manipulating Interrupt Objects

Several system components export functions that work with interrupt objects. Table 4.10 lists the most common ones.