DMA Model

The Solaris 7 device driver interface/driver-kernel interface provides a high-level, architecture-independent model for DMA. This allows the framework (the DMA routines) to hide such architecture-specific details as:

• Setting up DMA mappings

• Building scatter-gather lists

• Ensuring I/O and CPU caches are consistent

There are several abstractions that are used in the DDI/DKI to describe aspects of a DMA transaction. These include:

• DMA object - Memory that is the source or destination of a DMA transfer.

• DMA handle - An opaque object returned from a successful ddi_dma_alloc_handle(9F)call. The DMA handle is used in successive DMA subroutine calls to refer to the DMA object.

• DMA cookie - A ddi_dma_cookie(9S) structure (ddi_dma_cookie_t) describes a contiguous portion of a DMA object that is entirely addressable by the device. It contains DMA addressing information required to program the DMA engine.

Rather than knowing that a platform needs to map an object (typically a memory buffer) into a special DMA area of the kernel address space, device drivers instead allocate DMA resources for the object. The DMA routines then perform any platform-specific operations needed to set the object up for DMA access. The driver receives a DMA handle to identify the DMA resources allocated for the object. This handle is opaque to the device driver; the driver must save the handle and pass it in subsequent calls to DMA routines, but should not interpret it in any way.

Operations are defined on a DMA handle that provide the following services:

• Manipulating DMA resources

• Synchronizing DMA objects

• Retrieving attributes of the allocated resources