void * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags)
入口： phys_addr：要對映的起始的IO地址；

size：要對映的空間的大小；

flags：要對映的IO空間的和許可權有關的標誌；

功能： 將一個IO地址空間對映到核心的虛擬地址空間上去，便於訪問；

實現：對要對映的IO地址空間進行判斷，低PCI/ISA地址不需要重新對映，也不允許使用者將IO地址空間對映到正在使用的RAM中，最後申請一 個 vm_area_struct結構，呼叫remap_area_pages填寫頁表，若填寫過程不成功則釋放申請的vm_area_struct空 間；

意義：
比如isa裝置和pci裝置，或者是fb，硬體的跳線或者是物理連線方式決定了硬體上的記憶體影射到的cpu實體地址。
在核心訪問這些地址必須分配給這段記憶體以虛擬地址,這正是__ioremap的意義所在 ,需要注意的是,實體記憶體已經"存在"了,無需alloc page給這段地址了.

檔案中的註釋也是比較詳盡的,並且只 暴露了__ioremap,iounmap兩個函式供其他模
塊呼叫,函式remap_area_pte,remap_area_pmd,remap_area_pages只為__ioremap所用.

－－－－－－－－
為了使軟體訪問I/O記憶體,必須為裝置分配虛擬地址.這就是ioremap的工作.這個函式專門用來為I/O記憶體區域分配虛擬地址(空間).對於直接對映的I/O地址ioremap不做任何事情(uClinux中是這麼實現的??)
有了ioremap(和iounmap),裝置就可以訪問任何I/O記憶體空間,不論它是否直接對映到虛擬地址空間.但是,這些地址永遠不能直接使用(指實體地址),而要用readb這種函式.

根據計算機平臺和所使用匯流排的不同，I/O 記憶體可能是，也可能不是通過頁表訪問的，通過頁表訪問的是統一編址（PowerPC），否則是獨立編址(Intel)。如果訪問是經由頁表進行的，核心必須首先安排實體地址使其對裝置驅動 程式可見（這通常意味著在進行任何 I/O 之前必須先呼叫 ioremap）。如果訪問無需頁表，那麼 I/O 記憶體區域就很象 I/O 埠，可以使 用適當形式的函式讀寫它們。

不管訪問 I/O 記憶體時是否需要呼叫 ioremap，都不鼓勵直接使用指向 I/O 記憶體的指標。儘管（在“I/O 埠和 I/O 記憶體” 介紹過）I/O 記憶體在硬體一級是象普通 RAM 一樣定址的，但在“I/O 暫存器和常規記憶體”中描述過的那些需要額外小心的情況中已經建議不要使用普 通指標。相反，使用“包裝的”函式訪問 I/O 記憶體，一方面在所有平臺上都是安全的，另一方面，在可以直接對指標指向的記憶體區域執行操作的時候，該函式 是經過優化的

－－－－－－－

自己原以為當給顯示卡上的儲存空間分配了匯流排地址A以後,它所對應的虛擬空間就隨之確定了.也就是A+3G.可是事實上,在ioremap.c檔案裡面的實現並不是這樣的.所用的函式是 __ioremap(unsigned long phys_addr, unsigned long size, unsigned
long flags)實現的時候是為從phys_addr開始的size大小的實體地址分配一塊虛擬地址.注意這裡是分配,而不是指定.我所認為的分配應該是指定即根據phys_addr得到其所對應的虛擬地址是phys_addr+3G.
本人認為一合理的解釋是這樣的:系統虛擬空間中對映的非IO卡上的地址空間滿足3G差關係,而IO卡上的
儲存空間就不滿足了.

在X86 體系下的，CPU的實體地址和PCI匯流排地址共用一個空間。linux核心將3G-4G的虛擬地址固定對映到了實體地址的0－1G的地方。但是如果外圍裝置上的地址高於1G，例如某塊PCI卡分配到了一個高於1G的地址，就需要呼叫ioremap來重新建立該實體地址（匯流排地址）和虛擬地址之間的對映。這個對映過程是這樣的：在ioremap.c檔案的__ioremap函式中首先對將來對映的實體地址進行檢查，也就是不能重新對映640K-1M地址（由於歷史的原因，實體地址640k到1M空間被保留給了顯示卡）,普通的ram地也不能重新被對映。之後呼叫get_vm_area獲得可用的虛擬地址，然後根這虛擬地址和欲對映的實體地址修改頁表，之後核心就可以用這個虛擬地址來訪問對映的實體地址了。

[經典]Linux核心中ioremap對映的透徹理解

幾乎每一種外設都是通過讀寫裝置上的暫存器來進行的，通常包括控制暫存器、狀態暫存器和資料暫存器三大類，外設的暫存器通常被連續地編址。根據CPU體系結構的不同，CPU對IO埠的編址方式有兩種：

（1）I/O對映方式（I/O-mapped）

典型地，如X86處理器為外設專門實現了一個單獨的地址空間，稱為"I/O地址空間"或者"I/O埠空間"，CPU通過專門的I/O指令（如X86的IN和OUT指令）來訪問這一空間中的地址單元。

（2）記憶體對映方式（Memory-mapped）

RISC指令系統的CPU（如ARM、PowerPC等）通常只實現一個實體地址空間，外設I/O埠成為記憶體的一部分。此時，CPU可以象訪問一個記憶體單元那樣訪問外設I/O埠，而不需要設立專門的外設I/O指令。

但是，這兩者在硬體實現上的差異對於軟體來說是完全透明的，驅動程式開發人員可以將記憶體對映方式的I/O埠和外設記憶體統一看作是"I/O記憶體"資源。

一般來說，在系統執行時，外設的I/O記憶體資源的實體地址是已知的，由硬體的設計決定。但是CPU通常並沒有為這些已知的外設I/O記憶體資源的實體地址預定義虛擬地址範圍，驅動程式並不能直接通過實體地址訪問I/O記憶體資源，而必須將它們對映到核心虛地址空間內（通過頁表），然後才能根據對映所得到的核心虛地址範圍，通過訪內指令訪問這些I/O記憶體資源。Linux在io.h標頭檔案中聲明瞭函式ioremap（），用來將I/O記憶體資源的實體地址對映到核心虛地址空間（3GB－4GB）中，原型如下：

void * ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags);

iounmap函式用於取消ioremap（）所做的對映，原型如下：

void iounmap(void * addr);

這兩個函式都是實現在mm/ioremap.c檔案中。

在將I/O記憶體資源的實體地址對映成核心虛地址後，理論上講我們就可以象讀寫RAM那樣直接讀寫I/O記憶體資源了。為了保證驅動程式的跨平臺的可移植性，我們應該使用Linux中特定的函式來訪問 I/O記憶體資源，而不應該通過指向核心虛地址的指標來訪問。如在x86平臺上，讀寫I/O的函式如下所示：

#define readb(addr) (*(volatile unsigned char *) __io_virt(addr))
#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))
#define readl(addr) (*(volatile unsigned int *) __io_virt(addr))

#define writeb(b,addr) (*(volatile unsigned char *) __io_virt(addr) = (b))
#define writew(b,addr) (*(volatile unsigned short *) __io_virt(addr) = (b))
#define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))

#define memset_io(a,b,c) memset(__io_virt(a),(b),(c))
#define memcpy_fromio(a,b,c) memcpy((a),__io_virt(b),(c))
#define memcpy_toio(a,b,c) memcpy(__io_virt(a),(b),(c))

最後，我們要特別強調驅動程式中mmap函式的實現方法。用mmap對映一個裝置，意味著使使用者空間的一段地址關聯到裝置記憶體上，這使得只要程式在分配的地址範圍內進行讀取或者寫入，實際上就是對裝置的訪問。

筆者在Linux原始碼中進行包含"ioremap"文字的搜尋，發現真正出現的ioremap的地方相當少。所以筆者追根索源地尋找I/O操作的實體地址轉換到虛擬地址的真實所在，發現Linux有替代ioremap的語句，但是這個轉換過程卻是不可或缺的。

譬如我們再次摘取S3C2410這個ARM晶片RTC（實時鐘）驅動中的一小段：

01.static void get_rtc_time(int alm, struct rtc_time *rtc_tm) 02.{ 03.spin_lock_irq(&rtc_lock); 04.if (alm == 1) { 05.rtc_tm->tm_year = (unsigned char)ALMYEAR & Msk_RTCYEAR; 06.rtc_tm->tm_mon = (unsigned char)ALMMON & Msk_RTCMON; 07.rtc_tm->tm_mday = (unsigned char)ALMDAY & Msk_RTCDAY; 08.rtc_tm->tm_hour = (unsigned char)ALMHOUR & Msk_RTCHOUR; 09.rtc_tm->tm_min = (unsigned char)ALMMIN & Msk_RTCMIN; 10.rtc_tm->tm_sec = (unsigned char)ALMSEC & Msk_RTCSEC; 11.} 12.else { 13.read_rtc_bcd_time: 14.rtc_tm->tm_year = (unsigned char)BCDYEAR & Msk_RTCYEAR; 15.rtc_tm->tm_mon = (unsigned char)BCDMON & Msk_RTCMON; 16.rtc_tm->tm_mday = (unsigned char)BCDDAY & Msk_RTCDAY; 17.rtc_tm->tm_hour = (unsigned char)BCDHOUR & Msk_RTCHOUR; 18.rtc_tm->tm_min = (unsigned char)BCDMIN & Msk_RTCMIN; 19.rtc_tm->tm_sec = (unsigned char)BCDSEC & Msk_RTCSEC; 20. 21.if (rtc_tm->tm_sec == 0) { 22./* Re-read all BCD registers in case of BCDSEC is 0. 23.See RTC section at the manual for more info. */ 24.goto read_rtc_bcd_time; 25.} 26.} 27.spin_unlock_irq(&rtc_lock); 28. 29.BCD_TO_BIN(rtc_tm->tm_year); 30.BCD_TO_BIN(rtc_tm->tm_mon); 31.BCD_TO_BIN(rtc_tm->tm_mday); 32.BCD_TO_BIN(rtc_tm->tm_hour); 33.BCD_TO_BIN(rtc_tm->tm_min); 34.BCD_TO_BIN(rtc_tm->tm_sec); 35. 36./* The epoch of tm_year is 1900 */ 37.rtc_tm->tm_year += RTC_LEAP_YEAR - 1900; 38. 39./* tm_mon starts at 0, but rtc month starts at 1 */ 40.rtc_tm->tm_mon--; 41.}

I/O操作似乎就是對ALMYEAR、ALMMON、ALMDAY定義的暫存器進行操作，那這些巨集究竟定義為什麼呢？

#define ALMDAY bRTC(0x60)
#define ALMMON bRTC(0x64)
#define ALMYEAR bRTC(0x68)

其中藉助了巨集bRTC，這個巨集定義為：

#define bRTC(Nb) __REG(0x57000000 + (Nb))

其中又藉助了巨集__REG，而__REG又定義為：

# define __REG(x) io_p2v(x)

最後的io_p2v才是真正"玩"虛擬地址和實體地址轉換的地方：

#define io_p2v(x) ((x) | 0xa0000000)

與__REG對應的有個__PREG：

# define __PREG(x) io_v2p(x)

與io_p2v對應的有個io_v2p：

#define io_v2p(x) ((x) & ~0xa0000000)

可見有沒有出現ioremap是次要的，關鍵問題是有無虛擬地址和實體地址的轉換！

下面的程式在啟動的時候保留一段記憶體，然後使用ioremap將它對映到核心虛擬空間，同時又用remap_page_range對映到使用者虛擬空間，這樣一來，核心和使用者都能訪問。如果在核心虛擬地址將這段記憶體初始化串"abcd"，那麼在使用者虛擬地址能夠讀出來：

001./************mmap_ioremap.c**************/ 002.#include <linux/module.h> 003.#include <linux/kernel.h> 004.#include <linux/errno.h> 005.#include <linux/mm.h> 006.#include <linux/wrapper.h> /* for mem_map_(un)reserve */ 007.#include <asm/io.h> /* for virt_to_phys */ 008.#include <linux/slab.h> /* for kmalloc and kfree */ 009. 010.MODULE_PARM(mem_start, "i"); 011.MODULE_PARM(mem_size, "i"); 012. 013.static int mem_start = 101, mem_size = 10; 014.static char *reserve_virt_addr; 015.static int major; 016. 017.int mmapdrv_open(struct inode *inode, struct file *file); 018.int mmapdrv_release(struct inode *inode, struct file *file); 019.int mmapdrv_mmap(struct file *file, struct vm_area_struct *vma); 020. 021.static struct file_operations mmapdrv_fops = 022.{ 023.owner: THIS_MODULE, mmap: mmapdrv_mmap, open: mmapdrv_open, release: 024.mmapdrv_release, 025.}; 026. 027.int init_module(void) 028.{ 029.if ((major = register_chrdev(0, "mmapdrv", &mmapdrv_fops)) < 0) 030.{ 031.printk("mmapdrv: unable to register character device\n"); 032.return ( - EIO); 033.} 034.printk("mmap device major = %d\n", major); 035. 036.printk("high memory physical address 0x%ldM\n", virt_to_phys(high_memory) / 037.1024 / 1024); 038. 039.reserve_virt_addr = ioremap(mem_start *1024 * 1024, mem_size *1024 * 1024); 040.printk("reserve_virt_addr = 0x%lx\n", (unsigned long)reserve_virt_addr); 041.if (reserve_virt_addr) 042.{ 043.int i; 044.for (i = 0; i < mem_size *1024 * 1024; i += 4) 045.{ 046.reserve_virt_addr[i] = 'a'; 047.reserve_virt_addr[i + 1] = 'b'; 048.reserve_virt_addr[i + 2] = 'c'; 049.reserve_virt_addr[i + 3] = 'd'; 050.} 051.} 052.else 053.{ 054.unregister_chrdev(major, "mmapdrv"); 055.return - ENODEV; 056.} 057.return 0; 058.} 059. 060./* remove the module www.it165.net */ 061.void cleanup_module(void) 062.{ 063.if (reserve_virt_addr) 064.iounmap(reserve_virt_addr); 065. 066.unregister_chrdev(major, "mmapdrv"); 067.return ; 068.} 069. 070.int mmapdrv_open(struct inode *inode, struct file *file) 071.{ 072.MOD_INC_USE_COUNT; 073.return (0); 074.} 075. 076.int mmapdrv_release(struct inode *inode, struct file *file) 077.{ 078.MOD_DEC_USE_COUNT; 079.return (0); 080.} 081. 082.int mmapdrv_mmap(struct file *file, struct vm_area_struct *vma) 083.{ 084.unsigned long offset = vma->vm_pgoff << PAGE_SHIFT; 085.unsigned long size = vma->vm_end - vma->vm_start; 086. 087.if (size > mem_size *1024 * 1024) 088.{ 089.printk("size too big\n"); 090.return ( - ENXIO); 091.} 092. 093.offset = offset + mem_start * 1024 * 1024; 094. 095./* we do not want to have this area swapped out, lock it */ 096.vma->vm_flags |= VM_LOCKED; 097.if (remap_page_range(vma, vma->vm_start, offset, size, PAGE_SHARED)) 098.{ 099.printk("remap page range failed\n"); 100.return - ENXIO; 101.} 102.return (0); 103.}

remap_page_range函式的功能是構造用於對映一段實體地址的新頁表，實現了核心空間與使用者空間的對映，其原型如下：

int remap_page_range(vma_area_struct *vma, unsigned long from, unsigned long to, unsigned long size, pgprot_tprot);

使用mmap最典型的例子是顯示卡的驅動，將視訊記憶體空間直接從核心對映到使用者空間將可提供視訊記憶體的讀寫效率。

      （在核心驅動程式的初始化階段，通過ioremap（）將實體地址對映到核心虛擬空間；在驅動程式的mmap系統呼叫中，使用remap_page_range()將該塊ROM對映到使用者虛擬空間。這樣核心空間和使用者空間都能訪問這段被對映後的虛擬地址。）

i386 系列處理器中 , 記憶體和外部 IO 是獨立編址獨立定址的 , 於是有一個地址空間叫做記憶體空間 , 另有一個地址空間叫做 I/O 空間 . 也就是說 , 從處理器的角度來說 ,i386 提供了一些單獨的指令用來訪問 I/O 空間 . 換言之 , 訪問 I/O 空間和訪問普通的記憶體得使用不同的指令 . 而在一些玩嵌入式的處理器中 , 比如 PowerPC, 他們家就只使用一個空間 , 那就是記憶體空間 , 那像這種情況 , 外設的 I/O 埠的實體地址就被對映到記憶體地址空間中 , 這就是傳說中的 Memory-mapped, 記憶體對映 . 而我們家那種情況 , 外設的 I/O 埠的實體地址就被對映到 I/O 地址空間中 , 這就是傳說中的 I/O-mapped, 即 I/O 對映 .

要使用 I/O 記憶體首先要申請 , 然後要對映 , 而要使用 I/O 埠首先要申請 , 或者叫請求 , 對於 I/O 埠的請求意思是讓核心知道你要訪問這個埠 , 這樣核心知道了以後它就不會再讓別人也訪問這個埠了 . 畢竟這個世界僧多粥少啊 . 申請 I/O 埠的函式是 request_region, 這個函式來自 include/linux/ioport.h,

/* Convenience shorthand with allocation */

#define request_region(start,n,name)    __request_region(&ioport_resource, (start), (n), (name))

#define request_mem_region(start,n,name) __request_region(&iomem_resource, (start), (n), (name))

#define rename_region(region, newname) do { (region)->name = (newname); } while (0)

extern struct resource * __request_region(struct resource *,

                                         resource_size_t start,

                                         resource_size_t n, const char *name);

這裡我們看到的那個 request_mem_region 是申請 I/O 記憶體用的 . 申請了之後 , 還需要使用 ioremap 或者 ioremap_nocache 函式來對映 .對於 request_region, 三個引數 start,n,name 表示你想使用從 start 開始的 size 為 n 的 I/O port 資源 ,name 自然就是你的名字了 .

這兩個函式在核心的驅動中幾乎都會出現，例如ohci-at91.c裡面的probe函式：

01.hcd->rsrc_start = pdev->resource[0].start;   02.hcd->rsrc_len = pdev->resource[0].end - pdev->resource[0].start + 1;   03.if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {   04.pr_debug("request_mem_region failed\n");   05.retval = -EBUSY;   06.goto err1;   07.}   08.hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);   09.if (!hcd->regs) {   10.pr_debug("ioremap failed\n");   11.retval = -EIO;   12.goto err2;   13.} 14.hcd->rsrc_start = pdev->resource[0].start; 15.hcd->rsrc_len = pdev->resource[0].end - pdev->resource[0].start + 1; 16.if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) { 17.pr_debug("request_mem_region failed\n"); 18.retval = -EBUSY; 19.goto err1; 20.} 21.hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len); 22.if (!hcd->regs) { 23.pr_debug("ioremap failed\n"); 24.retval = -EIO; 25.goto err2; 26.}

這樣的好處是暫存器訪問方式比較好看，只要加個偏移地址就可以了。

不過我有時候又不太喜歡用。因為這兩句話說到底是為了訪問暫存器用的。相當於獲得暫存器虛擬地址。但是我們在初始化的時候虛擬地址就已經對映過了，所以我喜歡直接操作暫存器的虛擬地址。

ioremap 與__ioremap的區別　                                      
void * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags)

void *ioremap(unsigned long phys_addr, unsigned long size)

入口： phys_addr：要對映的起始的IO地址；

size：要對映的空間的大小；

flags：要對映的IO空間的和許可權有關的標誌；

phys_addr：是要對映的實體地址，

size：是要對映的長度，

S3C2410的long是32位而非你說的64位。

功能： 將一個IO地址空間對映到核心的虛擬地址空間上去，便於訪問；

實現： 對要對映的IO地址空間進行判斷，低PCI/ISA地址不需要重新對映，也不允許使用者將IO地址空間對映到正在使用的RAM中，最後申請一個 vm_area_struct結構，呼叫remap_area_pages填寫頁表，若填寫過程不成功則釋放申請的vm_area_struct空間；

ioremap 依靠 __ioremap實現,它只是在__ioremap中以第三個引數為0呼叫來實現.

ioremap是核心提供的用來對映外設暫存器到主存的函式，我們要對映的地址已經從pci_dev中讀了出來（上一步），這樣就水到渠成的成功映射了而不會和其他地址有衝突。對映完了有什麼效果呢，我舉個例子，比如某個網絡卡有100 個暫存器，他們都是連在一塊的，位置是固定的，加入每個暫存器佔4個位元組，那麼一共400個位元組的空間被對映到記憶體成功後，ioaddr就是這段地址的開頭（注意ioaddr是虛擬地址，而mmio_start是實體地址，它是BIOS得到的，肯定是實體地址，而保護模式下CPU不認實體地址，只認虛擬地址），ioaddr+0就是第一個暫存器的地址，ioaddr+4就是第二個暫存器地址（每個暫存器佔4個位元組），以此類推，我們就能夠在記憶體中訪問到所有的暫存器進而操控他們了。