我正在移植/調試設備驅動程序（由另一個內核模塊使用）並面臨死衚衕，因爲dma_sync_single_for_device（）失敗並伴隨內核oops。從哪裏開始學習有關Linux DMA /設備驅動程序/內存分配
我不知道該功能應該做什麼，並且使用谷歌搜索並沒有真正的幫助，所以我可能需要更多地瞭解這個東西。
問題是，從哪裏開始？
噢，如果它是相關的，則代碼應該在一個PowerPC上運行（以及Linux是的OpenWRT）
編輯： 在線資源preferrable（書籍需要幾天時間交付:)
在線：
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
博OKS：
Linux Kernel Development (2nd Edition)
Essential Linux Device Drivers（只有第4 - 5章）
有用的資源：
the Linux Cross Reference（檢索內核源代碼的所有內核）
API changes in the 2.6 kernel series
dma_sync_single_for_device調用dma_sync_single_range_for_cpu文件中遠一點起來，這是源文件（我認爲即使這是對ARM的界面和行爲是一樣的）：
/**
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 */
的章節Linux Device Drivers書（與@Matthew Flaschen推薦的理解Linux內核系列相同）可能很有用。
您可以從LWN Website下載獨立章節。 Chapter 16涉及DMA。
可能有助於獲得哎呀回溯（以符號形式）。這不應該發生，因爲你可能猜到了。最有可能的原因是它在同一個DMA區域被調用兩次。 – 2010-03-03 08:42:05
其實，我想我會發佈一個關於這個問題的新問題（因爲問題發生在2.6.30.10，而不是在2.6.23） – Kimvais 2010-03-03 09:52:21