7

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

Kimvais
  • 38,306
  • 16
  • 108
  • 142
  • Might help to have the oops traceback (in symbolic form). That isn't supposed to happen, as you probably guessed. Most likely reason is that it's getting called twice on the same DMA region. – Andrew McGregor Mar 03 '10 at 08:42
  • Actually, I think I'll post a new question about this (as the problem happens with 2.6.30.10, but not on 2.6.23) – Kimvais Mar 03 '10 at 09:52

3 Answers3

11

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 */
Robert S. Barnes
  • 39,711
  • 30
  • 131
  • 179
5

Understanding The Linux Kernel?

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
3

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.

Robert Christie
  • 20,177
  • 8
  • 42
  • 37