基于Davinci平臺(tái)的SD卡讀寫(xiě)優(yōu)化

梁正和，秦超，陸國(guó)強(qiáng)

0 前言

隨著嵌入式處理器速度的不斷提高以及嵌入式系統(tǒng)功能的不斷增加，嵌入式系統(tǒng)越來(lái)越多地被應(yīng)用到網(wǎng)絡(luò)音視頻的處理上，在這種情況下，美國(guó)德州儀器公司（TI）推出了面向嵌入式網(wǎng)絡(luò)音視頻應(yīng)用的Davinci解決方案。這個(gè)解決方案的提出使開(kāi)發(fā)人員擺脫了數(shù)字視頻的具體處理細(xì)節(jié)，加快了產(chǎn)品上市進(jìn)程。Davinci解決方案也成為了國(guó)內(nèi)的熱門(mén)研究課題。

SD卡（Security Digital Memory Card）是由日本松下公司、東芝公司和美國(guó)SANDISK公司共同開(kāi)發(fā)研制的全新存儲(chǔ)卡產(chǎn)品。SD卡兼容MMC卡接口規(guī)范，并以其大容量、高性能、高安全性等特點(diǎn)成為了嵌入式環(huán)境中存儲(chǔ)大容量數(shù)據(jù)的首選。對(duì)SD卡的操作也是Davinci解決方案里一個(gè)必不可少的組成部分。

1 Davinci平臺(tái)的SD卡驅(qū)動(dòng)程序

1.1 MMC/SD卡控制器

MMC/SD控制器通過(guò)MMC/SD協(xié)議與SD卡進(jìn)行通信，MMC/SD卡控制器通過(guò)配置可以實(shí)現(xiàn)MMC控制器和SD卡控制器之間的轉(zhuǎn)換。驅(qū)動(dòng)程序可以通過(guò)讀寫(xiě)控制器里的寄存器和FIFO，啟動(dòng)一次與SD卡的通信。通過(guò)設(shè)置寄存器，可以發(fā)送命令和參數(shù)、設(shè)置接受的應(yīng)答的格式、事發(fā)后發(fā)送/接收數(shù)據(jù)以及是否產(chǎn)生同步時(shí)鐘等SD卡操作所需要的功能。控制器還可以進(jìn)行DMA操作，將控制的FIFO作為DMA控制器的目標(biāo)或者源，實(shí)現(xiàn)后臺(tái)的數(shù)據(jù)傳輸，從而提高系統(tǒng)效率。

Davinci的MMC/SD控制器結(jié)構(gòu)，如圖1所示:

圖1

1.2 Davinci平臺(tái)的SD卡驅(qū)動(dòng)程序

Linux2.6內(nèi)核支持Davinci平臺(tái)下的SD卡，在drivers/mmc/davinci-mmc.c里為其提供了具體對(duì)應(yīng)于davinci平臺(tái)的SD卡驅(qū)動(dòng)程序。

SD卡是塊設(shè)備，只能以塊為單位來(lái)進(jìn)行讀寫(xiě)操作。因此SD卡驅(qū)動(dòng)程序必須將SD卡實(shí)現(xiàn)為塊設(shè)備。SD卡驅(qū)動(dòng)程序可以分為4層，分別為:協(xié)議層、塊設(shè)備驅(qū)動(dòng)層、抽象設(shè)備層、具體設(shè)備層。

在協(xié)議層里，規(guī)定了控制器與卡通信的具體命令，以及每個(gè)命令的類(lèi)型和返回類(lèi)型等。

在塊設(shè)備驅(qū)動(dòng)層里，mmc_block.c首先通過(guò)register_blkdev（）向內(nèi)核注冊(cè)自己，然后通過(guò)driver_register（）來(lái)注冊(cè)對(duì)應(yīng)的驅(qū)動(dòng)。驅(qū)動(dòng)里包括probe函數(shù)、remove函數(shù)、suspend函數(shù)、resume函數(shù)，在其probe函數(shù)里完成了gendisk結(jié)構(gòu)體的初始化，請(qǐng)求處理函數(shù)的設(shè)置等塊設(shè)備驅(qū)動(dòng)程序的核心。

在抽象設(shè)備層，mmc.c里實(shí)現(xiàn)了對(duì)SD卡的具體操作，如檢測(cè)卡的狀態(tài)、讀取SD卡寄存器。

在具體設(shè)備層里，davinci-mmc.c注冊(cè)了具體的SD卡設(shè)備和驅(qū)動(dòng)程序。實(shí)現(xiàn)具體的中斷處理、數(shù)據(jù)傳輸、請(qǐng)求函數(shù)。

當(dāng)有用戶向SD卡發(fā)出讀寫(xiě)命令時(shí)，命令會(huì)被內(nèi)核發(fā)送到塊設(shè)備的請(qǐng)求隊(duì)列里，調(diào)用在塊設(shè)備驅(qū)動(dòng)層里設(shè)置好的請(qǐng)求處理函數(shù)mmc_request（），mmc_request（）會(huì)喚醒mmc_queue_thread線程，而mmc_queue_thread會(huì)調(diào)用mmc_blk_issue_rq（）對(duì)請(qǐng)求進(jìn)行處理，最后請(qǐng)求會(huì)被轉(zhuǎn)換為標(biāo)準(zhǔn)協(xié)議并提交到mmc_davinci_request（）進(jìn)行命令和數(shù)據(jù)的發(fā)送與接收，具體過(guò)程，如圖2所示:

圖2

2 SD卡驅(qū)動(dòng)優(yōu)化

在Linux2.6內(nèi)核里將驅(qū)動(dòng)程序加載上之后，雖然能對(duì)SD卡進(jìn)行正常的讀寫(xiě)操作。

然而，在實(shí)際應(yīng)用中發(fā)現(xiàn)，在進(jìn)行讀寫(xiě)操作時(shí)，CPU峰值會(huì)達(dá)到80%，讀寫(xiě)速度僅為2.3MBps左右，在嵌入式系統(tǒng)資源有限和Davinci平臺(tái)高實(shí)時(shí)性要求的情況下，如此高的CPU占用率無(wú)疑會(huì)影響系統(tǒng)的正常運(yùn)行。

2.1 降低CPU峰值

2.1.1 原因分析:

由于SD卡的運(yùn)行模式會(huì)影響其傳輸速率，因此，首先檢查SD卡運(yùn)行模式:

總線頻率:25MHz（正確）

總線位寬:4bit（正確）

信令模式:多塊傳輸（正確）

搬運(yùn)模式:DMA（正確）

這說(shuō)明了SD卡運(yùn)行模式不是造成高CPU峰值的原因。開(kāi)啟內(nèi)核profile功能，對(duì)IO請(qǐng)求處理過(guò)程進(jìn)行分析，結(jié)果如表1所示:

表1

內(nèi)核profile功能的原理是每次系統(tǒng)時(shí)鐘中斷時(shí)，獲取并統(tǒng)計(jì)中斷前內(nèi)核PC指針的值。而__delay占用的系統(tǒng)tick數(shù)為2958遠(yuǎn)大于IO請(qǐng)求處理接口函數(shù)mmc_queue_thread所占用的tick數(shù)目，即等待請(qǐng)求處理函數(shù)對(duì)請(qǐng)求進(jìn)行處理的時(shí)間遠(yuǎn)大于請(qǐng)求本身被處理所需要的時(shí)間。

2.1.2 優(yōu)化

Linux內(nèi)核提供了許多延遲方法處理各種延時(shí)請(qǐng)求。不同的方法有不同的特點(diǎn)，有些是在延遲任務(wù)時(shí)掛起處理器，而另外一些則會(huì)一直占有CPU。ndelay（）、udelay（）、mdelay（）3個(gè)函數(shù)分別進(jìn)行納秒、微妙和毫秒級(jí)的延時(shí)。這3個(gè)函數(shù)都是用__udelay（）實(shí)現(xiàn)的，而__delay是忙等待，也就是說(shuō)在延遲4的過(guò)程中不會(huì)讓出CPU，從而導(dǎo)致循環(huán)等待代碼占用了過(guò)多的CPU時(shí)間。更為理想的方法是使用schedule_timeout（）函數(shù)，該方法會(huì)讓需要延遲執(zhí)行的任務(wù)睡眠到指定的延遲時(shí)間耗盡后再重新運(yùn)行，它由__schedule（）實(shí)現(xiàn)的，而__schedule（）并不是忙等待，它會(huì)在等待時(shí)讓出CPU。

找到davinci-mmc.c里的輪詢代碼將循環(huán)占用CPU（udelay）修改為循環(huán)睡眠等待（schedule_timeout）。

3.1.3 測(cè)試修改后開(kāi)啟內(nèi)核profile功能，如表2所示:

表2

上述數(shù)據(jù)說(shuō)明輪詢代碼所占用的CPU時(shí)間已經(jīng)大大減少，系統(tǒng)占用系統(tǒng)的瓶頸已經(jīng)由輪詢代碼轉(zhuǎn)移到了mmc_blk_issue_rq函數(shù)。

同時(shí)，用dd命令全力進(jìn)行讀寫(xiě)操作，CPU峰值降為20%，吞吐量為2.1MBps。

2.2 提高讀寫(xiě)速度

2.2.1 原因分析

20%的CPU峰值依然很高，而且吞吐量也因此而下降。由于mmc_blk_issue_rq為SD卡驅(qū)動(dòng)處理IO請(qǐng)求的入口函數(shù)，故CPU峰值過(guò)高的原因是IO請(qǐng)求過(guò)多或IO請(qǐng)求占用CPU時(shí)間過(guò)多。但是由于mmc_davinci_request占用的系統(tǒng)tick數(shù)很少，所以可以排除單個(gè)IO請(qǐng)求占用CPU時(shí)間過(guò)多的可能。運(yùn)行blktrace觀察IO請(qǐng)求的數(shù)量、結(jié)果，如表3所示:

表3

(其中:“179,0”代表SD卡塊設(shè)備號(hào),“D”代表issued,”C”代表complete,“W”代表write,“x+y”代表塊設(shè)備上從偏移量x個(gè)扇區(qū)開(kāi)始,長(zhǎng)度為y個(gè)扇區(qū)的區(qū)域)

Blktrace的原理為對(duì)IO請(qǐng)求處理路徑上的各個(gè)關(guān)鍵處理點(diǎn)進(jìn)行實(shí)時(shí)統(tǒng)計(jì)，上述數(shù)據(jù)說(shuō)明了SD卡驅(qū)動(dòng)每次處理的IO請(qǐng)求僅為16個(gè)扇區(qū)，IO請(qǐng)求大小僅為8KB（16*512B=8KB），每次傳輸?shù)臄?shù)據(jù)量過(guò)小，導(dǎo)致傳輸效率低，IO請(qǐng)求過(guò)多，CPU峰值過(guò)高。

SD卡IO請(qǐng)求的大小受到DM365芯片的SD卡控制器和EDMA控制器的限制:

SD卡控制器:每次IO請(qǐng)求大小最大為64K*512B=32MB其中64K為最大的數(shù)據(jù)塊個(gè)數(shù)（MMCNBLK），512B為塊大小。

EDMA控制器:每次IO請(qǐng)求大小最大為4B*64K*64K*256=4TB其中4B為傳輸單元大小（ACNT），64K分別為傳輸行大小（BCNT）和傳輸塊大小（CCNT），256為傳輸鏈表大小（LINK）。

因此，理想情況下IO請(qǐng)求大小最大應(yīng)該為32M。

檢查EDMA控制器的參數(shù)，發(fā)現(xiàn)EDMA設(shè)置傳輸鏈表大小為2，傳輸塊大小為128KB，故可以斷定，對(duì)傳輸鏈表大小設(shè)置過(guò)小，導(dǎo)致了IO請(qǐng)求過(guò)小。

2.2.2 優(yōu)化

EDMA3提供了一種鏈接的DMA傳輸機(jī)制，允許整個(gè)PaRAM（ParameterRAM）重新加載，這種機(jī)制在ping-pong buffers、circular buffering和連續(xù)傳輸里很有效。由于EMDA3控制器最多支持256個(gè)PaRAM，故，理論上傳輸鏈表大小最大可以為256。

修改驅(qū)動(dòng)程序里EDMA鏈表的設(shè)計(jì)，使其支持16個(gè)傳輸塊（不采用256個(gè)傳輸塊，因?yàn)槠渌绦蛞惨玫紻MA傳輸塊）。

2.2.3 測(cè)試

開(kāi)啟內(nèi)核profile功能、數(shù)據(jù)，如表4所示:

表4

上述數(shù)據(jù)說(shuō)明系統(tǒng)的瓶頸已經(jīng)由IO請(qǐng)求處理入口函數(shù)轉(zhuǎn)移到了write系統(tǒng)調(diào)用的拷貝上。同時(shí)，用dd命令全力進(jìn)行讀寫(xiě)操作，CPU峰值降為10%，吞吐量為6MBps。相比于優(yōu)化前的80%CPU峰值和2.3MBps吞吐量，有了很大的提高

3 總結(jié)

本文給出了Davinci平臺(tái)的SD卡驅(qū)動(dòng)程序的優(yōu)化方案，經(jīng)過(guò)優(yōu)化后的SD卡驅(qū)動(dòng)程序降低了CPU峰值，提高了讀寫(xiě)速度，已經(jīng)完全能夠滿足davinci平臺(tái)下的應(yīng)用。

但在改進(jìn)的過(guò)程中發(fā)現(xiàn)，因?yàn)镈MA連接數(shù)位2，傳輸塊大小設(shè)置為128KB，因此IO請(qǐng)求的大小也應(yīng)該為256KB，但實(shí)際上IO請(qǐng)求大小卻只有8K，說(shuō)明傳輸塊的大小并沒(méi)有達(dá)到所設(shè)置的128K。分析原因后發(fā)現(xiàn)由于系統(tǒng)采用4KB大小內(nèi)存頁(yè)存儲(chǔ)IO請(qǐng)求數(shù)據(jù)，多個(gè)連續(xù)的內(nèi)存頁(yè)作為一個(gè)DMA傳輸塊進(jìn)行傳輸，當(dāng)內(nèi)存頁(yè)不連續(xù)時(shí)，最壞情況下，每個(gè)傳輸塊只有一個(gè)4KB內(nèi)存頁(yè)，無(wú)法達(dá)到預(yù)期的128K，所以IO請(qǐng)求實(shí)際大小只有8K（4KB*2）。未來(lái)優(yōu)化方向?yàn)檠芯咳绾伪M可能的將數(shù)據(jù)集中在一個(gè)傳輸塊內(nèi)進(jìn)行傳輸，進(jìn)一步提高效率。

[1]（美）Corbet,J等著；魏永明，耿岳，鐘屬毅譯.linux設(shè)備驅(qū)動(dòng)程序[M].北京:中國(guó)電力出版社.2008

[2]TMS320DM36xDigital Media System-on-Chip(DMSoC)Multimedia Card/Secure Digital Card Controller User's Guide.www.ti.com.cn.2010

[3]紀(jì)竟舟，付宇卓；嵌入式linux下的MMC/SD卡的原理及其實(shí)現(xiàn)[M].上海:上海交通大學(xué)芯片7與系統(tǒng)研究中心.2005