轉載於 : http://blog.csdn.net/myarrow/article/details/8279156
1. USB協議
1.1 USB主機系統
在USB主機系統中，通過根集線器與外部USB從機設備相連的處理芯片，稱為USB主機控制器。USB主機控制器包含硬件、軟件和固件一部分。
1.2 USB設備系統
USB設備按功能分為兩部分：集線器(Hub)和功能部件。從下圖可知，主機通過根集線器連接到各種外圍設備(集線器和功能部件)。
1.3 主機和設備之間通信模型
主機與設備之間的通信模型
上圖展示了USB主機和USB設備之間的數據傳輸過程。在設備端，USB設備將非USB格式的數據進行打包處理，轉換成USB格式的數據包，然后傳遞到鏈路層，經過硬件處理、傳遞到物理層，由物理層通過PHY以數據流的形式傳輸到主機。
USB主機在USB設備和USB主機之間發起的傳輸過程，穩為事務。每次事務以2到3個數據包的形式進行USB總線傳輸。每個數據包包含2到3個步驟：
1) USB主機控制器向USB設備發出命令
2) USB控制器和USB設備之間傳遞讀寫請求，其方向取決於第一部分的命令是讀還是寫
3) 握手信號。
USB主機控制器向USB設備發送事務類型請求，通過分組標識符來進行識別。
1.4 USB分組標識
主機和設備之間進行操作，通過分組標識(PID)來進行傳輸。數據包傳輸格式一般由：PID、數據/控制信息、CRC校驗碼組成。
常見的PID主要包括令牌、數據、握手等類型組成。PID碼以特定的方式組成，如下表所示：
PID分組碼是數據傳輸流程中的重要元素。無論硬件還是軟件，都要對PID分組碼進行分析，從而做出正確響應。USB主機和設備嚴格按照PID分組碼信息進行信息交互。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
附加:
數據是由二進制數字串構成的，首先數字串構成域（有七種），域再構成包，包再構成事務（IN、OUT、SETUP），事務最后構成傳輸（中斷傳輸、並行傳輸、批量傳輸和控制傳輸）。
（一）域：是USB數據最小的單位，由若干位組成（至於是多少位由具體的域決定），域可分為七個類型：
1、同步域（SYNC），八位，值固定為0000 0001，用於本地時鍾與輸入同步；
2、標識域（PID），由四位標識符+四位標識符反碼構成，表明包的類型和格式，這是一個很重要的部分，這里可以計算出，USB的標識碼有16種；
3、地址域（ADDR）：七位地址，代表了設備在主機上的地址，地址000 0000被命名為零地址，是任何一個設備第一次連接到主機時，在被主機配置、枚舉前的默認地址，由此可以知道為什么一個USB主機只能接127個設備的原因。
4、端點域（ENDP），四位，由此可知一個USB設備有的端點數量最大為16個。
5、幀號域（FRAM），11位，每一個幀都有一個特定的幀號，幀號域最大容量0x800，對於同步傳輸有重要意義（同步傳輸為四種傳輸類型之一）。
6、數據域（DATA）：長度為0~1023字節，在不同的傳輸類型中，數據域的長度各不相同，但必須為整數個字節的長度
7、校驗域（CRC）：對令牌包和數據包（對於包的分類請看下面）中非PID域進行校驗的一種方法，CRC校驗在通訊中應用很泛，是一種很好的校驗方法，至於具體的校驗方法這里就不多說，請查閱相關資料，只須注意CRC碼的除法是模2運算，不同於10進制中的除法。
（二）包：由域構成的包有四種類型，分別是令牌包、數據包、握手包和特殊包，前面三種是重要的包，不同的包的域結構不同，介紹如下
1、令牌包：可分為輸入包、輸出包、設置包和幀起始包（注意這里的輸入包是用於設置輸入命令的，輸出包是用來設置輸出命令的，而不是放據數的） 其中輸入包、輸出包和設置包的格式都是一樣的：
SYNC+PID+ADDR+ENDP+CRC5（五位的校驗碼）
幀起始包的格式：
SYNC+PID+11位FRAM+CRC5（五位的校驗碼）
2、數據包：分為DATA0包和DATA1包，當USB發送數據的時候，當一次發送的數據長度大於相應端點的容量時，就需要把數據包分為好幾個包，分批發送，DATA0包和DATA1包交替發送，即如果第一個數據包是 DATA0，那第二個數據包就是DATA1。但也有例外情況，在同步傳輸中（四類傳輸類型中之一），所有的數據包都是為DATA0，格式如下：
SYNC+PID+0~1023字節+CRC16
3、握手包：結構最為簡單的包，格式如下 SYNC+PID
（三）事務：分別有IN事務、OUT事務和SETUP事務三大事務，每一種事務都由令牌包、數據包、握手包三個階段構成，這里用階段的意思是因為這些包的發送是有一定的時間先后順序的，事務的三個階段如下：
1、令牌包階段：啟動一個輸入、輸出或設置的事務
2、數據包階段：按輸入、輸出發送相應的數據
3、握手包階段：返回數據接收情況，在同步傳輸的IN和OUT事務中沒有這個階段，這是比較特殊的。
事務的三種類型如下（以下按三個階段來說明一個事務）：
1、 IN事務：
令牌包階段——主機發送一個PID為IN的輸入包給設備，通知設備要往主機發送數據；
數據包階段——設備根據情況會作出三種反應（要注意：數據包階段也不總是傳送數據的，根據傳輸情況還會提前進入握手包階段）
1） 設備端點正常，設備往入主機里面發出數據包（DATA0與DATA1交替）；
2） 設備正在忙，無法往主機發出數據包就發送NAK無效包，IN事務提前結束，到了下一個IN事務才繼續；
3） 相應設備端點被禁止，發送錯誤包STALL包，事務也就提前結束了，總線進入空閑狀態。
握手包階段——主機正確接收到數據之后就會向設備發送ACK包。
2、 OUT事務：
令牌包階段——主機發送一個PID為OUT的輸出包給設備，通知設備要接收數據；
數據包階段——比較簡單，就是主機會給設備送數據，DATA0與DATA1交替
握手包階段——設備根據情況會作出三種反應
1）設備端點接收正確，設備往入主機返回ACK，通知主機可以發送新的數據，如果數據包發生了CRC校驗錯誤，將不返回任何握手信息；
2）設備正在忙，無法接收主機發出數據包就發送NAK無效包，通知主機再次發送數據；
3）相應設備端點被禁止，發送錯誤包STALL包，事務提前結束，總線直接進入空閑狀態。
3、SETUT事務：
令牌包階段——主機發送一個PID為SETUP的輸出包給設備，通知設備要接收數據；
數據包階段——比較簡單，就是主機會設備送數據，注意，這里只有一個固定為8個字節的DATA0包，這8個字節的內容就是標准的USB設備請求命令（共有11條）
握手包階段——設備接收到主機的命令信息后，返回ACK，此后總線進入空閑狀態，並准備下一個傳輸（在SETUP事務后通常是一個IN或OUT事務構成的傳輸）
（四）傳輸：傳輸由OUT、IN、SETUP事務其中的事務構成，傳輸有四種類型，中斷傳輸、批量傳輸、同步傳輸、控制傳輸，其中中斷傳輸和批量轉輸的結構一樣，同步傳輸有最簡單的結構，而控制傳輸是最重要的也是最復雜的傳輸。
1、中斷傳輸：由OUT事務和IN事務構成，用於鍵盤、鼠標等HID設備的數據傳輸中
2、批量傳輸：由OUT事務和IN事務構成，用於大容量數據傳輸，沒有固定的傳輸速率，也不占用帶寬，當總線忙時，USB會優先進行其他類型的數據傳輸，而暫時停止批量轉輸。
3、同步傳輸：由OUT事務和IN事務構成，有兩個特殊地方，第一，在同步傳輸的IN和OUT事務中是沒有返回包階段的；第二，在數據包階段所有的數據包都為DATA0
4、控制傳輸：最重要的也是最復雜的傳輸，控制傳輸由三個階段構成（初始設置階段、可選數據階段、狀態信息步驟），每一個階段可以看成一個的傳輸，也就是說控制傳輸其實是由三個傳輸構成的，用來於USB設備初次加接到主機之后，主機通過控制傳輸來交換信息，設備地址和讀取設備的描述符，使得主機識別設備，並安裝相應的驅動程序，這是每一個USB開發者都要關心的問題。
1)、初始設置步驟：就是一個由SET事務構成的傳輸;
2)、可選數據步驟：就是一個由IN或OUT事務構成的傳輸，這個步驟是可選的，要看初始設置步驟有沒有要求讀/寫數據（由SET事務的數據包階段發送的標准請求命令決定）;
3)、狀態信息步驟：顧名思義，這個步驟就是要獲取狀態信息，由IN或OUT事務構成構成的傳輸，但是要注意這里的IN和OUT事務和之前的INT和OUT事務有兩點不同：
(1) 傳輸方向相反，通常IN表示設備往主機送數據，OUT表示主機往設備送數據；在這里，IN表示主機往設備送數據，而OUT表示設備往主機送數據，這是為了和可選數據步驟相結合；
(2) 在這個步驟里，數據包階段的數據包都是0長度的，即SYNC+PID+CRC16
--------------------------------------------------------------------------------------------------------------------------------------------------
1.5 數據包傳輸模式
當USB設備連接到集線器，集線器狀態將發生相應的變化，並將狀態變化信息傳遞給USB主機。USB主機通過根集線器向USB設備發送命令，獲取USB設備的各種信息，包含USB設備傳輸類型、ID號、Product、USB速度等信息。
USB主機和USB設備之間的數據傳輸共有四種類型：控制傳輸、批量傳輸、中斷傳輸和同頻傳輸。與之對應，USB主機和USB設備之間有四種事務：控制事務、批量事務、中斷事務和同步事務。
1.5.1 批量(Bulk)傳輸
作用：主要用於非實時性傳輸，數據包較大而延時要求較低。
特點：數據傳輸准備即可，采用批量傳輸模式的USB從機設備，如U盤
數據傳輸分三個階段：
a) 令牌階段：主機發送請求，USB設備依據請求PID來判斷IN或OUT傳輸
b) 數據傳輸階段：依據令牌階段的IN或OUT傳輸，來決定數據傳輸為DATA0或DATA1來進行數據傳輸
c) 握手階段：接收信息的一方發送ACK信號以表示接收成功；若為NAK，表示發送失敗；STALL表示不可預知的錯誤
1.5.2 控制(Control)傳輸
作用：USB傳輸過程必須支持的傳輸模式。USB主機為了獲取設備描述符、ID、Product等信息，向USB設備發送相應的PID命令。
特點：唯一可以進行IN/OUT傳輸的傳輸模式。
數據寬度：控制傳輸方式可以以8、16、32或64字節的數據進行傳輸，這取決於設備的傳輸速度。
USB主機和設備之間必須支持控制傳輸，通過端點0進行數據傳輸。控制傳輸分為令牌、數據傳輸和握手階段。
1.5.3 中斷傳輸事務
作用：按照一定時刻輪詢設備是否有中斷傳輸請求
特點：查詢頻率取決於端點的模式結構，從1到255ms不等
中斷傳輸主要用於實時性要求非常高的從機設備，如鍵盤操縱桿和Mouse等
傳輸過程也分為令牌階段、數據傳輸和握手階段
1.6 USB描述符
USB協議中共定義了以下四種描述符：
1) 設備描述符
2) 配置描述符
3) 接口描述符
4) 端點描述符
其關系如下圖所示：
1.6.1 設備描述符
每個USB設備都有一個唯一的設備描述符，如下表所示：
1.6.2 配置描述符
每個USB設備都有默認的配置描述符，支持至少一個接口，每個配置描述符如下表：
1.6.3 接口描述符
設備應至少支持一個接口，如：塊傳輸數據接口，部分設備可能支持其它的接口。復合設備可以支持額外接口，以支持音頻和視頻功能。標准中並沒有定義此類接口。接口可能有多個可選設置，主機將會檢查每個可選的設置。
1.6.4 端點描述符
每個設備至少支持控制端點0。USB設備應該支持三類端點：控制端點、輸入端點和輸出端點。
2. OTG協議
OTG設備采用Mini-AB插座，相對於傳統的USB數據線，Mini-AB接口多了一根數據線ID，ID線是否接入將Mini-AB接口分為Mini-A和Mini-B接口兩種類型。在OTG設備之間數據連接的過程中，通過OTG數據線Mini-A和Mini-B接口來確定OTG設備的主從：接入Mini-A接口的設備默認為A設備(主機設備)；接入Mini-B接口的設備，默認為B設備(從設備)。
A設備和B設備無需交換電纜接口，即可通過主機交換協議(HNP)實現A、B設備之間的角色互換。同時，為了節省電源，OTG允許總線空閑時A設備判斷電源。此時，若B設備希望使用總線，可以通過會話請求協議(SRP)請求A設備提供電源。
2.1 HNP(主機交換)協議
當Mini-A接口接入A設備並確定A設備為主機時；若B設備希望成為主機，則A設備向B設備發送SetFeature命令，允許B設備進行主機交換。B設備檢測到總線掛起5ms后，即掛起D+並啟動HNP，使總線處於SE0狀態。此時A設備檢測到總線處於SE0狀態，即認為B設備發起主機交換，A設備進行響應。待B設備發現D+線為高電平而D-線為低電平(J狀態)，表示A設備識別了B設備的HNP請求。B設備開始總線復位並具有總線控制權，主機交換協議完成。
2.2 SRP(會話請求)協議
對於主機，要求能響應會話請求；對於設備，僅要求能夠發起SRP協議。OTG設備，不僅要求發起SRP，而且還能響應SRP請求。
SRP分為數據線脈沖調制和電壓脈沖調兩種方式，B設備發起SRP必須滿足以下兩個條件：
1) B設備檢測到A設備低於其有效的電壓閾值，同時B設備低於有效的電壓閾值。
2) B設備必須檢測到D+和D-數據線至少在2ms的時間內低於有效閾值，即處於SE0狀態。
數據線脈沖調制會話請求：B設備必須等到滿足以上兩個條件后，將數據線接入上拉電阻一定的時間，以備A設備過濾數據線上的瞬間電壓。與此同時，B設備上拉D+以便於在全速模式下進行初始化操作。A設備在檢測到D+變為高電平或D-變為低電平時產生SRP指示信號。
Vbus脈沖調制會話請求：B設備同樣需等待滿足上述兩個初始化條件，然后B設備通過對電容充電以提高總線電壓，待達到總線上的電壓閾值，喚醒A設備。在充電過程中，一定要保證充電的電壓峰值在一定的范圍以避免燒壞A設備。
3. USB驅動架構
USB驅動架構如下圖所示：
3.1 USB主機端驅動
USB核心(USBD)是整個USB驅動的核心部分，從上圖可知，一方面USBD對接收到USB主機控制器的數據進行處理，並傳遞給上層的設備端驅動軟件；同時也接收來自上層的非USB格式數據流，進行相應的數據處理后傳遞給USB主機控制器驅動。
USB數據傳輸都以URB(USB Request Block)請求、URB生成、URB遞交、URB釋放為主線。從上圖可知，當加載控制器驅動之后，注冊根據集線器，hub和hcd驅動成為一個整體。接着，主機通過控制傳輸獲取設備的控制描述符等信息，接着詳述整個控制傳輸的流程。usb_submit_urb依據是否連接到根集線器來決定調用urb_enqueue或rh_urb_enqueue函數。
USB從設備通過集線器或根集線器連接到USB主機上。比如：主機通過根集線器與外界進行數據交互，根集線器通過探測數據線狀態的變化來通知USB主機是否有USB外圍設備接入。
在主機端控制器驅動加載的過程中，注冊了根集線器，然后匹配了相應的hub驅動程序，同時完成了對Hub的輪詢函數和狀態處理函數的設置。這樣，一旦hub集線器的狀態發生變化，就會產生相應的中斷，主機端控制器就會執行相應的中斷處理函數，下圖為hub驅動程序的流程圖。
USB Core中的usb_init()函數中完成了對hub線程(khubd，在usb_hub_init函數中真正地創建)的創建，然后完成相應設備的探測。主機端控制器驅動進行探測時，將hub驅動和主機端控制器驅動結合在一起，相互之間完成調用。 相對於大容量存儲設備與主機之間通過控制/批量傳輸，集線器與主機之間通過中斷/控制方式完成數據交互。
3.2 USB設備端驅動
從上圖可知，設備端驅動包含兩部分：
1) 底層設備控制器驅動
2) 上層大容量存儲類驅動
3.2.1 設備控制器驅動
USB設備控制器驅動主要實現Gadget API定義的函數和中斷服務函數，可按功能划分為：API函數實現模塊和中斷處理模塊。
API函數主要實現Gadget API定義的函數功能，如結構體usb_ep_ops和usb_gadget_ops中的函數、usb_gadget_register_driver函數。這些函數是供Gadget Driver調用。
中斷處理模塊主要處理設備控制器產生的各種中斷，包括端點中斷、復位、掛起等中斷。
上圖為設備端控制器基本架構，主要完成了Gadget驅動和控制器驅動綁定、usb_gadget_register_driver注冊。
3.3 OTG驅動
OS_FS: 文件系統
USBD: USB核心
HCD: 主機控制器驅動
UDC: 設備端控制器驅動
OTG設備支持HNP和SRP協議。OTG設備通過USB OTG電纜連接到一起，其中接Mini-A接口的設備為A設備，默認為主機端，Mini-B接口的設備默認為B設備。當A、B設備完成數據交互之后，A、B設備之間的USB OTG電纜進入掛起狀態，如下圖所示：
當B設備寫入b_bus_req，向A設備發起HNP請求。待A設備響應之后，A設備發送a_set_b_hnp_en，B設備響應之后即進入主機狀態，同時發送請求使用A設備set_device，這樣A、B設備完成主從交換。
4. USB 傳輸流程
4.1 USB初始化過程
USB驅動作為一個系統，集成了眾多的驅動模塊，注冊過程非常復雜。從USB系統的角度來說，USB主機驅動主要包含：
1) USB核驅動
2) 主機控制器驅動
3) 集線器驅動
驅動的加載執行流程如下圖所示：
USB初始化過程
4.1.1 USB Core的初始化
USB驅動從USB子系統的初始化開始，USB子系統的初始化在文件driver/usb/core/usb.c
- subsys_initcall(usb_init);
- module_exit(usb_exit);
subsys_initcall()是一個宏，可以理解為module_init()。由於此部分代碼非常重要，開發者把它看作一個子系統，而不僅僅是一個模塊。USB Core這個模塊代表的不是某一個設備，而是所有USB設備賴以生存的模塊。在Linux中，像這樣一個類別的設備驅動被歸結為一個子系統。subsys_initcall(usb_init)告訴我們，usb_init才是真正的初始化函數，而usb_exit將是整個USB子系統結束時的清理函數。
4.1.2 主機控制器的初始化及驅動執行(以EHCI為例)
module_init(otg_init); 模塊注冊
static init __init otg_init(void);
platform_driver_register(); 平台注冊
static int __init otg_probe(struct platform_device *pdev); 探測處理函數
reg = platform_get_resource(pdev, IORESOURCE_MEM, 0); 獲取寄存器信息
data = platform_get_resource(pdev,IORESOURCE_MEM, 1); 獲取內存信息
irq = platform_get_irq(pdev,0); 獲取中斷號
usb_create_hcd(&otg_hc_driver, &pdev->dev, pdev->dev.bus_id);
分配和初始化HCD結構體。對設備數據空間進行分配，初始化計數器、總線、定時器、hcd結構體各成員值。
ret = usb_add_hcd(hcd,irq,SA_INTERRUPT);
完成HCD結構體的初始化和注冊。申請buffer，注冊總線、分配設備端內存空間，向中斷向量表中申請中斷，注冊根集線器，對根集線器狀態進行輪詢。
4.1.3 注冊集線器
register_root_hub(hcd);
在USB系統驅動加載的過程中，創建了集線器的線程(khubd)，並且一直查詢相應的線程事務。HCD驅動中，將集線器作為一個設備添加到主機控制器驅動中，然后進行集線器端口的初始化。在USB主機看來，根集線器本身也是USB主機的設備。USB主機驅動加載完成之后，即開始注冊根集線器，並且作為一個設備加載到主機驅動之中。
USB主機和USB設備之間進行數據交互，USB設備本身並沒有總線控制權，U盤被動地接收USB主機發送過來的信息並做出響應。USB主機控制器與根集線器構成了主機系統，然后外接其它的USB設備。
為了更好地探測到根集線器的狀態變化，USB主機控制器驅動增加了狀態輪詢函數，以一定的時間間隔輪詢根集線器狀態是否發生變化。一旦根集線器狀態發生變化，主機控制器就會產生相應的響應。
USB主機和USB設備之間的數據傳輸以URB(USB Request Block)的形式進行。
4.2 URB傳輸過程
USB初始化過程中，無論是主機控制器驅動還是根集線器驅動，都是通過URB傳輸獲取設備信息。
4.2.1 申請URB
struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)
為urb分配內存並執行初始化。
4.2.2 初始化URB
初始化具體的urb包
- static inline void usb_fill_bulk_urb(struct urb *urb,
- struct usb_device *dev,
- unsigned int pipe,
- void *transfer_buffer,
- int buffer_length,
- usb_complete_t complete_fn,
- void *context)
- static inline void usb_fill_control_urb(struct urb *urb,
- struct usb_device *dev,
- unsigned int pipe,
- unsigned char *setup_packet,
- void *transfer_buffer,
- int buffer_length,
- usb_complete_t complete_fn,
- void *context)
- static inline void usb_fill_int_urb(struct urb *urb,
- struct usb_device *dev,
- unsigned int pipe,
- void *transfer_buffer,
- int buffer_length,
- usb_complete_t complete_fn,
- void *context,
- int interval)
不同的傳輸模式下，驅動為之申請不同的URB。其中，Linux內核只支持同步傳輸外的三種傳輸事件，ISO事務需要手工進行初始化工作。控制傳輸事務、批量傳輸事務、中斷傳輸事務API如上所示。
三種事務傳輸模式下的URB初始化函數有很多相似之處，主要參數含義如下：
• urb: 事務傳輸中的urb
• dev: 事務傳輸的目的設備
• pipe: USB主機與USB設備之間數據傳輸的通道
• transfer_buffer: 發送數據所申請的內存緩沖區首地址
• length: 發送數據緩沖區的長度
• context: complete函數的上下文
• complete_fn: 調用完成函數
• usb_fill_control_urb()的setup_packet: 即將被發送的設備數據包
• usb_fill_int_urb()的interval: 中斷傳輸中兩個URB調度的時間間隔
4.2.3 提交URB
URB初始化完成之后，USBD開始通過usb_start_wait_urb()提交urb請求(它調用usb_submit_urb來真正的發送URB請求)，添加completition函數。
接下來，從message.c傳到主機控制器(hcd.c)，開始真正的usb_hcd_submit_urb()。此時，根據是否為根集線器，進入不同的工作隊列。
usb_start_wait_urb->
usb_submit_urb->
usb_hcd_submit_urb
a) root_hub傳輸
若為root hub，將調用rh_urb_enqueue()，共有兩種傳輸事務(控制傳輸和中斷傳輸)
- static int rh_urb_enqueue (struct usb_hcd *hcd, struct urb *urb)
- {
- if (usb_endpoint_xfer_int(&urb->ep->desc)) // 中斷傳輸
- return rh_queue_status (hcd, urb);
- if (usb_endpoint_xfer_control(&urb->ep->desc)) // 控制傳輸
- return rh_call_control (hcd, urb);
- return -EINVAL;
- }
b) 非root_hub傳輸
對於非常root_hub傳輸，它調用:
status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);
c) 批量傳輸
root_hub本身沒有批量傳輸流程，按照控制傳輸流程，控制傳輸最終要通過switch語句跳轉到Bulk-Only傳輸流程中。