Specifications

This is the Title of the Book, eMatter Edition

456

Chapter 15: Memory Mapping and DMA

/* ... */

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;

}

The close implementation that matches the open just shown looks like this:

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);

/* ... */

}

Here’s how the /proc/dma file looks on a system with the sound card installed:

merlino% cat /proc/dma

1: Sound Blaster8

4: cascade

It’s interesting to note that the default sound driver gets the DMA channel at system

boot and never releases it. The

cascade entry is a placeholder, indicating that chan-

nel 4 is not available to drivers, as explained earlier.

Talking to the DMA controller

After registration, the main part of the driver’s job consists of configuring the DMA

controller for proper operation. This task is not trivial, but fortunately, the kernel

exports all the functions needed by the typical driver.

The driver needs to configure the DMA controller either when read or write is called,

or when preparing for asynchronous transfers. This latter task is performed either at

open time or in response to an ioctl command, depending on the driver and the pol-

icy it implements. The code shown here is the code that is typically called by the read

or write device methods.

This subsection provides a quick overview of the internals of the DMA controller so

you understand the code introduced here. If you want to learn more, we’d urge you

to read <asm/dma.h> and some hardware manuals describing the PC architecture. In

,ch15.13676 Page 456 Friday, January 21, 2005 11:04 AM