當(dāng)前位置:首頁 > 技術(shù)學(xué)院 > 技術(shù)前線
[導(dǎo)讀]在USB主機(jī)系統(tǒng)中,通過根集線器與外部USB從機(jī)設(shè)備相連的處理芯片,稱為USB主機(jī)控制器。USB主機(jī)控制器包含硬件、軟件和固件一部分。

1. USB協(xié)議

1.1 USB主機(jī)系統(tǒng)

在USB主機(jī)系統(tǒng)中,通過根集線器與外部USB從機(jī)設(shè)備相連的處理芯片,稱為USB主機(jī)控制器。USB主機(jī)控制器包含硬件、軟件和固件一部分。

1.2 USB設(shè)備系統(tǒng)

USB設(shè)備按功能分為兩部分:集線器(Hub)和功能部件。從下圖可知,主機(jī)通過根集線器連接到各種外圍設(shè)備(集線器和功能部件)。

1.3 主機(jī)和設(shè)備之間通信模型

主機(jī)與設(shè)備之間的通信模型

上圖展示了USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸過程。在設(shè)備端,USB設(shè)備將非USB格式的數(shù)據(jù)進(jìn)行打包處理,轉(zhuǎn)換成USB格式的數(shù)據(jù)包,然后傳遞到鏈路層,經(jīng)過硬件處理、傳遞到物理層,由物理層通過PHY以數(shù)據(jù)流的形式傳輸?shù)街鳈C(jī)。

USB主機(jī)在USB設(shè)備和USB主機(jī)之間發(fā)起的傳輸過程,穩(wěn)為事務(wù)。每次事務(wù)以2到3個數(shù)據(jù)包的形式進(jìn)行USB總線傳輸。每個數(shù)據(jù)包包含2到3個步驟:

1) USB主機(jī)控制器向USB設(shè)備發(fā)出命令

2) USB控制器和USB設(shè)備之間傳遞讀寫請求,其方向取決于第一部分的命令是讀還是寫

3) 握手信號。

USB主機(jī)控制器向USB設(shè)備發(fā)送事務(wù)類型請求,通過分組標(biāo)識符來進(jìn)行識別。

1.4 USB分組標(biāo)識

主機(jī)和設(shè)備之間進(jìn)行操作,通過分組標(biāo)識(PID)來進(jìn)行傳輸。數(shù)據(jù)包傳輸格式一般由:PID、數(shù)據(jù)/控制信息、CRC校驗碼組成。

常見的PID主要包括令牌、數(shù)據(jù)、握手等類型組成。PID碼以特定的方式組成,如下表所示:

PID分組碼是數(shù)據(jù)傳輸流程中的重要元素。無論硬件還是軟件,都要對PID分組碼進(jìn)行分析,從而做出正確響應(yīng)。USB主機(jī)和設(shè)備嚴(yán)格按照PID分組碼信息進(jìn)行信息交互。

1.5 數(shù)據(jù)包傳輸模式

當(dāng)USB設(shè)備連接到集線器,集線器狀態(tài)將發(fā)生相應(yīng)的變化,并將狀態(tài)變化信息傳遞給USB主機(jī)。USB主機(jī)通過根集線器向USB設(shè)備發(fā)送命令,獲取USB設(shè)備的各種信息,包含USB設(shè)備傳輸類型、ID號、Product、USB速度等信息。

USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸共有四種類型:控制傳輸、批量傳輸、中斷傳輸和同頻傳輸。與之對應(yīng),USB主機(jī)和USB設(shè)備之間有四種事務(wù):控制事務(wù)、批量事務(wù)、中斷事務(wù)和同步事務(wù)。

1.5.1 批量(Bulk)傳輸

作用:主要用于非實時性傳輸,數(shù)據(jù)包較大而延時要求較低。

特點:數(shù)據(jù)傳輸準(zhǔn)備即可,采用批量傳輸模式的USB從機(jī)設(shè)備,如U盤

數(shù)據(jù)傳輸分三個階段:

a) 令牌階段:主機(jī)發(fā)送請求,USB設(shè)備依據(jù)請求PID來判斷IN或OUT傳輸

b) 數(shù)據(jù)傳輸階段:依據(jù)令牌階段的IN或OUT傳輸,來決定數(shù)據(jù)傳輸為DATA0或DATA1來進(jìn)行數(shù)據(jù)傳輸

c) 握手階段:接收信息的一方發(fā)送ACK信號以表示接收成功;若為NAK,表示發(fā)送失敗;STALL表示不可預(yù)知的錯誤

1.5.2 控制(Control)傳輸

作用:USB傳輸過程必須支持的傳輸模式。USB主機(jī)為了獲取設(shè)備描述符、ID、Product等信息,向USB設(shè)備發(fā)送相應(yīng)的PID命令。

特點:唯一可以進(jìn)行IN/OUT傳輸?shù)膫鬏斈J健?

數(shù)據(jù)寬度:控制傳輸方式可以以8、16、32或64字節(jié)的數(shù)據(jù)進(jìn)行傳輸,這取決于設(shè)備的傳輸速度。

USB主機(jī)和設(shè)備之間必須支持控制傳輸,通過端點0進(jìn)行數(shù)據(jù)傳輸??刂苽鬏敺譃榱钆?、數(shù)據(jù)傳輸和握手階段。

1.5.3 中斷傳輸事務(wù)

作用:按照一定時刻輪詢設(shè)備是否有中斷傳輸請求

特點:查詢頻率取決于端點的模式結(jié)構(gòu),從1到255ms不等

中斷傳輸主要用于實時性要求非常高的從機(jī)設(shè)備,如鍵盤操縱桿和Mouse等

傳輸過程也分為令牌階段、數(shù)據(jù)傳輸和握手階段

1.6 USB描述符

USB協(xié)議中共定義了以下四種描述符:

1) 設(shè)備描述符

2) 配置描述符

3) 接口描述符

4) 端點描述符

其關(guān)系如下圖所示:

1.6.1 設(shè)備描述符

每個USB設(shè)備都有一個唯一的設(shè)備描述符,如下表所示:

1.6.2 配置描述符

每個USB設(shè)備都有默認(rèn)的配置描述符,支持至少一個接口,每個配置描述符如下表:

1.6.3 接口描述符

設(shè)備應(yīng)至少支持一個接口,如:塊傳輸數(shù)據(jù)接口,部分設(shè)備可能支持其它的接口。復(fù)合設(shè)備可以支持額外接口,以支持音頻和視頻功能。標(biāo)準(zhǔn)中并沒有定義此類接口。接口可能有多個可選設(shè)置,主機(jī)將會檢查每個可選的設(shè)置。

1.6.4 端點描述符

每個設(shè)備至少支持控制端點0。USB設(shè)備應(yīng)該支持三類端點:控制端點、輸入端點和輸出端點。

2. OTG協(xié)議

OTG設(shè)備采用Mini-AB插座,相對于傳統(tǒng)的USB數(shù)據(jù)線,Mini-AB接口多了一根數(shù)據(jù)線ID,ID線是否接入將Mini-AB接口分為Mini-A和Mini-B接口兩種類型。在OTG設(shè)備之間數(shù)據(jù)連接的過程中,通過OTG數(shù)據(jù)線Mini-A和Mini-B接口來確定OTG設(shè)備的主從:接入Mini-A接口的設(shè)備默認(rèn)為A設(shè)備(主機(jī)設(shè)備);接入Mini-B接口的設(shè)備,默認(rèn)為B設(shè)備(從設(shè)備)。

A設(shè)備和B設(shè)備無需交換電纜接口,即可通過主機(jī)交換協(xié)議(HNP)實現(xiàn)A、B設(shè)備之間的角色互換。同時,為了節(jié)省電源,OTG允許總線空閑時A設(shè)備判斷電源。此時,若B設(shè)備希望使用總線,可以通過會話請求協(xié)議(SRP)請求A設(shè)備提供電源。

2.1 HNP(主機(jī)交換)協(xié)議

當(dāng)Mini-A接口接入A設(shè)備并確定A設(shè)備為主機(jī)時;若B設(shè)備希望成為主機(jī),則A設(shè)備向B設(shè)備發(fā)送SetFeature命令,允許B設(shè)備進(jìn)行主機(jī)交換。B設(shè)備檢測到總線掛起5ms后,即掛起D+并啟動HNP,使總線處于SE0狀態(tài)。此時A設(shè)備檢測到總線處于SE0狀態(tài),即認(rèn)為B設(shè)備發(fā)起主機(jī)交換,A設(shè)備進(jìn)行響應(yīng)。待B設(shè)備發(fā)現(xiàn)D+線為高電平而D-線為低電平(J狀態(tài)),表示A設(shè)備識別了B設(shè)備的HNP請求。B設(shè)備開始總線復(fù)位并具有總線控制權(quán),主機(jī)交換協(xié)議完成。

2.2 SRP(會話請求)協(xié)議

對于主機(jī),要求能響應(yīng)會話請求;對于設(shè)備,僅要求能夠發(fā)起SRP協(xié)議。OTG設(shè)備,不僅要求發(fā)起SRP,而且還能響應(yīng)SRP請求。

SRP分為數(shù)據(jù)線脈沖調(diào)制和電壓脈沖調(diào)兩種方式,B設(shè)備發(fā)起SRP必須滿足以下兩個條件:

1) B設(shè)備檢測到A設(shè)備低于其有效的電壓閾值,同時B設(shè)備低于有效的電壓閾值。

2) B設(shè)備必須檢測到D+和D-數(shù)據(jù)線至少在2ms的時間內(nèi)低于有效閾值,即處于SE0狀態(tài)。

數(shù)據(jù)線脈沖調(diào)制會話請求:B設(shè)備必須等到滿足以上兩個條件后,將數(shù)據(jù)線接入上拉電阻一定的時間,以備A設(shè)備過濾數(shù)據(jù)線上的瞬間電壓。與此同時,B設(shè)備上拉D+以便于在全速模式下進(jìn)行初始化操作。A設(shè)備在檢測到D+變?yōu)楦唠娖交駾-變?yōu)榈碗娖綍r產(chǎn)生SRP指示信號。

Vbus脈沖調(diào)制會話請求:B設(shè)備同樣需等待滿足上述兩個初始化條件,然后B設(shè)備通過對電容充電以提高總線電壓,待達(dá)到總線上的電壓閾值,喚醒A設(shè)備。在充電過程中,一定要保證充電的電壓峰值在一定的范圍以避免燒壞A設(shè)備。

3. USB驅(qū)動架構(gòu)

USB驅(qū)動架構(gòu)如下圖所示:

3.1 USB主機(jī)端驅(qū)動

USB核心(USBD)是整個USB驅(qū)動的核心部分,從上圖可知,一方面USBD對接收到USB主機(jī)控制器的數(shù)據(jù)進(jìn)行處理,并傳遞給上層的設(shè)備端驅(qū)動軟件;同時也接收來自上層的非USB格式數(shù)據(jù)流,進(jìn)行相應(yīng)的數(shù)據(jù)處理后傳遞給USB主機(jī)控制器驅(qū)動。

USB數(shù)據(jù)傳輸都以URB(USB Request Block)請求、URB生成、URB遞交、URB釋放為主線。從上圖可知,當(dāng)加載控制器驅(qū)動之后,注冊根據(jù)集線器,hub和hcd驅(qū)動成為一個整體。接著,主機(jī)通過控制傳輸獲取設(shè)備的控制描述符等信息,接著詳述整個控制傳輸?shù)牧鞒?。usb_submit_urb依據(jù)是否連接到根集線器來決定調(diào)用urb_enqueue或rh_urb_enqueue函數(shù)。

USB從設(shè)備通過集線器或根集線器連接到USB主機(jī)上。比如:主機(jī)通過根集線器與外界進(jìn)行數(shù)據(jù)交互,根集線器通過探測數(shù)據(jù)線狀態(tài)的變化來通知USB主機(jī)是否有USB外圍設(shè)備接入。

在主機(jī)端控制器驅(qū)動加載的過程中,注冊了根集線器,然后匹配了相應(yīng)的hub驅(qū)動程序,同時完成了對Hub的輪詢函數(shù)和狀態(tài)處理函數(shù)的設(shè)置。這樣,一旦hub集線器的狀態(tài)發(fā)生變化,就會產(chǎn)生相應(yīng)的中斷,主機(jī)端控制器就會執(zhí)行相應(yīng)的中斷處理函數(shù),下圖為hub驅(qū)動程序的流程圖。

USB Core中的usb_init()函數(shù)中完成了對hub線程(khubd,在usb_hub_init函數(shù)中真正地創(chuàng)建)的創(chuàng)建,然后完成相應(yīng)設(shè)備的探測。主機(jī)端控制器驅(qū)動進(jìn)行探測時,將hub驅(qū)動和主機(jī)端控制器驅(qū)動結(jié)合在一起,相互之間完成調(diào)用。 相對于大容量存儲設(shè)備與主機(jī)之間通過控制/批量傳輸,集線器與主機(jī)之間通過中斷/控制方式完成數(shù)據(jù)交互。

3.2 USB設(shè)備端驅(qū)動

從上圖可知,設(shè)備端驅(qū)動包含兩部分:

1) 底層設(shè)備控制器驅(qū)動

2) 上層大容量存儲類驅(qū)動

3.2.1 設(shè)備控制器驅(qū)動

USB設(shè)備控制器驅(qū)動主要實現(xiàn)Gadget API定義的函數(shù)和中斷服務(wù)函數(shù),可按功能劃分為:API函數(shù)實現(xiàn)模塊和中斷處理模塊。

API函數(shù)主要實現(xiàn)Gadget API定義的函數(shù)功能,如結(jié)構(gòu)體usb_ep_ops和usb_gadget_ops中的函數(shù)、usb_gadget_register_driver函數(shù)。這些函數(shù)是供Gadget Driver調(diào)用。

中斷處理模塊主要處理設(shè)備控制器產(chǎn)生的各種中斷,包括端點中斷、復(fù)位、掛起等中斷。

上圖為設(shè)備端控制器基本架構(gòu),主要完成了Gadget驅(qū)動和控制器驅(qū)動綁定、usb_gadget_register_driver注冊。

3.3 OTG驅(qū)動

OS_FS: 文件系統(tǒng)

USBD: USB核心

HCD: 主機(jī)控制器驅(qū)動

UDC: 設(shè)備端控制器驅(qū)動

OTG設(shè)備支持HNP和SRP協(xié)議。OTG設(shè)備通過USB OTG電纜連接到一起,其中接Mini-A接口的設(shè)備為A設(shè)備,默認(rèn)為主機(jī)端,Mini-B接口的設(shè)備默認(rèn)為B設(shè)備。當(dāng)A、B設(shè)備完成數(shù)據(jù)交互之后,A、B設(shè)備之間的USB OTG電纜進(jìn)入掛起狀態(tài),如下圖所示:

當(dāng)B設(shè)備寫入b_bus_req,向A設(shè)備發(fā)起HNP請求。待A設(shè)備響應(yīng)之后,A設(shè)備發(fā)送a_set_b_hnp_en,B設(shè)備響應(yīng)之后即進(jìn)入主機(jī)狀態(tài),同時發(fā)送請求使用A設(shè)備set_device,這樣A、B設(shè)備完成主從交換。

4. USB 傳輸流程

4.1 USB初始化過程

USB驅(qū)動作為一個系統(tǒng),集成了眾多的驅(qū)動模塊,注冊過程非常復(fù)雜。從USB系統(tǒng)的角度來說,USB主機(jī)驅(qū)動主要包含:

1) USB核驅(qū)動

2) 主機(jī)控制器驅(qū)動

3) 集線器驅(qū)動

驅(qū)動的加載執(zhí)行流程如下圖所示:

USB初始化過程

4.1.1 USB Core的初始化

USB驅(qū)動從USB子系統(tǒng)的初始化開始,USB子系統(tǒng)的初始化在文件driver/usb/core/usb.c

subsys_initcall(usb_init);

module_exit(usb_exit);

subsys_initcall()是一個宏,可以理解為module_init()。由于此部分代碼非常重要,開發(fā)者把它看作一個子系統(tǒng),而不僅僅是一個模塊。USB Core這個模塊代表的不是某一個設(shè)備,而是所有USB設(shè)備賴以生存的模塊。在Linux中,像這樣一個類別的設(shè)備驅(qū)動被歸結(jié)為一個子系統(tǒng)。subsys_initcall(usb_init)告訴我們,usb_init才是真正的初始化函數(shù),而usb_exit將是整個USB子系統(tǒng)結(jié)束時的清理函數(shù)。

4.1.2 主機(jī)控制器的初始化及驅(qū)動執(zhí)行(以EHCI為例)

module_init(otg_init); 模塊注冊

static init __init otg_init(void);

platform_driver_register(); 平臺注冊

static int __init otg_probe(struct platform_device *pdev); 探測處理函數(shù)

reg = platform_get_resource(pdev, IORESOURCE_MEM, 0); 獲取寄存器信息

data = platform_get_resource(pdev,IORESOURCE_MEM, 1); 獲取內(nèi)存信息

irq = platform_get_irq(pdev,0); 獲取中斷號

usb_create_hcd(&otg_hc_driver, &pdev->dev, pdev->dev.bus_id);

分配和初始化HCD結(jié)構(gòu)體。對設(shè)備數(shù)據(jù)空間進(jìn)行分配,初始化計數(shù)器、總線、定時器、hcd結(jié)構(gòu)體各成員值。

ret = usb_add_hcd(hcd,irq,SA_INTERRUPT);

完成HCD結(jié)構(gòu)體的初始化和注冊。申請buffer,注冊總線、分配設(shè)備端內(nèi)存空間,向中斷向量表中申請中斷,注冊根集線器,對根集線器狀態(tài)進(jìn)行輪詢。

4.1.3 注冊集線器

register_root_hub(hcd);

在USB系統(tǒng)驅(qū)動加載的過程中,創(chuàng)建了集線器的線程(khubd),并且一直查詢相應(yīng)的線程事務(wù)。HCD驅(qū)動中,將集線器作為一個設(shè)備添加到主機(jī)控制器驅(qū)動中,然后進(jìn)行集線器端口的初始化。在USB主機(jī)看來,根集線器本身也是USB主機(jī)的設(shè)備。USB主機(jī)驅(qū)動加載完成之后,即開始注冊根集線器,并且作為一個設(shè)備加載到主機(jī)驅(qū)動之中。

USB主機(jī)和USB設(shè)備之間進(jìn)行數(shù)據(jù)交互,USB設(shè)備本身并沒有總線控制權(quán),U盤被動地接收USB主機(jī)發(fā)送過來的信息并做出響應(yīng)。USB主機(jī)控制器與根集線器構(gòu)成了主機(jī)系統(tǒng),然后外接其它的USB設(shè)備。

為了更好地探測到根集線器的狀態(tài)變化,USB主機(jī)控制器驅(qū)動增加了狀態(tài)輪詢函數(shù),以一定的時間間隔輪詢根集線器狀態(tài)是否發(fā)生變化。一旦根集線器狀態(tài)發(fā)生變化,主機(jī)控制器就會產(chǎn)生相應(yīng)的響應(yīng)。

USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸以URB(USB Request Block)的形式進(jìn)行。

4.2 URB傳輸過程

USB初始化過程中,無論是主機(jī)控制器驅(qū)動還是根集線器驅(qū)動,都是通過URB傳輸獲取設(shè)備信息。

4.2.1 申請URB

struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)

為urb分配內(nèi)存并執(zhí)行初始化。

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)

不同的傳輸模式下,驅(qū)動為之申請不同的URB。其中,Linux內(nèi)核只支持同步傳輸外的三種傳輸事件,ISO事務(wù)需要手工進(jìn)行初始化工作??刂苽鬏斒聞?wù)、批量傳輸事務(wù)、中斷傳輸事務(wù)API如上所示。

三種事務(wù)傳輸模式下的URB初始化函數(shù)有很多相似之處,主要參數(shù)含義如下:

? urb: 事務(wù)傳輸中的urb

? dev: 事務(wù)傳輸?shù)哪康脑O(shè)備

? pipe: USB主機(jī)與USB設(shè)備之間數(shù)據(jù)傳輸?shù)耐ǖ?

? transfer_buffer: 發(fā)送數(shù)據(jù)所申請的內(nèi)存緩沖區(qū)首地址

? length: 發(fā)送數(shù)據(jù)緩沖區(qū)的長度

? context: complete函數(shù)的上下文

? complete_fn: 調(diào)用完成函數(shù)

? usb_fill_control_urb()的setup_packet: 即將被發(fā)送的設(shè)備數(shù)據(jù)包

? usb_fill_int_urb()的interval: 中斷傳輸中兩個URB調(diào)度的時間間隔

4.2.3 提交URB

URB初始化完成之后,USBD開始通過usb_start_wait_urb()提交urb請求(它調(diào)用usb_submit_urb來真正的發(fā)送URB請求),添加completition函數(shù)。

接下來,從message.c傳到主機(jī)控制器(hcd.c),開始真正的usb_hcd_submit_urb()。此時,根據(jù)是否為根集線器,進(jìn)入不同的工作隊列。

usb_start_wait_urb->

usb_submit_urb->

usb_hcd_submit_urb

a) root_hub傳輸

若為root hub,將調(diào)用rh_urb_enqueue(),共有兩種傳輸事務(wù)(控制傳輸和中斷傳輸)

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傳輸,它調(diào)用:

status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);

c) 批量傳輸

root_hub本身沒有批量傳輸流程,按照控制傳輸流程,控制傳輸最終要通過switch語句跳轉(zhuǎn)到Bulk-Only傳輸流程中。

1. USB協(xié)議

1.1 USB主機(jī)系統(tǒng)

在USB主機(jī)系統(tǒng)中,通過根集線器與外部USB從機(jī)設(shè)備相連的處理芯片,稱為USB主機(jī)控制器。USB主機(jī)控制器包含硬件、軟件和固件一部分。

1.2 USB設(shè)備系統(tǒng)

USB設(shè)備按功能分為兩部分:集線器(Hub)和功能部件。從下圖可知,主機(jī)通過根集線器連接到各種外圍設(shè)備(集線器和功能部件)。

1.3 主機(jī)和設(shè)備之間通信模型

主機(jī)與設(shè)備之間的通信模型

上圖展示了USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸過程。在設(shè)備端,USB設(shè)備將非USB格式的數(shù)據(jù)進(jìn)行打包處理,轉(zhuǎn)換成USB格式的數(shù)據(jù)包,然后傳遞到鏈路層,經(jīng)過硬件處理、傳遞到物理層,由物理層通過PHY以數(shù)據(jù)流的形式傳輸?shù)街鳈C(jī)。

USB主機(jī)在USB設(shè)備和USB主機(jī)之間發(fā)起的傳輸過程,穩(wěn)為事務(wù)。每次事務(wù)以2到3個數(shù)據(jù)包的形式進(jìn)行USB總線傳輸。每個數(shù)據(jù)包包含2到3個步驟:

1) USB主機(jī)控制器向USB設(shè)備發(fā)出命令

2) USB控制器和USB設(shè)備之間傳遞讀寫請求,其方向取決于第一部分的命令是讀還是寫

3) 握手信號。

USB主機(jī)控制器向USB設(shè)備發(fā)送事務(wù)類型請求,通過分組標(biāo)識符來進(jìn)行識別。

1.4 USB分組標(biāo)識

主機(jī)和設(shè)備之間進(jìn)行操作,通過分組標(biāo)識(PID)來進(jìn)行傳輸。數(shù)據(jù)包傳輸格式一般由:PID、數(shù)據(jù)/控制信息、CRC校驗碼組成。

常見的PID主要包括令牌、數(shù)據(jù)、握手等類型組成。PID碼以特定的方式組成,如下表所示:

PID分組碼是數(shù)據(jù)傳輸流程中的重要元素。無論硬件還是軟件,都要對PID分組碼進(jìn)行分析,從而做出正確響應(yīng)。USB主機(jī)和設(shè)備嚴(yán)格按照PID分組碼信息進(jìn)行信息交互。

1.5 數(shù)據(jù)包傳輸模式

當(dāng)USB設(shè)備連接到集線器,集線器狀態(tài)將發(fā)生相應(yīng)的變化,并將狀態(tài)變化信息傳遞給USB主機(jī)。USB主機(jī)通過根集線器向USB設(shè)備發(fā)送命令,獲取USB設(shè)備的各種信息,包含USB設(shè)備傳輸類型、ID號、Product、USB速度等信息。

USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸共有四種類型:控制傳輸、批量傳輸、中斷傳輸和同頻傳輸。與之對應(yīng),USB主機(jī)和USB設(shè)備之間有四種事務(wù):控制事務(wù)、批量事務(wù)、中斷事務(wù)和同步事務(wù)。

1.5.1 批量(Bulk)傳輸

作用:主要用于非實時性傳輸,數(shù)據(jù)包較大而延時要求較低。

特點:數(shù)據(jù)傳輸準(zhǔn)備即可,采用批量傳輸模式的USB從機(jī)設(shè)備,如U盤

數(shù)據(jù)傳輸分三個階段:

a) 令牌階段:主機(jī)發(fā)送請求,USB設(shè)備依據(jù)請求PID來判斷IN或OUT傳輸

b) 數(shù)據(jù)傳輸階段:依據(jù)令牌階段的IN或OUT傳輸,來決定數(shù)據(jù)傳輸為DATA0或DATA1來進(jìn)行數(shù)據(jù)傳輸

c) 握手階段:接收信息的一方發(fā)送ACK信號以表示接收成功;若為NAK,表示發(fā)送失敗;STALL表示不可預(yù)知的錯誤

1.5.2 控制(Control)傳輸

作用:USB傳輸過程必須支持的傳輸模式。USB主機(jī)為了獲取設(shè)備描述符、ID、Product等信息,向USB設(shè)備發(fā)送相應(yīng)的PID命令。

特點:唯一可以進(jìn)行IN/OUT傳輸?shù)膫鬏斈J健?

數(shù)據(jù)寬度:控制傳輸方式可以以8、16、32或64字節(jié)的數(shù)據(jù)進(jìn)行傳輸,這取決于設(shè)備的傳輸速度。

USB主機(jī)和設(shè)備之間必須支持控制傳輸,通過端點0進(jìn)行數(shù)據(jù)傳輸。控制傳輸分為令牌、數(shù)據(jù)傳輸和握手階段。

1.5.3 中斷傳輸事務(wù)

作用:按照一定時刻輪詢設(shè)備是否有中斷傳輸請求

特點:查詢頻率取決于端點的模式結(jié)構(gòu),從1到255ms不等

中斷傳輸主要用于實時性要求非常高的從機(jī)設(shè)備,如鍵盤操縱桿和Mouse等

傳輸過程也分為令牌階段、數(shù)據(jù)傳輸和握手階段

1.6 USB描述符

USB協(xié)議中共定義了以下四種描述符:

1) 設(shè)備描述符

2) 配置描述符

3) 接口描述符

4) 端點描述符

其關(guān)系如下圖所示:

1.6.1 設(shè)備描述符

每個USB設(shè)備都有一個唯一的設(shè)備描述符,如下表所示:

1.6.2 配置描述符

每個USB設(shè)備都有默認(rèn)的配置描述符,支持至少一個接口,每個配置描述符如下表:

1.6.3 接口描述符

設(shè)備應(yīng)至少支持一個接口,如:塊傳輸數(shù)據(jù)接口,部分設(shè)備可能支持其它的接口。復(fù)合設(shè)備可以支持額外接口,以支持音頻和視頻功能。標(biāo)準(zhǔn)中并沒有定義此類接口。接口可能有多個可選設(shè)置,主機(jī)將會檢查每個可選的設(shè)置。

1.6.4 端點描述符

每個設(shè)備至少支持控制端點0。USB設(shè)備應(yīng)該支持三類端點:控制端點、輸入端點和輸出端點。

2. OTG協(xié)議

OTG設(shè)備采用Mini-AB插座,相對于傳統(tǒng)的USB數(shù)據(jù)線,Mini-AB接口多了一根數(shù)據(jù)線ID,ID線是否接入將Mini-AB接口分為Mini-A和Mini-B接口兩種類型。在OTG設(shè)備之間數(shù)據(jù)連接的過程中,通過OTG數(shù)據(jù)線Mini-A和Mini-B接口來確定OTG設(shè)備的主從:接入Mini-A接口的設(shè)備默認(rèn)為A設(shè)備(主機(jī)設(shè)備);接入Mini-B接口的設(shè)備,默認(rèn)為B設(shè)備(從設(shè)備)。

A設(shè)備和B設(shè)備無需交換電纜接口,即可通過主機(jī)交換協(xié)議(HNP)實現(xiàn)A、B設(shè)備之間的角色互換。同時,為了節(jié)省電源,OTG允許總線空閑時A設(shè)備判斷電源。此時,若B設(shè)備希望使用總線,可以通過會話請求協(xié)議(SRP)請求A設(shè)備提供電源。

2.1 HNP(主機(jī)交換)協(xié)議

當(dāng)Mini-A接口接入A設(shè)備并確定A設(shè)備為主機(jī)時;若B設(shè)備希望成為主機(jī),則A設(shè)備向B設(shè)備發(fā)送SetFeature命令,允許B設(shè)備進(jìn)行主機(jī)交換。B設(shè)備檢測到總線掛起5ms后,即掛起D+并啟動HNP,使總線處于SE0狀態(tài)。此時A設(shè)備檢測到總線處于SE0狀態(tài),即認(rèn)為B設(shè)備發(fā)起主機(jī)交換,A設(shè)備進(jìn)行響應(yīng)。待B設(shè)備發(fā)現(xiàn)D+線為高電平而D-線為低電平(J狀態(tài)),表示A設(shè)備識別了B設(shè)備的HNP請求。B設(shè)備開始總線復(fù)位并具有總線控制權(quán),主機(jī)交換協(xié)議完成。

2.2 SRP(會話請求)協(xié)議

對于主機(jī),要求能響應(yīng)會話請求;對于設(shè)備,僅要求能夠發(fā)起SRP協(xié)議。OTG設(shè)備,不僅要求發(fā)起SRP,而且還能響應(yīng)SRP請求。

SRP分為數(shù)據(jù)線脈沖調(diào)制和電壓脈沖調(diào)兩種方式,B設(shè)備發(fā)起SRP必須滿足以下兩個條件:

1) B設(shè)備檢測到A設(shè)備低于其有效的電壓閾值,同時B設(shè)備低于有效的電壓閾值。

2) B設(shè)備必須檢測到D+和D-數(shù)據(jù)線至少在2ms的時間內(nèi)低于有效閾值,即處于SE0狀態(tài)。

數(shù)據(jù)線脈沖調(diào)制會話請求:B設(shè)備必須等到滿足以上兩個條件后,將數(shù)據(jù)線接入上拉電阻一定的時間,以備A設(shè)備過濾數(shù)據(jù)線上的瞬間電壓。與此同時,B設(shè)備上拉D+以便于在全速模式下進(jìn)行初始化操作。A設(shè)備在檢測到D+變?yōu)楦唠娖交駾-變?yōu)榈碗娖綍r產(chǎn)生SRP指示信號。

Vbus脈沖調(diào)制會話請求:B設(shè)備同樣需等待滿足上述兩個初始化條件,然后B設(shè)備通過對電容充電以提高總線電壓,待達(dá)到總線上的電壓閾值,喚醒A設(shè)備。在充電過程中,一定要保證充電的電壓峰值在一定的范圍以避免燒壞A設(shè)備。

3. USB驅(qū)動架構(gòu)

USB驅(qū)動架構(gòu)如下圖所示:

3.1 USB主機(jī)端驅(qū)動

USB核心(USBD)是整個USB驅(qū)動的核心部分,從上圖可知,一方面USBD對接收到USB主機(jī)控制器的數(shù)據(jù)進(jìn)行處理,并傳遞給上層的設(shè)備端驅(qū)動軟件;同時也接收來自上層的非USB格式數(shù)據(jù)流,進(jìn)行相應(yīng)的數(shù)據(jù)處理后傳遞給USB主機(jī)控制器驅(qū)動。

USB數(shù)據(jù)傳輸都以URB(USB Request Block)請求、URB生成、URB遞交、URB釋放為主線。從上圖可知,當(dāng)加載控制器驅(qū)動之后,注冊根據(jù)集線器,hub和hcd驅(qū)動成為一個整體。接著,主機(jī)通過控制傳輸獲取設(shè)備的控制描述符等信息,接著詳述整個控制傳輸?shù)牧鞒?。usb_submit_urb依據(jù)是否連接到根集線器來決定調(diào)用urb_enqueue或rh_urb_enqueue函數(shù)。

USB從設(shè)備通過集線器或根集線器連接到USB主機(jī)上。比如:主機(jī)通過根集線器與外界進(jìn)行數(shù)據(jù)交互,根集線器通過探測數(shù)據(jù)線狀態(tài)的變化來通知USB主機(jī)是否有USB外圍設(shè)備接入。

在主機(jī)端控制器驅(qū)動加載的過程中,注冊了根集線器,然后匹配了相應(yīng)的hub驅(qū)動程序,同時完成了對Hub的輪詢函數(shù)和狀態(tài)處理函數(shù)的設(shè)置。這樣,一旦hub集線器的狀態(tài)發(fā)生變化,就會產(chǎn)生相應(yīng)的中斷,主機(jī)端控制器就會執(zhí)行相應(yīng)的中斷處理函數(shù),下圖為hub驅(qū)動程序的流程圖。

USB Core中的usb_init()函數(shù)中完成了對hub線程(khubd,在usb_hub_init函數(shù)中真正地創(chuàng)建)的創(chuàng)建,然后完成相應(yīng)設(shè)備的探測。主機(jī)端控制器驅(qū)動進(jìn)行探測時,將hub驅(qū)動和主機(jī)端控制器驅(qū)動結(jié)合在一起,相互之間完成調(diào)用。 相對于大容量存儲設(shè)備與主機(jī)之間通過控制/批量傳輸,集線器與主機(jī)之間通過中斷/控制方式完成數(shù)據(jù)交互。

3.2 USB設(shè)備端驅(qū)動

從上圖可知,設(shè)備端驅(qū)動包含兩部分:

1) 底層設(shè)備控制器驅(qū)動

2) 上層大容量存儲類驅(qū)動

3.2.1 設(shè)備控制器驅(qū)動

USB設(shè)備控制器驅(qū)動主要實現(xiàn)Gadget API定義的函數(shù)和中斷服務(wù)函數(shù),可按功能劃分為:API函數(shù)實現(xiàn)模塊和中斷處理模塊。

API函數(shù)主要實現(xiàn)Gadget API定義的函數(shù)功能,如結(jié)構(gòu)體usb_ep_ops和usb_gadget_ops中的函數(shù)、usb_gadget_register_driver函數(shù)。這些函數(shù)是供Gadget Driver調(diào)用。

中斷處理模塊主要處理設(shè)備控制器產(chǎn)生的各種中斷,包括端點中斷、復(fù)位、掛起等中斷。

上圖為設(shè)備端控制器基本架構(gòu),主要完成了Gadget驅(qū)動和控制器驅(qū)動綁定、usb_gadget_register_driver注冊。

3.3 OTG驅(qū)動

OS_FS: 文件系統(tǒng)

USBD: USB核心

HCD: 主機(jī)控制器驅(qū)動

UDC: 設(shè)備端控制器驅(qū)動

OTG設(shè)備支持HNP和SRP協(xié)議。OTG設(shè)備通過USB OTG電纜連接到一起,其中接Mini-A接口的設(shè)備為A設(shè)備,默認(rèn)為主機(jī)端,Mini-B接口的設(shè)備默認(rèn)為B設(shè)備。當(dāng)A、B設(shè)備完成數(shù)據(jù)交互之后,A、B設(shè)備之間的USB OTG電纜進(jìn)入掛起狀態(tài),如下圖所示:

當(dāng)B設(shè)備寫入b_bus_req,向A設(shè)備發(fā)起HNP請求。待A設(shè)備響應(yīng)之后,A設(shè)備發(fā)送a_set_b_hnp_en,B設(shè)備響應(yīng)之后即進(jìn)入主機(jī)狀態(tài),同時發(fā)送請求使用A設(shè)備set_device,這樣A、B設(shè)備完成主從交換。

4. USB 傳輸流程

4.1 USB初始化過程

USB驅(qū)動作為一個系統(tǒng),集成了眾多的驅(qū)動模塊,注冊過程非常復(fù)雜。從USB系統(tǒng)的角度來說,USB主機(jī)驅(qū)動主要包含:

1) USB核驅(qū)動

2) 主機(jī)控制器驅(qū)動

3) 集線器驅(qū)動

驅(qū)動的加載執(zhí)行流程如下圖所示:

USB初始化過程

4.1.1 USB Core的初始化

USB驅(qū)動從USB子系統(tǒng)的初始化開始,USB子系統(tǒng)的初始化在文件driver/usb/core/usb.c

subsys_initcall(usb_init);

module_exit(usb_exit);

subsys_initcall()是一個宏,可以理解為module_init()。由于此部分代碼非常重要,開發(fā)者把它看作一個子系統(tǒng),而不僅僅是一個模塊。USB Core這個模塊代表的不是某一個設(shè)備,而是所有USB設(shè)備賴以生存的模塊。在Linux中,像這樣一個類別的設(shè)備驅(qū)動被歸結(jié)為一個子系統(tǒng)。subsys_initcall(usb_init)告訴我們,usb_init才是真正的初始化函數(shù),而usb_exit將是整個USB子系統(tǒng)結(jié)束時的清理函數(shù)。

4.1.2 主機(jī)控制器的初始化及驅(qū)動執(zhí)行(以EHCI為例)

module_init(otg_init); 模塊注冊

static init __init otg_init(void);

platform_driver_register(); 平臺注冊

static int __init otg_probe(struct platform_device *pdev); 探測處理函數(shù)

reg = platform_get_resource(pdev, IORESOURCE_MEM, 0); 獲取寄存器信息

data = platform_get_resource(pdev,IORESOURCE_MEM, 1); 獲取內(nèi)存信息

irq = platform_get_irq(pdev,0); 獲取中斷號

usb_create_hcd(&otg_hc_driver, &pdev->dev, pdev->dev.bus_id);

分配和初始化HCD結(jié)構(gòu)體。對設(shè)備數(shù)據(jù)空間進(jìn)行分配,初始化計數(shù)器、總線、定時器、hcd結(jié)構(gòu)體各成員值。

ret = usb_add_hcd(hcd,irq,SA_INTERRUPT);

完成HCD結(jié)構(gòu)體的初始化和注冊。申請buffer,注冊總線、分配設(shè)備端內(nèi)存空間,向中斷向量表中申請中斷,注冊根集線器,對根集線器狀態(tài)進(jìn)行輪詢。

4.1.3 注冊集線器

register_root_hub(hcd);

在USB系統(tǒng)驅(qū)動加載的過程中,創(chuàng)建了集線器的線程(khubd),并且一直查詢相應(yīng)的線程事務(wù)。HCD驅(qū)動中,將集線器作為一個設(shè)備添加到主機(jī)控制器驅(qū)動中,然后進(jìn)行集線器端口的初始化。在USB主機(jī)看來,根集線器本身也是USB主機(jī)的設(shè)備。USB主機(jī)驅(qū)動加載完成之后,即開始注冊根集線器,并且作為一個設(shè)備加載到主機(jī)驅(qū)動之中。

USB主機(jī)和USB設(shè)備之間進(jìn)行數(shù)據(jù)交互,USB設(shè)備本身并沒有總線控制權(quán),U盤被動地接收USB主機(jī)發(fā)送過來的信息并做出響應(yīng)。USB主機(jī)控制器與根集線器構(gòu)成了主機(jī)系統(tǒng),然后外接其它的USB設(shè)備。

為了更好地探測到根集線器的狀態(tài)變化,USB主機(jī)控制器驅(qū)動增加了狀態(tài)輪詢函數(shù),以一定的時間間隔輪詢根集線器狀態(tài)是否發(fā)生變化。一旦根集線器狀態(tài)發(fā)生變化,主機(jī)控制器就會產(chǎn)生相應(yīng)的響應(yīng)。

USB主機(jī)和USB設(shè)備之間的數(shù)據(jù)傳輸以URB(USB Request Block)的形式進(jìn)行。

4.2 URB傳輸過程

USB初始化過程中,無論是主機(jī)控制器驅(qū)動還是根集線器驅(qū)動,都是通過URB傳輸獲取設(shè)備信息。

4.2.1 申請URB

struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)

為urb分配內(nèi)存并執(zhí)行初始化。

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)

不同的傳輸模式下,驅(qū)動為之申請不同的URB。其中,Linux內(nèi)核只支持同步傳輸外的三種傳輸事件,ISO事務(wù)需要手工進(jìn)行初始化工作??刂苽鬏斒聞?wù)、批量傳輸事務(wù)、中斷傳輸事務(wù)API如上所示。

三種事務(wù)傳輸模式下的URB初始化函數(shù)有很多相似之處,主要參數(shù)含義如下:

? urb: 事務(wù)傳輸中的urb

? dev: 事務(wù)傳輸?shù)哪康脑O(shè)備

? pipe: USB主機(jī)與USB設(shè)備之間數(shù)據(jù)傳輸?shù)耐ǖ?

? transfer_buffer: 發(fā)送數(shù)據(jù)所申請的內(nèi)存緩沖區(qū)首地址

? length: 發(fā)送數(shù)據(jù)緩沖區(qū)的長度

? context: complete函數(shù)的上下文

? complete_fn: 調(diào)用完成函數(shù)

? usb_fill_control_urb()的setup_packet: 即將被發(fā)送的設(shè)備數(shù)據(jù)包

? usb_fill_int_urb()的interval: 中斷傳輸中兩個URB調(diào)度的時間間隔

4.2.3 提交URB

URB初始化完成之后,USBD開始通過usb_start_wait_urb()提交urb請求(它調(diào)用usb_submit_urb來真正的發(fā)送URB請求),添加completition函數(shù)。

接下來,從message.c傳到主機(jī)控制器(hcd.c),開始真正的usb_hcd_submit_urb()。此時,根據(jù)是否為根集線器,進(jìn)入不同的工作隊列。

usb_start_wait_urb->

usb_submit_urb->

usb_hcd_submit_urb

a) root_hub傳輸

若為root hub,將調(diào)用rh_urb_enqueue(),共有兩種傳輸事務(wù)(控制傳輸和中斷傳輸)

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傳輸,它調(diào)用:

status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);

c) 批量傳輸

root_hub本身沒有批量傳輸流程,按照控制傳輸流程,控制傳輸最終要通過switch語句跳轉(zhuǎn)到Bulk-Only傳輸流程中。

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉