DMA記憶體申請--dma_alloc_coherent 及 暫存器與記憶體
在專案驅動過程中會經常用到dma傳輸資料,而dma需要的記憶體有自己的特點,一般認為需要實體地址連續,並且記憶體是不可cache的,在linux核心中提供一個供dma所需記憶體的申請函式dma_alloc_coherent. 如下所述:
dma_alloc_coherent()
dma_alloc_coherent() -- 獲取物理頁,並將該物理頁的匯流排地址保存於dma_handle,返回該物理頁的虛擬地址
DMA對映建立了一個新的結構型別---------dma_addr_t來表示匯流排地址。dma_addr_t型別的變數對驅動程式是不透明的;唯一允許的操作是將它們傳遞給DMA支援例程以及裝置本身。作為一個匯流排地址,如果CPU直接使用了dma_addr_t,將會導致發生不可預期的後果!
一致性DMA對映存在與驅動程式的生命週期中,它的緩衝區必須可同時被CPU和外圍裝置訪問!因此一致性對映必須儲存在一致性快取中。建立和使用一致性對映的開銷是很大的!
(以上紅色文字摘錄在LDD3)
void *
dma_alloc_coherent
(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp)
{
void *ret;
if (!dev || *dev->dma_mask >= 0xffffffffUL)
gfp &= ~GFP_DMA;
ret = (void *)__get_free_pages
(gfp, get_order(size)); //(1)
if (ret) {
memset(ret, 0, size);
*dma_handle = virt_to_bus
(ret); //(2)
}
return ret;
}
(1) 將size轉換成order, 即2^order
(2) 將虛擬地址ret轉換成匯流排地址
這個函式是一個平臺相關的函式,以上是在x86平臺的實現細節,從這裡我們可以看到該函式返回值為linux 核心線性地址,所以對於驅動開發過程的mmap函式實現提供了便利。
但是在powerpc平臺卻不是這樣,筆者就曾經遇到在將pci驅動從x86平臺移植到powerpc平臺時出現問題。
首先我們來先看一下兩個平臺對於dma記憶體的處理。
x86:
linux記憶體區域分為DMA區域,Normal記憶體區域與高階記憶體區域,高階記憶體區域為當實體記憶體高於768M時使用,一般DMA區域為16M,這段空間由作業系統預留。DMA區域與Normal區域全部使用線性對映,採用邏輯地址使用,高階記憶體使用核心虛擬地址。其中核心空間的分部為:
物理區--8M隔離--vmalloc區--8k隔離--4M的高階對映區--固定對映區--128k
powerpc:
本節採用freescale的mpc5121晶片為例,核心沒有采用Normal記憶體區域,只使用ZONE_DMA和ZONE_HIMEM兩種型別的空間,其中ZONE_DMA存放低端記憶體, ZONE_HIMEN存放高階記憶體,整個記憶體不在採用邏輯地址這一概念。所以基於邏輯地址的操作沒有可移植性。
下面看下具體的區別:
void * __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
{
//物理空間頁的申請
page = alloc_pages(gfp, order);
//對物理空間進行清零cache
{
unsigned long kaddr = (unsigned long)page_address(page);
memset(page_address(page), 0, size);
flush_dcache_range(kaddr, kaddr + size);
}
//申請虛擬空間
c = vm_region_alloc(&consistent_head, size, gfp &
~(__GFP_DMA | __GFP_HIGHMEM));
//實現虛擬地址與實體地址對映
if (c) {
unsigned long vaddr = c->vm_start;
pte_t *pte = consistent_pte + CONSISTENT_OFFSET(vaddr);
struct page *end = page + (1 << order);
split_page(page, order);
/*
* Set the \"dma handle\"
*/
*handle = page_to_bus(page);
do {
BUG_ON(!pte_none(*pte));
SetPageReserved(page);
set_pte_at(&init_mm, vaddr,
pte, mk_pte(page, pgprot_noncached(PAGE_KERNEL)));
page++;
pte++;
vaddr += PAGE_SIZE;
} while (size -= PAGE_SIZE);
// 返回值為核心虛擬地址。
return (void *)c->vm_start
1. I/O 埠和 I/O 記憶體
每個外設都是通過讀寫它的暫存器來控制. 大部分時間一個裝置有幾個暫存器, 並且在連續地址存取它們, 或者在記憶體地址空間或者在 I/O 地址空間.
在硬體級別上, 記憶體區和 I/O 區域沒有概念上的區別: 它們都是通過在地址匯流排和控制總線上發出電訊號來存取(即, 讀寫訊號)[32] 並且讀自或者寫到資料匯流排.
但是一些 CPU 製造商在他們的晶片上實現了一個單個地址空間, 有人認為外設不同於記憶體, 因此, 應該有一個分開的地址空間. 一些處理器(最有名的是 x86 家族)有分開的讀和寫電線給 I/O 埠和特殊的 CPU 指令來存取埠.
因為外設被建立來適合一個外設匯流排, 並且大部分流行的 I/O 匯流排成型在個人計算機上, 即便那些沒有單獨地址空間給 I/O 埠的處理器, 也必須在存取一些特殊裝置時偽裝讀寫埠, 常常利用外部的晶片組或者 CPU 核的額外電路. 後一個方法在用在嵌入式應用的小處理器中常見.
由於同樣的理由, Linux 在所有它執行的計算機平臺上實現了 I/O 埠的概念, 甚至在那些 CPU 實現一個單個地址空間的平臺上. 埠存取的實現有時依賴特殊的主機制造和型號( 因為不同的型號使用不同的晶片組來對映匯流排傳送到記憶體地址空間).
即便外設匯流排有一個單獨的地址空間給 I/O 埠, 不是所有的裝置對映它們的暫存器到 I/O 埠. 雖然對於 ISA 外設板使用 I/O 埠是普遍的, 大部分 PCI 裝置對映暫存器到一個記憶體地址區. 這種 I/O 記憶體方法通常是首選的, 因為它不需要使用特殊目的處理器指令; CPU 核存取記憶體更加有效, 並且編譯器當存取記憶體時有更多自由在暫存器分配和定址模式的選擇上.
1.1. I/O 暫存器和常規記憶體
不管硬體暫存器和記憶體之間的強相似性, 存取 I/O 暫存器的程式設計師必須小心避免被 CPU(或者編譯器)優化所戲弄, 它可能修改希望的 I/O 行為.
I/O 暫存器和 RAM 的主要不同是 I/O 操作有邊際效果, 而記憶體操作沒有: 一個記憶體寫的唯一效果是儲存一個值到一個位置, 並且一個記憶體讀返回最近寫到那裡的值. 因為記憶體存取速度對 CPU 效能是至關重要的, 這種無邊際效果的情況已被多種方式優化: 值被快取, 並且 讀/寫指令被重編排.
編譯器能夠快取資料值到 CPU 暫存器而不寫到記憶體, 並且即便它儲存它們, 讀和寫操作都能夠在緩衝記憶體中進行而不接觸物理 RAM. 重編排也可能在編譯器級別和在硬體級別都發生: 常常一個指令序列能夠執行得更快, 如果它以不同於在程式文字中出現的順序來執行, 例如, 為避免在 RISC 流水線中的互鎖. 在CISC 處理器, 要花費相當數量時間的操作能夠和其他的併發執行, 更快的.
當應用於傳統記憶體時(至少在單處理器系統)這些優化是透明和有益的, 但是它們可能對正確的 I/O 操作是致命的, 因為它們干擾了那些"邊際效果", 這是主要的原因為什麼一個驅動存取 I/O 暫存器. 處理器無法預見這種情形, 一些其他的操作(在一個獨立處理器上執行, 或者發生在一個 I/O 控制器的事情)依賴記憶體存取的順序. 編譯器或者 CPU 可能只盡力勝過你並且重編排你請求的操作; 結果可能是奇怪的錯誤而非常難於除錯. 因此, 一個驅動必須確保沒有進行緩衝並且在存取暫存器時沒有發生讀或寫的重編排.
硬體緩衝的問題是最易面對的:底層的硬體已經配置(或者自動地或者通過 Linux 初始化程式碼)成禁止任何硬體緩衝, 當存取 I/O 區時(不管它們是記憶體還是埠區域).
對編譯器優化和硬體重編排的解決方法是安放一個記憶體屏障在必須以一個特殊順序對硬體(或者另一個處理器)可見的操作之間. Linux 提供 4 個巨集來應對可能的排序需要:
- #include <linux/kernel.h>
- void barrier(void)
- #include <asm/system.h>
- void rmb(void);
- void read_barrier_depends(void);
- void wmb(void);
- void mb(void);
-
# define isb() __asm__ __volatile__ ( "isb" : : : "memory")
-
# define dsb() __asm__ __volatile__ ( "dsb" : : : "memory")
-
# define dmb() __asm__ __volatile__ ( "dsb" : : : "memory")
-
#define mb() do { dsb(); outer_sync(); } while (0)
-
#define rmb() dsb()
-
#define wmb() mb()
-
#define smp_mb() dmb()
-
#define smp_rmb() dmb()
-
#define smp_wmb() dmb()
- void smp_rmb(void);
- void smp_read_barrier_depends(void);
- void smp_wmb(void);
- void smp_mb(void);
這個函式告知編譯器插入一個記憶體屏障但是對硬體沒有影響.編譯的程式碼將所有的當前改變的並且駐留在 CPU 暫存器的值儲存到記憶體, 並且後來重新讀取它們當需要時. 對屏障的呼叫阻止編譯器跨越屏障的優化, 而留給硬體自由做它的重編排.
這些函式插入硬體記憶體屏障在編譯的指令流中; 它們的實際例項是平臺相關的.一個 rmb ( read memory barrier) 保證任何出現於屏障前的讀在執行任何後續讀之前完成. wmb 保證寫操作中的順序, 並且 mb 指令都保證. 每個這些指令是一個屏障的超集.
read_barrier_depends 是讀屏障的一個特殊的, 弱些的形式. 而 rmb 阻止所有跨越屏障的讀的重編排, read_barrier_depends 只阻止依賴來自其他讀的資料的讀的重編排. 區別是微小的, 並且它不在所有體系中存在. 除非你確切地理解做什麼, 並且你有理由相信, 一個完整的讀屏障確實是一個過度地效能開銷, 你可能應當堅持使用 rmb.
表4.27 隔離指令
指令名 |
功能描述 |
DMB |
資料儲存器隔離。DMB 指令保證: 僅當所有在它前面的儲存器訪問操作 都執行完畢後,才提交(commit)在它後面的儲存器訪問操作。 |
DSB |
資料同步隔離。比 DMB 嚴格: 僅當所有在它前面的儲存器訪問操作 都執行完畢後,才執行在它後面的指令(亦即任何指令都要等待儲存器訪 問操作——譯者注) |
ISB |
指令同步隔離。最嚴格:它會清洗流水線,以保證所有它前面的指令都執 行完畢之後,才執行它後面的指令。 |
屏障的這些版本僅當核心為 SMP 系統編譯時插入硬體屏障; 否則, 它們都擴充套件為一個簡單的屏障呼叫.
在一個裝置驅動中一個典型的記憶體屏障的用法可能有這樣的形式:
writel(dev->registers.addr, io_destination_address); writel(dev->registers.size, io_size); writel(dev->registers.operation, DEV_READ); wmb(); writel(dev->registers.control, DEV_GO);
在這種情況, 是重要的, 確保所有的控制一個特殊操作的裝置暫存器在告訴它開始前已被正確設定. 記憶體屏障強制寫以需要的順序完成.
因為記憶體屏障影響效能, 它們應當只用在確實需要它們的地方. 屏障的不同型別也有不同的效能特性, 因此值得使用最特定的可能型別. 例如, 在 x86 體系上, wmb() 目前什麼都不做, 因為寫到處理器外不被重編排. 但是, 讀被重編排, 因此 mb() 被 wmb() 慢.
值得注意大部分的其他的處理同步的核心原語, 例如自旋鎖和原子的 _t 操作, 如同記憶體屏障一樣是函式. 還值得注意的是一些外設匯流排(例如 PCI 匯流排)有它們自己的緩衝問題; 我們在以後章節遇到時討論它們.
一些體系允許一個賦值和一個記憶體屏障的有效組合. 核心提供了幾個巨集來完成這個組合; 在預設情況下, 它們如下定義:
#define set_mb(var, value) do {var = value; mb();}while 0 #define set_wmb(var, value) do {var = value; wmb();} while 0 #define set_rmb(var, value) do {var = value; rmb();} while 0
在合適的地方, <asm/system.h> 定義這些巨集來使用體系特定的指令來很快完成任務. 注意 set_rmb 只在少量體系上定義. (一個 do...while 結構的使用是一個標準 C 用語, 來使被擴充套件的巨集作為一個正常的 C 語句可在所有上下文中工作).
本文永久更新連結:http://embeddedlinux.org.cn/emb-linux/kernel-driver/201905/09-8658.html