1. DMA讀到舊數(shù)據(jù)根子出在Cache一致性做過嵌入式Linux驅(qū)動的人多半都遇到過這種詭異場景中斷明明對了DMA的描述符狀態(tài)字也確實更新了但CPU去讀接收緩沖區(qū)時拿到的卻是上一次甚至更早的陳舊數(shù)據(jù)。發(fā)送方向也一樣數(shù)據(jù)明明通過CPU寫進了buffer外設(shè)收到的卻是幾個節(jié)拍之前的舊內(nèi)容。排了半天指針錯誤、地址錯位最后才意識到是Cache在搗鬼。把這句話擺在最前面沒有硬件Cache一致性機制的平臺DMA繞過CPU緩存直接訪問物理內(nèi)存而CPU寫數(shù)據(jù)時可能只落在Cache里還沒寫回內(nèi)存DMA讀到的自然就是舊數(shù)據(jù)DMA寫進來的內(nèi)容也可能被CPU緩存里的舊副本擋住讓CPU看不到新數(shù)據(jù)。這幾乎是每個非一致性DMA系統(tǒng)都會踩的坑。這篇文章會先講清楚為什么會這樣再給出我實際處理這類問題最常用的三招正確使用DMA映射API自動刷Cache、手動Cache維護配合內(nèi)存屏障、以及直接分配一致性DMA緩沖區(qū)。這套方法既支持Linux驅(qū)動也適合裸機環(huán)境參考。內(nèi)容偏ARM嵌入式方向x86和其他自帶IO一致性DMA的平臺可以直接跳到后面看如何判斷。1.1 為什么硬件Cache會讓DMA犯糊涂現(xiàn)代CPU一般有L1/L2甚至L3 Cache。Cache的存在是為了讓CPU快速訪問高頻使用的數(shù)據(jù)。但在DMA場景下CPU和DMA是兩個“看不見彼此”的訪存發(fā)起方。CPU日常讀寫內(nèi)存時往往不是在改物理內(nèi)存而是在改Cache。采用write-back策略的Cache只有在Cache行被替換、手動Clean或硬件事件觸發(fā)時才會把臟數(shù)據(jù)回寫到內(nèi)存。也就是說CPU說“我寫好了”數(shù)據(jù)的真正歸宿可能還在Cache里躺著。DMA控制器通常直接掛在內(nèi)存總線上它不知道CPU的Cache里有什么也不會先看一眼Cache再去訪問內(nèi)存。于是在兩個方向都出問題發(fā)送場景CPU → DMA → 外設(shè)CPU往緩沖區(qū)寫數(shù)據(jù)Cache中產(chǎn)生臟行。DMA從物理內(nèi)存直接讀讀到的自然還是老數(shù)據(jù)。接收場景外設(shè) → DMA → CPUDMA把新數(shù)據(jù)寫進物理內(nèi)存但CPU之前可能讀過這塊緩沖區(qū)Cache里保留了舊副本。CPU去讀緩沖區(qū)命中的是Cache里的舊數(shù)據(jù)DMA剛寫入的新內(nèi)容被無視了。用個粗糙但好懂的類比CPU是秘書手邊有一堆“桌面草稿”Cache正式檔案存放在“文件柜”內(nèi)存。DMA是另一個部門只認(rèn)文件柜里的版本。秘書改了一版文件只放在桌上沒有歸檔DMA來取的時候拿到的當(dāng)然還是舊版反過來DMA把新版本放進文件柜秘書卻還盯著桌上的舊草稿自然也對不上。1.2 先確認(rèn)你的SoC到底要不要處理Cache一致性很多人一上來就常規(guī)性地刷Cache其實第一步應(yīng)該是查硬件的Cache一致性機制。部分現(xiàn)代SoC比如帶CCI/CMN總線的ARM高性能平臺或者x86架構(gòu)配合IOMMU、PCIe硬件SnoopDMA訪問已經(jīng)做到了硬件級一致。也就是說DMA操作同樣會參與CPU Cache的一致性協(xié)議硬件會自動做“監(jiān)聽”不需要軟件刷Cache。在這種平臺上如果你還是傻乎乎地每次收發(fā)都做clean/invalidate不僅白白損耗性能還可能把狀態(tài)搞壞。舉個真實踩過的例子某平臺手冊里寫了DMA引擎能自動監(jiān)聽L2 Cache驅(qū)動里卻保留了早期的刷Cache邏輯結(jié)果每次收發(fā)都會偶發(fā)“描述符狀態(tài)異?！比サ羰謩铀ache之后一切恢復(fù)。問題不在刷的動作而在于多余的操作破壞了硬件管理的一致性視圖。判斷方法一是查芯片參考手冊里的Memory Coherency或DMA章節(jié)二是看內(nèi)核設(shè)備樹里對應(yīng)設(shè)備節(jié)點是否有dma-coherent屬性。dma-coherent表示該設(shè)備DMA與Cache保持一致Linux這一側(cè)的通用DMA API會對應(yīng)走捷徑驅(qū)動代碼里不需要再做同步操作。如果你確定板子硬件不具備一致性能力再繼續(xù)往下看三招都基于“非一致性系統(tǒng)”這個前提。2. 第一招用DMA映射API按方向自動刷CacheLinux內(nèi)核的DMA API其實是把最標(biāo)準(zhǔn)的做法寫進了規(guī)范里。只要在合適的時機、按正確的方向調(diào)用dma_map_single和dma_unmap_singleCache維護這個臟活就交給內(nèi)核去辦了。這也是我在驅(qū)動里優(yōu)先推薦的方法。因為它不要求你自己動手寫任何刷Cache的底層操作只要守規(guī)矩就能保證CPU和DMA雙方都看到正確數(shù)據(jù)。2.1 DMA_TO_DEVICE 和 DMA_FROM_DEVICE 的正確姿勢搞清楚方向最重要。內(nèi)核DMA API用direction參數(shù)表達的是數(shù)據(jù)的“最終流向”DMA_TO_DEVICE數(shù)據(jù)由CPU寫入內(nèi)存然后由設(shè)備通過DMA讀取。對應(yīng)發(fā)送路徑。DMA_FROM_DEVICE數(shù)據(jù)由設(shè)備通過DMA寫入內(nèi)存然后由CPU讀取。對應(yīng)接收路徑。對應(yīng)到Cache操作上方向傳輸前傳輸后說明DMA_TO_DEVICE需要把CPU在Cache中寫入的臟數(shù)據(jù)Clean回內(nèi)存不需要額外操作DMA讀內(nèi)存不會改內(nèi)存關(guān)鍵是啟動DMA前讓數(shù)據(jù)真正落到RAMDMA_FROM_DEVICE需要處理Cache中的舊數(shù)據(jù)防止臟寫回覆蓋DMA內(nèi)容需要Invalidate CacheCPU再讀時才會取內(nèi)存中的新數(shù)據(jù)接收完成后必須讓CPU的Cache失效因此dma_map_single在傳輸前調(diào)用dma_unmap_single在傳輸完成后調(diào)用內(nèi)核會根據(jù)direction完成上述Cache維護。別小看API這套約定很多問題恰恰是調(diào)用時機錯了。一個規(guī)范的發(fā)送流程是這樣/* 發(fā)送 */ void *buffer ctx-tx_buf; size_t len packet_len; dma_addr_t dma_handle; memcpy(buffer, data, len); dma_handle dma_map_single(ctx-dev, buffer, len, DMA_TO_DEVICE); if (dma_mapping_error(ctx-dev, dma_handle)) { dev_err(ctx-dev, dma_map_single failed\n); return -EIO; } /* 把dma_handle和len寫到設(shè)備寄存器然后啟動傳輸 */ writel(len, ctx-regs TX_LEN); writel(dma_handle, ctx-regs TX_ADDR); writel(CTRL_START, ctx-regs TX_CTRL); /* 記住dma_handle傳輸完成中斷里做unmap */ ctx-tx_dma dma_handle; ctx-tx_len len;/* 發(fā)送完成中斷 */ if (status TX_DONE) { dma_unmap_single(ctx-dev, ctx-tx_dma, ctx-tx_len, DMA_TO_DEVICE); }接收流程要區(qū)分兩個階段。啟動接收時需要先把緩沖區(qū)map好傳輸完成后在中斷或tasklet里unmap并invalidate/* 接收前 */ dma_addr_t rx_dma; rx_dma dma_map_single(ctx-dev, ctx-rx_buf, RX_BUF_SIZE, DMA_FROM_DEVICE); writel(ctx-rx_buf_len, ctx-regs RX_LEN); writel(rx_dma, ctx-regs RX_ADDR); writel(CTRL_START, ctx-regs RX_CTRL); /* 接收完成中斷 */ if (status RX_DONE) { dma_unmap_single(ctx-dev, ctx-rx_dma, ctx-rx_len, DMA_FROM_DEVICE); /* 到這里rx_buf里的數(shù)據(jù)才是DMA寫進來的新數(shù)據(jù) */ process_packet(ctx-rx_buf, ctx-rx_len); }這里有個非常容易犯的錯在調(diào)用dma_map_single之后到dma_unmap_single之前CPU不能隨意訪問這塊緩沖區(qū)。API建立的是一個“外設(shè)訪問期”這期間CPU再寫緩沖區(qū)內(nèi)存里的數(shù)據(jù)是否最新就沒人能保證了。有些新手在map后還往buffer里memcpy結(jié)果DMA傳出去的還是舊內(nèi)容排查半天發(fā)現(xiàn)是訪問序違規(guī)。2.2 高頻傳輸時的替代方案dma_sync_single_for_cpu/device有人會問每次收發(fā)都map/unmap開銷是不是大了點對于高頻小包場景確實如此。尤其是有IOMMU的平臺map/unmap還涉及頁表操作頻繁調(diào)用代價不可小覷。這時可以用同步API替代反復(fù)map/unmap。思想是把map/unmap只看作“建立/釋放設(shè)備對內(nèi)存訪問權(quán)限”的過程而把Cache維護用dma_sync_single_for_cpu和dma_sync_single_for_device單獨完成。緩沖區(qū)只映射一次之后每次收發(fā)只做同步。接收路徑典型寫法/* 初始化時映射一次 */ ctx-rx_dma dma_map_single(ctx-dev, ctx-rx_buf, RX_BUF_SIZE, DMA_FROM_DEVICE); /* 每次啟動接收 */ static void arm_rx(struct my_ctx *ctx) { dma_sync_single_for_device(ctx-dev, ctx-rx_dma, RX_BUF_SIZE, DMA_FROM_DEVICE); writel(RX_BUF_SIZE, ctx-regs RX_LEN); writel(ctx-rx_dma, ctx-regs RX_ADDR); writel(CTRL_START, ctx-regs RX_CTRL); } /* 接收完成 */ static void rx_complete(struct my_ctx *ctx) { dma_sync_single_for_cpu(ctx-dev, ctx-rx_dma, RX_BUF_SIZE, DMA_FROM_DEVICE); dma_rmb(); process_packet(ctx-rx_buf, ctx-rx_len); arm_rx(ctx); }注意dma_sync_single_for_device和dma_sync_single_for_cpu只是Cache維護手段并不會像map/unmap那樣建立或釋放IOMMU映射。如果你的設(shè)備沒有IOMMU或者驅(qū)動不需要反復(fù)映射這個方法很適合。這套API最大價值是讓“刷Cache”這件事變得標(biāo)準(zhǔn)化。但它不是萬能鑰匙CPU訪問期和DMA訪問期必須嚴(yán)格交替互不重疊。一旦有一個CPU線程在DMA傳輸過程中插入訪問崩潰和臟數(shù)據(jù)只是一瞬間的事。3. 第二招手動Cache維護加內(nèi)存屏障自己掌控全局Linux API固然方便但有些場景繞不開手動操作老版本內(nèi)核、裸機驅(qū)動、或者需要極細(xì)致控制Cache維護時機的地方。另外面試或者排查問題時懂底層Cache指令也能省很多力氣。這一招的核心是兩件事Cache Clean/Invalidate操作以及配套的內(nèi)存屏障。很多只刷Cache不加屏障的驅(qū)動也能跑但屬于“運氣好”換個CPU、換個總線問題立刻現(xiàn)形。3.1 底層Cache操作接口與調(diào)用位置在ARMv7/ARMv8裸機環(huán)境下Cache維護通常通過協(xié)處理器指令或者CPI段中的Cache操作by MVA完成。例如Clean Cache LineDCCMVAC把臟Cache行回寫內(nèi)存。Invalidate Cache LineDCIMVAC丟棄Cache中的副本。Clean and InvalidateDCCIMVAC。在Linux內(nèi)核里不直接依賴具體指令而是使用封裝好的底層接口比如dmac_map_area、dmac_unmap_area。但更推薦的做法還是用dma_sync_single_*因為它在不同架構(gòu)間有可移植性。這里講手動方式是為了讓你理解API背后發(fā)生了什么。映射到實際操作位置發(fā)送方向在DMA啟動前對緩沖區(qū)做Cleanclean_cache_mva(buffer, len); dma_wmb(); writel(CTRL_START, dev-regs TX_CTRL);接收方向在DMA完成中斷里對緩沖區(qū)做Invalidatedma_rmb(); invalidate_cache_mva(buffer, len); dma_rmb(); process_packet(buffer, len);很多人會把Clean和Invalidate的順序搞反。發(fā)送前該做的是Clean而不是Invalidate接收完成后該做的是Invalidate同時對舊的臟行要先Clean再Invalidate否則臟行數(shù)據(jù)可能還沒來得及回寫就被揚了。3.2 為什么還必須配內(nèi)存屏障內(nèi)存屏障管的是“訪問順序”它和Cache維護是兩回事。我見過太多人把內(nèi)存屏障當(dāng)成刷Cache的替代品加了dma_rmb卻不做invalidate數(shù)據(jù)照樣錯然后百思不得其解。屏障解決的是亂序問題處理器、編譯器、總線都可能對內(nèi)存訪問重新排序。典型例子是發(fā)送方向/* 錯誤示范只寫數(shù)據(jù)不寫屏障 */ memcpy(buffer, data, len); clean_cache_mva(buffer, len); writel(CTRL_START, dev-regs CTRL);如果writel(CTRL_START)被CPU亂序提前執(zhí)行DMA控制器可能在你還沒Clean完成、甚至數(shù)據(jù)還沒完全寫入緩沖區(qū)時就開始傳輸。結(jié)果就是設(shè)備讀到了不完整的包或者讀到了舊值。正確做法是在數(shù)據(jù)準(zhǔn)備和啟動DMA之間插入寫屏障memcpy(buffer, data, len); clean_cache_mva(buffer, len); dma_wmb(); /* 保證clean_cache以及buffer寫入都對DMA引擎可見 */ writel(CTRL_START, dev-regs CTRL);接收方向DMA完成中斷里需要讀屏障if (readl(dev-regs IRQ_STATUS) RX_DONE) { dma_rmb(); /* 確保DMA寫入內(nèi)存的動作已經(jīng)完成且有序可見 */ invalidate_cache_mva(rx_buf, len); dma_rmb(); /* 確保invalidate之后CPU再讀buffer */ process_packet(rx_buf, len); }為什么中斷里還要加dma_rmb因為DMA控制器寫入內(nèi)存是外設(shè)側(cè)的主設(shè)備操作CPU觀察到中斷時DMA的寫如果還沒完全抵達內(nèi)存或總線上仍有排隊寫后續(xù)讀取可能讀到半新不舊的數(shù)據(jù)。屏障可以約束CPU端讀操作的順序這也是內(nèi)核文檔里明確建議的用法。3.3 手動Cache維護時的描述符Ring示例在裸機網(wǎng)絡(luò)驅(qū)動里我們經(jīng)常用描述符Ring管理收發(fā)。描述符本身也是DMA要訪問的內(nèi)存同樣存在Cache一致性問題。一個經(jīng)典做法是描述符數(shù)組放在非Cacheable內(nèi)存區(qū)域這樣CPU每次讀寫描述符都直接訪問RAM不需要維護Cache。但如果你偏要把描述符放在Cacheable內(nèi)存里就得按下面這種模式處理/* 寫發(fā)送描述符然后啟動DMA */ static void prepare_tx_desc(struct my_dev *ctx, int idx, dma_addr_t payload_dma, u32 len) { volatile struct tx_desc *desc ctx-tx_ring[idx]; desc-addr payload_dma; desc-len len; desc-ctrl DESC_VALID | DESC_LAST; /* 確保描述符內(nèi)容先寫入內(nèi)存 */ clean_cache_mva((void *)desc, sizeof(*desc)); dma_wmb(); /* 更新生產(chǎn)者索引讓DMA引擎開始搬運 */ writel((idx 1) % RING_SIZE, ctx-regs TX_PRODUCER); }接收完成同理static void handle_rx_desc(struct my_dev *ctx, int idx) { volatile struct rx_desc *desc ctx-rx_ring[idx]; u32 len; dma_rmb(); invalidate_cache_mva((void *)desc, sizeof(*desc)); dma_rmb(); len desc-actual_len; if (desc-ctrl DESC_DONE) { invalidate_cache_mva(ctx-rx_payload[idx], len); process_packet(ctx-rx_payload[idx], len); } }這樣搞確實繁瑣所以即使裸機驅(qū)動很多老手的做法依然是描述符放Non-Cacheable區(qū)Payload緩存用Cacheable區(qū)只在Payload上做Cache操作。只有非常追求性能、Payload也不大時才把環(huán)形緩沖整體放到手動管理里反復(fù)折騰。4. 第三招直接分配一致性DMA緩沖區(qū)從根上解決如果每次收發(fā)都要刷Cache、加屏障總還是太累了。有沒有一種辦法讓CPU和DMA操作同一塊內(nèi)存時硬件或軟件映射機制自動保證雙方看到的內(nèi)容一致有。這就是一致性DMA映射。Linux下對應(yīng)接口是dma_alloc_coherent和dma_free_coherent。用這個API分配出來的緩沖區(qū)CPU和設(shè)備不用再做Cache維護直接讀直接寫兩邊看到的結(jié)果都是同步的。4.1 dma_alloc_coherent 到底干了什么它的核心思路是把分配給DMA控制器使用的物理內(nèi)存區(qū)域在CPU頁表里映射為“不具備一般Cache緩存屬性”的內(nèi)存。通常是不允許Write-Back Cache緩存或者直接映射為保持“一致性”的硬件域。這樣CPU訪問該緩沖區(qū)時數(shù)據(jù)不只是停留在Cache而是直接落到內(nèi)存DMA訪問時自然也能拿到最新內(nèi)容。在某些支持硬件總線一致性的平臺上dma_alloc_coherent可能分配的仍是Cacheable內(nèi)存但硬件監(jiān)聽機制保證了DMA和CPU共同看到同一份數(shù)據(jù)。無論哪種實現(xiàn)對驅(qū)動代碼來說效果一樣不需要手動Clean/Invalidate。典型用法struct desc_ring { void *virt_base; dma_addr_t dma_base; u32 n_desc; }; static int alloc_desc_ring(struct my_ctx *ctx, struct desc_ring *ring) { ring-virt_base dma_alloc_coherent(ctx-dev, ring-n_desc * sizeof(struct desc), ring-dma_base, GFP_KERNEL); if (!ring-virt_base) return -ENOMEM; memset(ring-virt_base, 0, ring-n_desc * sizeof(struct desc)); return 0; } static void free_desc_ring(struct my_ctx *ctx, struct desc_ring *ring) { dma_free_coherent(ctx-dev, ring-n_desc * sizeof(struct desc), ring-virt_base, ring-dma_base); }分配成功后virt_base是CPU使用的虛擬地址dma_base是DMA引擎使用的物理地址。CPU操作virt_baseDMA操作dma_base共享同一塊物理內(nèi)存。這類內(nèi)存最適合放DMA描述符、環(huán)形隊列索引、硬件狀態(tài)字以及體積不大但訪問頻繁的控制信息塊。下面這段描述符Ring的消費端就用得干干凈凈static bool rx_ring_has_packet(struct my_ctx *ctx) { struct rx_desc *desc ctx-rx_ring_desc[idx]; dma_rmb(); return (desc-ctrl DESC_DONE) ! 0; }這里還需要dma_rmb嗎需要。一致性內(nèi)存解決的是Cache一致性問題但沒解決總線上的讀寫排序問題。DMA引擎寫完描述符后CPU并不保證馬上就能看到中間還有總線緩沖、寫緩沖。用一次dma_rmb確保讀到的是DMA寫入后的最新狀態(tài)。這是很多人的知識盲區(qū)我見過有人把一致性內(nèi)存當(dāng)成完全隔離結(jié)果還是讀到舊描述符狀態(tài)。4.2 哪些場景適合用一致性內(nèi)存哪些并不適合一致性內(nèi)存并不總是優(yōu)于普通內(nèi)存。它的主要代價是CPU訪問性能。如果CPU每次讀寫都直接繞過Cache沖到內(nèi)存那么對于大數(shù)據(jù)量Payload的解析和填充速度會明顯下降。所以實際驅(qū)動里最常見的組合是描述符Ring、狀態(tài)字、生產(chǎn)者/消費者索引這類“控制面”數(shù)據(jù)放一致性內(nèi)存。真正的網(wǎng)絡(luò)包Payload、大文件緩沖區(qū)這類“數(shù)據(jù)面”用普通Cacheable內(nèi)存通過dma_map_single在收發(fā)瞬間做Cache維護。舉個例子某網(wǎng)絡(luò)驅(qū)動里環(huán)形描述符共256項每項64字節(jié)用dma_alloc_coherent分配每個包的數(shù)據(jù)緩沖區(qū)單獨申請用dma_map_single做映射。這樣描述符的讀寫頻率非常高放到一致性內(nèi)存能省下每包都Clean/Invalidate描述符的開銷而Payload動輒幾KBCPU解析時訪存壓力大放Cacheable內(nèi)存再手動管理Cache收益更明顯。有一個容易踩的坑dma_alloc_coherent分配大塊連續(xù)內(nèi)存并不總是成功。它拿的是物理連續(xù)頁面還要滿足一致性內(nèi)存池或CMA分配器的限制。大塊分配失敗時驅(qū)動回退方案要么是改用dma_map_single配合分散頁要么用sg表。所以要分配幾MB甚至幾十MB的視頻幀緩沖別指望一致性內(nèi)存在所有平臺都能輕松給你。5. 實操避坑指南緩存行對齊與調(diào)試驗證很多Cache相關(guān)的問題不是方向搞錯而是對齊問題。Cache維護的基本單位是Cache Line不是字節(jié)。x86常見64字節(jié)ARM Cortex-A系列常見64字節(jié)老一些的ARM可能是32字節(jié)也有個別平臺是128字節(jié)。如果你的DMA緩沖區(qū)和其他變量共用了一個Cache Line那麻煩就大了。5.1 緩存行對齊——最容易翻車的隱藏規(guī)則假設(shè)分配了一個緩沖區(qū)buf從0x1000到0x1010只有16字節(jié)而緊跟著地址0x1010到0x1020里放了一個相鄰變量flag。Cache Line大小64字節(jié)也就是說0x1000到0x1040屬于同一行。CPU之前訪問過flag這個Line被緩存起來了。DMA往buf寫入新數(shù)據(jù)然后CPU對buf做invalidate操作。invalidate是以整個Cache Line為單位的0x1000到0x1040這一行會被直接丟棄。如果flag的數(shù)據(jù)還沒來得及回寫或者CPU后面再從內(nèi)存讀flag內(nèi)存里flag可能是舊值也可能因為臟行丟失而狀態(tài)錯亂。更惡心的是這種問題只在特定地址布局、特定時序下出現(xiàn)看起來完全隨機非常難復(fù)現(xiàn)。解決辦法DMA緩沖區(qū)首地址對齊到Cache Line大小。緩沖區(qū)長度向上對齊到Cache Line整數(shù)倍。不要讓DMA緩沖區(qū)和普通變量共享同一Cache Line區(qū)域。如果DMA只需要操作一段很小的數(shù)據(jù)你依然要給整個Cache Line“買全單”該操作整行就操作整行。Linux內(nèi)核里DMA映射API要求buffer地址按ARCH_DMA_MINALIGN對齊。自定義驅(qū)動里可以結(jié)合平臺信息用dma_get_cache_line_size取到Cache Line大小然后對緩沖做對齊分配。裸機環(huán)境直接用編譯期常量ALIGN即可。一個簡單分配代碼#define CACHE_LINE_SIZE 64 static unsigned char dma_buf[2 * CACHE_LINE_SIZE]; static unsigned char *aligned_buf; aligned_buf (unsigned char *)ALIGN((unsigned long)dma_buf, CACHE_LINE_SIZE);這里的冗余分配就是為了保證即使數(shù)組起始不對齊也能找到一段從Cache Line邊界開始的空間。5.2 打開內(nèi)核DMA調(diào)試開關(guān)讓問題自己浮出來Linux提供了一套嚴(yán)格檢測DMA映射使用錯誤的機制內(nèi)核配置項叫CONFIG_DMA_API_DBUG編進內(nèi)核后通過啟動參數(shù)或sysfs觀察。打開之后它會記錄每次dma_map_*和dma_unmap_*的調(diào)用檢測map/unmap次數(shù)不匹配在映射未釋放時反復(fù)map同一地址使用未映射的地址訪問設(shè)備越界訪問使用了錯誤的direction排查Cache問題時我第一件事就是先開它。它能排除掉“API調(diào)用本身寫錯”的可能避免在錯誤的方向上浪費大量時間。debug信息通常在/sys/kernel/debug/dma-api目錄下。內(nèi)核也會在檢測到問題時打印詳細(xì)堆棧。在設(shè)備驅(qū)動模型里還可以通過dma_debug_driver驅(qū)動名只跟蹤特定設(shè)備的DMA操作。這個過濾在大型系統(tǒng)里很有用否則log會被大量無關(guān)DMA操作淹沒。5.3 常見癥狀速查表現(xiàn)象大概率原因排查方向發(fā)送數(shù)據(jù)偶爾變成舊內(nèi)容重啟后第一次正常DMA啟動前Cache沒Clean或者map后又寫buffer檢查DMA啟動前的clean操作檢查訪問時序接收數(shù)據(jù)永遠(yuǎn)是上一次的內(nèi)容DMA完成后沒有InvalidateCPU命中舊Cache行確認(rèn)接收路徑invalidate是否執(zhí)行接收數(shù)據(jù)偶爾部分正確部分亂Cache Line部分被invalidate殃及相鄰變量檢查緩沖對齊、DMA與變量是否共享Cache Line加了內(nèi)存屏障還是出錯屏障不是刷CacheCache問題沒解決先確保Clean/Invalidate正確再加屏障平臺宣稱非一致性但怎么刷都還是舊數(shù)據(jù)可能是設(shè)備樹標(biāo)了dma-coherent或IOMMU配置導(dǎo)致查設(shè)備樹和IOMMU配置換了CPU或總線頻率后錯誤復(fù)現(xiàn)頻率變化亂序窗口被放大缺少內(nèi)存屏障在DMA啟動/完成路徑補全屏障最直接的驗證方法是把DMA緩沖區(qū)臨時映射為Non-Cacheable或Strongly-Ordered如果問題消失基本坐實是Cache一致性問題。不過要注意這只是排查手段正式方案仍應(yīng)回到上面三招里選型。6. 寫在最后我的幾點體會這類問題真正難的地方不是“刷Cache”這個動作而是你不知道什么時候該刷、哪個方向刷、刷多大范圍。我個人的經(jīng)驗是每接手一個新平臺的DMA驅(qū)動第一件事就是看SoC手冊里DMA Controller和CPU Cache之間有沒有硬件一致機制確認(rèn)之后再決定用哪一招。另外強烈建議在項目早期做一次最簡單的DMA Cache一致性自測分配一塊Cacheable內(nèi)存CPU先寫入一個特征字節(jié)然后啟動DMA去讀再看DMA寫回的特征字節(jié)CPU能否立即讀到。這個測試不到半天就能寫好但能省下后面幾個月的排錯時間尤其是硬件和驅(qū)動同時Debug的階段。如果非要總結(jié)一條最實用的心法那就是CPU和DMA是兩套完全獨立的內(nèi)存視圖你的驅(qū)動代碼就是它們之間的翻譯官。翻譯出錯數(shù)據(jù)自然錯亂。把方向、時機、對齊這三件事刻在腦子里Cache問題再詭異也能一步步拆解到源頭。