Before introducing the programming details, let’s review how a DMA transfer takes place, considering only input transfers to simplify the discussion.

Data transfer can be triggered in two ways: either the software asks for data (via a function such as read) or the hardware asynchronously pushes data to the system.

In the first case, the steps involved can be summarized as follows:

Sometimes DMA is used asynchronously. This happens, for example, with those data acquisition devices that go on pushing data even if nobody is reading it. In this case, the driver should maintain a buffer so that a subsequent read call will return all the accumulated data to user space. The steps involved in this kind of transfer are slightly different:

The processing steps in both cases above emphasize that efficient DMA handling relies on interrupt reporting. While it is possible to implement DMA with a polling driver, it wouldn’t make sense, as a polling driver would waste the performance benefits that DMA offers over the easier processor-driven I/O.

Another relevant item introduced here is the DMA buffer. To exploit Direct Memory Access, the device driver must be able to allocate a special buffer, suited to DMA. Note that most drivers allocate their buffer at initialization time and use it until shutdown--the word ``allocate'' in the lists above therefore means ``get hold of the previously allocated buffer.''

The main problem with the DMA buffer is that when it is bigger than one page, it must occupy contiguous pages in physical memory, because the device transfers data using the ISA or PCI system bus, both of which carry physical addresses. It’s interesting to note that this constraint doesn’t apply to the Sbus (see Section 15.4 in Chapter 15), which uses virtual addresses on the peripheral bus.

Although DMA buffers can be allocated either at system boot or at run time, modules can only allocate their buffers at run time. Chapter 7 introduced these techniques: Section 7.4 talks about allocation at system boot while Section 7.1 and Section 7.2 describe allocation at run time. If you use kmalloc you must specify GFP_DMA priority, bitwise-ORed with either GFP_KERNEL or GFP_ATOMIC.

It is GFP_DMA that requires the memory space to be suitable for DMA transfers. The kernel guarantees that DMA-capable buffers have two features. First, the physical addresses must be consecutive when get_free_page returns more than one page (but this is always true, independent of GFP_DMA, because the kernel arranges free memory in clusters of consecutive pages). And second, when GFP_DMA is set, the kernel guarantees that only addresses lower than MAX_DMA_ADDRESS are returned. The macro MAX_DMA_ADDRESS is set to 16MB on the PC, to deal with the ISA constraints described later.

As far as PCI is concerned, there’s no MAX_DMA_ADDRESS limit, and a PCI device driver should avoid setting GFP_DMA when allocating its buffers.

dmabuf = vremap( 0x1F00000 /* 31MB */, 0x100000 /* 1MB */);

When dealing with DMA, the device driver has to talk to hardware connected to the interface bus, which uses physical addresses, whereas program code uses virtual addresses.

As a matter of fact, the situation is slightly more complicated than that. DMA-based hardware uses bus, rather than physical, addresses. While ISA and PCI addresses are the same as physical addresses on the PC, this is not true for every platform. Sometimes the interface bus is connected through bridge circuitry that maps I/O addresses to different physical addresses.

The Linux kernel provides a portable solution by exporting the following functions, defined in <asm/io.h>:

unsigned long virt_to_bus(volatile void * address);
void * bus_to_virt(unsigned long address);

The virt_to_bus conversion must be used when the driver needs to send address information to an I/O device (such as an expansion board or the DMA controller), while bus_to_virt must be used when address information is received from hardware connected to the bus.

If you look at code that relies on the allocator engine described earlier, you’ll find a sample use of these functions. The code relies also on vremap because of the context:

/* the allocator returns a physical address */
dev->dmabuffer = allocator_allocate_dma(kilobytes, GFP_KERNEL);
/* map it in the virtual address space */
dev->dmavbuffer = vremap(dev->dmabuffer, kilobytes*1024);

/* ... */

/* pass the address to the device */
writel(virt_to_bus(dev->dmavbuffer,
                   dev->registers + DEV_DMA_ADDRESS);

Although they are not related to DMA, the kernel exports two additional functions that perform address conversion and are worth knowing about:

unsigned long virt_to_phys(volatile void * address);
void * phys_to_virt(unsigned long address);

These functions convert virtual addresses to physical addresses; they are needed when the program code needs to talk to a Memory Management Unit (MMU) or other hardware connected to the address lines of the processor. On the PC platform the two pairs of functions accomplish the same task; keeping them as separate functions is nonetheless important, both for code clarity and portability.

The ISA bus allows for two kinds of DMA transfers: ``native'' DMA uses standard DMA-controller circuitry on the mainboard to drive the signal lines on the ISA bus; ISA-busmaster DMA, on the other hand, is completely controlled by the peripheral device. The latter type of DMA is rarely used and doesn’t deserve discussion here because it is similar to DMA for PCI devices, at least from the driver’s point of view. An example of an ISA busmaster is the 1542 SCSI controller, whose driver is drivers/scsi/aha1542.c in the kernel sources.

As far as ``native'' DMA is concerned, there are three entities involved in a DMA data transfer on the ISA bus:

The original DMA controller used in the PC could manage four ``channels.'' Each channel is associated with one set of DMA registers, so that four devices can store their DMA information in the controller at the same time. Newer PCs contain the equivalent of two DMAC devices:^[35] the second controller (the master) is connected to the system processor, and the first (the slave) is connected to channel 0 of the second controller.^[36]

The channels are numbered from 0 to 7; channel 4 is not available to ISA peripherals because it is used internally to ``cascade'' the slave controller onto the master. The available channels are thus 0-3 on the slave (the 8-bit channels) and 5-7 on the master (the 16-bit channels^[37]). The size of any DMA transfer, as stored in the controller, is a 16-bit number representing the number of bus cycles. The maximum transfer size is therefore 64KB for the slave controller and 128KB for the master.

Since the DMA controller is a system-wide resource, the kernel helps deal with it. It uses a DMA registry to provide a request and free mechanism for the DMA channels and a set of functions to configure channel information in the DMA controller.

int request_dma(unsigned int channel, const char *name); 
void free_dma(unsigned int channel);

int dad_open (struct inode *inode, struct file *filp)
{
    struct dad_device *my_device; 

    /* ... */
    if ( (error = request_irq(my_device.irq, dad_interrupt,
                              SA_INTERRUPT, "dad", NULL)) )
        return error; /* or implement blocking open */

    if ( (error = request_dma(my_device.dma, "dad")) ) {
        free_irq(my_device.irq, NULL);
        return error; /* or implement blocking open */
    }
    /* ... */
    return 0;
}

void dad_close (struct inode *inode, struct file *filp)
{
    struct dad_device *my_device;

    /* ... */
    free_dma(my_device.dma);
    free_irq(my_device.irq, NULL);
    /* ... */
}

merlino% cat /proc/dma
 1: Sound Blaster8
 4: cascade

int dad_dma_prepare(int channel, int mode, unsigned int buf,
                        unsigned int count)
{
    unsigned long flags;

    save_flags(flags);
    cli();
    disable_dma(channel);
    clear_dma_ff(channel);
    set_dma_mode(channel, mode);
    set_dma_addr(channel, virt_to_bus(buf));
    set_dma_count(channel, count);
    enable_dma(channel);
    restore_flags(flags);

    return 0;
}

int dad_dma_isdone(int channel)
{
    return (get_dma_residue(channel) == 0);
}

The PCI implementation of DMA is much easier to handle than the ISA version.

PCI supports multiple bus-masters, and DMA reduces to bus-mastering. The device that needs to read or write main memory simply requests control of the bus and then directly controls the electrical signals. The PCI implementation is more elaborate at the hardware level and easier to manage in the device driver.

Programming a DMA transfer with PCI consists of the following steps:

As you can see, there’s no general code used to program DMA for a PCI device. A typical implementation looks like the following one, but every device is different, and the amount of configurable information varies greatly between devices.

int dad_dma_prepare_pci(int mode, unsigned long buf,
                        unsigned int count)
{
    unsigned long addr = virt_to_bus(buf);
        

    writeb(DAD_CMD_DISABLEDMA, DAD_COMMAND);
    writeb(mode, DAD_COMMAND); /* either DAD_CMD_RD or DAD_CMD_WR */
    writel(addr, DAD_DMA_BUFFER);
    writel(count>>2, DAD_DMA_COUNT); /* each transfer is 32 bits */
    writeb(DAD_CMD_ENABLEDMA, DAD_COMMAND);

    return 0;
}