The Solaris Device Driver Interface/Driver-Kernel Interface (DDI/DKI) 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 that 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 can be used in subsequent DMA subroutine calls to refer to such DMA objects.
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