Where to start learning about linux DMA / device d

Question

I'm porting / debugging a device driver (that is used by another kernel module) and facing a dead end because dma_sync_single_for_device() fails with an kernel oops.

I have no clue what that function is supposed to do and googling does not really help, so I probably need to learn more about this stuff in total.

The question is, where to start?

Oh yeah, in case it is relevant, the code is supposed to run on a PowerPC (and the linux is OpenWRT)

EDIT: On-line resources preferrable (books take a few days to be delivered :)

Answer 1

The chapters of the Linux Device Drivers book (in the same series as Understanding the Linux Kernel, recommended by @Matthew Flaschen) might be useful.

You can download the indiivudal chapters from the LWN Website. Chapter 16 deals with DMA.

Answer 2

Understanding The Linux Kernel?

Answer 3

On-line:

Anatomy of the Linux slab allocator

Understanding the Linux Virtual Memory Manager

Linux Device Drivers, Third Edition

The Linux Kernel Module Programming Guide

Writing device drivers in Linux: A brief tutorial

Books:

Linux Kernel Development (2nd Edition)

Essential Linux Device Drivers ( Only the first 4 - 5 chapters )

Useful Resources:

the Linux Cross Reference ( Searchable Kernel Source for all Kernels )

API changes in the 2.6 kernel series

---

dma_sync_single_for_device calls dma_sync_single_range_for_cpu a little further up in the file and this is the source documentation ( I assume that even though this is for arm the interface and behavior are the same ):

/**
 380 * dma_sync_single_range_for_cpu
 381 * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
 382 * @handle: DMA address of buffer
 383 * @offset: offset of region to start sync
 384 * @size: size of region to sync
 385 * @dir: DMA transfer direction (same as passed to dma_map_single)
 386 *
 387 * Make physical memory consistent for a single streaming mode DMA
 388 * translation after a transfer.
 389 *
 390 * If you perform a dma_map_single() but wish to interrogate the
 391 * buffer using the cpu, yet do not wish to teardown the PCI dma
 392 * mapping, you must call this function before doing so.  At the
 393 * next point you give the PCI dma address back to the card, you
 394 * must first the perform a dma_sync_for_device, and then the
 395 * device again owns the buffer.
 396 */