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