引 言
　　MMC（Multitmedia Card）是一種體積小巧、容量大、使用方便的存儲器，目前在手機等嵌入式系統(tǒng)中有著廣泛的應用。MMC通過卡內的一個集成片內控制器對MMC卡進行控制和管理，當主機正確地驅動MMC卡后，就可以像磁盤一樣方便地存取數(shù)據(jù)。本文所研究與實現(xiàn)的Linux驅動程序，以Intel XScale的PXA250為硬件平臺，在遵循MMC卡通信協(xié)議規(guī)范的基礎上，實現(xiàn)了卡的底層讀寫。然后對傳統(tǒng)的塊設備驅動程序中的單塊讀寫進行了改進，實現(xiàn)了集群讀寫技術，提高了卡的讀寫速度；同時增加了電源管理功能，滿足了嵌入式系統(tǒng)低功耗的需求；增加了即插即用功能，方便了用戶的使用。
　　1 MMC卡驅動程序的體系結構
　　MMC卡僅通過5個引腳與主機的控制器相連，通過串行協(xié)議與主機通信。MMC卡在硬件上的簡單構造必然導致在實現(xiàn)驅動程序上的復雜。依據(jù)MMC卡的通信擲議規(guī)范和Linux驅動程序的結構，把驅動程序原有的底層驅動、守護線程、單塊讀寫進行改進和擴展，其結構層次再劃分為底層驅動、守護線程、集群讀寫、電源管理及熱拔插管理5個部分，如圖l所示。
　　
　　圖1中各部分的功能為：
　　①底層驅動——處理直接涉及與MMC卡硬件寄存器端口的操作，包括：命令的發(fā)布和響應、中斷響應和處理、PIO或者DMA通道數(shù)據(jù)傳輸?shù)取?br /> 　　②集群讀寫——將磁盤相鄰數(shù)據(jù)塊的讀寫請求合并起來一起發(fā)布讀寫命令，以加快數(shù)據(jù)讀寫，并在讀寫中實現(xiàn)并發(fā)控制。
　　③電源管理——實現(xiàn)MMC卡的低功耗管理。
　　④熱拔插管理——實現(xiàn)MMC卡的即插即用功能。
　　⑤守護線程——響應文件系統(tǒng)的讀寫請求并啟動對卡的1/O。
　　2 MMC卡驅動程序的實現(xiàn)
　　2．1 底層驅動
　　底層驅動指的是直接對MMC卡進行操作。MMC卡采用串行的數(shù)據(jù)傳輸方式；是一種比較“精細”的卡，對它的操作比較復雜而且必須有準確的時序安排。以下從命令的發(fā)布和響應、中斷響應和處理、DMA數(shù)據(jù)傳輸3個方面講述如何進行底層讀寫驅動。
　　（1）命令發(fā)布和響應
　　MMC卡的操作是通過對其18個控制寄存器的讀寫實現(xiàn)的。首先，設置時鐘起停寄存器MMC_STRCPL的最低兩位為01．關閉MMC卡內部時鐘。然后，設置中斷屏蔽寄存器MMC_LMASK的最低7位都為1，屏蔽所有對MMC控制器的中斷，再向指定的MMC控制寄存器中寫入命令參數(shù)，如時鐘頻率設置寄存器MMC_CLKRT，讀寫塊數(shù)寄存器MMC_NOB，命令寄存器MMC_CMD等。最后，打開內部時鐘，解除屏蔽的中斷。這時，當前讀寫進程進入睡眠狀態(tài)，等待中斷處理程序的喚醒。
　　（2）中斷響應和處理
　　MMC卡在數(shù)據(jù)傳輸請求、內部時鐘關閉、命令發(fā)布完畢、數(shù)據(jù)傳輸完畢的情況下都會產(chǎn)生中斷，但足MMC卡的控制器只通過1裉GPIO23的引腳與CPU相連，用于中斷信號線的復用；因此在中斷處理程序中，必須首先判斷到底是哪種原因產(chǎn)生的中斷，然后再進行相應的處理。這里，MMC卡在正確發(fā)布讀寫命令以后，系統(tǒng)會產(chǎn)生1次中斷，中斷處理程序中讀取MMC_IREG的值，判斷命令已經(jīng)發(fā)布成功，同時喚醒等待命令完成的進程。
　　讀寫進程被中斷喚醒后，首先讀取MMC卡響應寄存器MMC_RES中的狀態(tài)信息，再根據(jù)這些狀態(tài)信息判斷命令是否發(fā)布成功和卡的當前狀態(tài)。如果這些狀態(tài)信息表示命令執(zhí)行成功，則通過讀寫緩沖寄存器MMC_RXFIFO和MMC_TXFIFO進行數(shù)據(jù)的讀寫（這里使用DMA進行數(shù)據(jù)傳輸，提高了數(shù)據(jù)的傳輸速度）；如果返回的狀態(tài)信息表明命令執(zhí)行不成功，則根據(jù)狀念信息進行相應的出錯處理。
　　（3）DMA數(shù)據(jù)傳輸
　　驅動程序中對MMC卡的數(shù)據(jù)讀寫是通過DMA通道進行傳輸?shù)摹榱吮Ｍ舨僮鞯倪B續(xù)性，驅動程序對MMC卡的輸入和輸出緩沖各設置1個DMA通道，在進行實際數(shù)據(jù)傳輸時，讀寫進程也進入睡眠狀態(tài)，等待DMA數(shù)據(jù)傳輸完畢后，被DMA中斷喚醒。實現(xiàn)一次讀操作的偽代碼如下：
　　Pxa_read_mmc（）{
　　關閉時鐘，屏蔽中斷；
　　設置讀寫寄存器的內容； /*讀寫塊數(shù)，起始塊數(shù)，讀寫速度等*／
　　打開時鐘，發(fā)布讀寫命令；
　　Interruptible_sleep_on（）； ／*進入可打斷睡眠狀態(tài)，等待中斷程序的喚醒*／
　　被中斷程序喚醒，打開DMA通道，進行數(shù)據(jù)傳輸，再次進入可打斷睡眠狀態(tài)；
　　被DMA傳輸完畢中斷喚醒，發(fā)布結束傳輸命令，結束數(shù)據(jù)傳輸；
　　2．2 集群（clustering）讀寫和并發(fā)控制
　　2．2．1 傳統(tǒng)的塊設備驅動程序結構和不足
　　塊沒備驅動程序是Linux系統(tǒng)中最復雜的驅動程序之一，參閱文獻［3，4］可以詳細了解Linux塊設備驅動程序。這里簡單介紹與集群讀寫相關的數(shù)據(jù)結構和操作。扇區(qū)（seetor）是塊設備硬件傳輸數(shù)據(jù)的基本單位，而塊（block）是塊設備請求1次I／O操作所涉及的一組相鄰扇區(qū)，每個塊都需要有自己的內存緩沖區(qū)。緩沖區(qū)首部（buffer_head）是與每個緩沖區(qū)相關的數(shù)據(jù)結構，每次對塊沒備的I／O傳輸都必須經(jīng)過塊的緩沖區(qū)。
　　Linux塊沒備驅動程序采取一種延遲I／O策略。當進程有I／O請求時，驅動程序延遲一段時間，把塊設備上相連續(xù)的buffer_head結構關聯(lián)在一起形成一個I／O請求描述符（struct request），再把request結構按照電梯算法排隊到設備的請求隊列（request_queue_t）。這樣實際執(zhí)行I／O傳輸時，順次處理對應塊設備的請求隊列。
　　對于request結構的電梯排隊算法，避免由于頻繁的移動磁頭而導致塊設備性能下降；然而，目前在Linux塊設備驅動程序中，對一個request結構中的
　　各個buffer_head結構分別發(fā)布I／O讀寫命令，會導致每次對一個buffer_head的輸入／輸出時，磁頭都會停頓一段時間，進行DMA數(shù)據(jù)讀寫。這樣頻繁的磁頭啟停會導致磁盤性能下降。
　　2.2.2 集群讀寫的實現(xiàn)
　　傳統(tǒng)的塊設備驅動程序中每次發(fā)布讀寫命令都只對一個buffer_head緩沖而導致塊設備性能下降。針對這一問題，我們對傳統(tǒng)塊設備進行改進，實現(xiàn)了集群讀寫。由于每一個request結構的buffer_head結構鏈對應的物理塊都是相鄰的，因此為進行集群讀寫創(chuàng)造了條件。request結構中的nr_sectors表示該request結構需要讀寫的塊數(shù)。進行讀寫時，一次性發(fā)布讀寫塊數(shù)為nr_seetors，讀入塊設備內容到requem結構指向的第一個buffer_head結構對應的內存區(qū)域。在一個buffer_head結構的緩沖區(qū)讀寫滿了以后，就調整讀寫緩沖區(qū)地址為下一個buffer_head所指向的緩沖區(qū)，同時配合DMA進行數(shù)據(jù)傳輸，提高了讀寫速度。對一個request結構操作完成以后，釋放request結構資源。實現(xiàn)集群讀操作偽碼如下：
　　Read_mmc（）{
　　發(fā)布讀寫命令，讀入的數(shù)據(jù)塊數(shù)為一個rcquest一》nr_sectors的塊數(shù)；
　　緩沖區(qū)的指針指向第1個bh結構所指的緩沖區(qū)；
　　while（數(shù)據(jù)還沒有讀完）{
　　讀入數(shù)據(jù)到buffer_head結構所指定的緩沖區(qū)；／*調用Pxa_read_mmc（）*／
　　調整緩沖區(qū)的指針到下一個buffer_head結構所指向的緩沖區(qū)；
　　}
　　}
　　2．2．3集群讀寫中的并發(fā)控制
　　如果I／O請求隊列request_queue_t是在內核中的許多地方都被訪問的，則該隊列就成為了臨界資源。為了對該隊列進行互斥保護，Linux2．4中所有的請求隊列都受一個單獨的全局自旋鎖io_request_lock的保護。所有對清求隊列的操作必須要求擁有該鎖并禁止中斷，然而，在驅動程序擁有這個鎖的同時，其他任何讀寫請求不能排隊到系統(tǒng)的任何塊設備上，其他讀寫處理函數(shù)也不能運行。為了盡量減輕由于驅動程序長期的擁有該鎖而導致系統(tǒng)性能下降的問題，在實現(xiàn)集群讀寫時必須遵循以下原則：
　　①對請求隊列進行讀寫操作時要獲得鎖；
　　②對請求隊列操作完畢后釋放請求鎖；
　　③為了減少占用鎖的時間，可先把隊列中的request結構從隊列中取下來，再打開鎖，然后在開鎖的情況下對取下的request結構進行操作。
　　基于以上原則，讀／寫處理函數(shù)的偽碼如下所示：
　　mmc_request_fn（）
　　whilc（1）{
　　加鎖io_request_lock;
　　讀取當前MMC卡請求隊列的第一個請求結構request；
　　釋放鎖io_request_lock;
　　if（request為空）
　　cxit（O）； ／*沒有可以處理的隊列，返回*/
　　read_mmc（）； /*調用集群讀寫函數(shù)*/
　　加鎖io_request_lock；
　　在queue結構中取處理完畢的request結構，釋放request資源；
　　釋放鎖io_request_lock；
　　}
　　}
　　2.3 守護線程
　　在MMC卡驅動程序初始化的時候，啟動守護線程mme_block_thread。它平時處于睡眠狀態(tài)，當有對MMC卡的讀／寫請求時，mmc_blok_thread被喚醒。該線程調用上述讀／寫處理函數(shù)mmc_request_fn（），處理完畢后再進入睡眠狀態(tài)。