UFS中流淌的數(shù)據(jù)包叫做UPIU（UFS Protocol Information Unit，UFS協(xié)議信息單元），它是固定格式的數(shù)據(jù)結(jié)構(gòu)，用以傳輸應(yīng)用層發(fā)來的命令或者請求，以及跟它們相關(guān)的數(shù)據(jù)或者狀態(tài)信息。它就是SATA中的FIS，PCIe中的TLP。我們看看UFS中命令或請求是怎么執(zhí)行的。

UFS采用“客戶-服務(wù)器”或者說主從的命令架構(gòu)，UFS主機(jī)（Client，命令發(fā)起者，Initiator，他們都是一個意思）發(fā)送命令或者請求（Request）給UFS設(shè)備（服務(wù)器，Target），然后UFS設(shè)備執(zhí)行命令并返回命令狀態(tài)（Response）。

一個命令或者請求的執(zhí)行包含下面幾個階段：

命令階段：主機(jī)發(fā)起命令或請求給設(shè)備，這是“因”；

數(shù)據(jù)階段：傳輸跟命令相關(guān)的數(shù)據(jù)，比如讀寫命令，都涉及到數(shù)據(jù)的傳輸；有些命令不涉及數(shù)據(jù)的傳輸，所以這個階段并不是總是存在的，跟具體命令和請求相關(guān)。

狀態(tài)階段：設(shè)備執(zhí)行完命令，必須給主機(jī)返回命令執(zhí)行狀態(tài)信息。這個是“果”，必不可少的。在PCIe中，有Posted和Non-posted的TLP。對前者，命令執(zhí)行者無需返回命令執(zhí)行狀態(tài)給命令發(fā)起者，對后者，命令執(zhí)行者必須返回狀態(tài)給命令發(fā)起者。對UFS來說，它的命令總是non-posted，即設(shè)備必須返回命令狀態(tài)給主機(jī)。

在命令執(zhí)行過程中，無論是處在哪個階段，UFS主機(jī)和設(shè)備間都是通過UPIU進(jìn)行信息的交互。

1. UFS主機(jī)通過命令或者請求UPIU發(fā)命令請求給設(shè)備；

2. UFS主機(jī)或者設(shè)備通過UPIU傳輸數(shù)據(jù)；

3. UFS設(shè)備通過UPIU返回命令狀態(tài)信息給主機(jī)。

下面我們看看UFS當(dāng)中都有哪些UPIU。

命令或者請求UPIU

前一章看到，應(yīng)用層包括UFS命令、設(shè)備管理器和任務(wù)管理器三個模塊，傳輸層根據(jù)不同模塊發(fā)來的命令或者請求，分別產(chǎn)生不同類型的UPIU。

UFS命令模塊發(fā)送簡化版本的SCSI命令，當(dāng)傳輸層收到命令請求后，它會生成：COMMAND UPIU，把命令封裝起來。

應(yīng)用層通過任務(wù)管理器來管理任務(wù)隊列，比如終止（Abort）和查詢命令隊列中的命令。當(dāng)傳輸層收到來自任務(wù)管理器中的請求后，它會生成：TASK MANAGEMENT REQUEST UPIU，把請求封裝起來。

UFS通過設(shè)備管理器來管理UFS設(shè)備，比如設(shè)置和查詢UFS設(shè)備的配置（Configuration）。當(dāng)傳輸層收到來自設(shè)備管理器發(fā)來的請求后，它會生成：QUERY REQUEST UPIU，把請求封裝起來。

數(shù)據(jù)傳輸相關(guān)UPIU

當(dāng)主機(jī)發(fā)送了類似讀命令給設(shè)備之后，設(shè)備需要返回數(shù)據(jù)給主機(jī)，設(shè)備通過DATA IN UPIU向主機(jī)傳輸數(shù)據(jù)。

當(dāng)主機(jī)發(fā)送了類似寫命令給設(shè)備之后，主機(jī)需要往設(shè)備寫數(shù)據(jù)，主機(jī)通過DATA OUT UPIU向設(shè)備傳輸數(shù)據(jù)。

UFS的主機(jī)是個暖男，它在向設(shè)備寫數(shù)據(jù)的時候，會考慮到設(shè)備這個時候能不能接收數(shù)據(jù)（因為設(shè)備可能這個時候沒有足夠的空間接收主機(jī)數(shù)據(jù)），它在向設(shè)備發(fā)了寫命令之后，不會立刻把數(shù)據(jù)傳輸給設(shè)備，而是在那里等設(shè)備的通知。當(dāng)設(shè)備準(zhǔn)備好接收數(shù)據(jù)，以及接收多少數(shù)據(jù)，設(shè)備通過READY TO TRANSFER UPIU （RTT）告知主機(jī)。當(dāng)主機(jī)接收到該RTT后，才開始按照RTT的信息傳輸數(shù)據(jù)。至于每次傳輸數(shù)據(jù)的多少，RTT中包含這信息，主機(jī)根據(jù)RTT進(jìn)行傳輸。

所以，主機(jī)只有在收到設(shè)備的RTT，才能發(fā)DATA OUT UPIU！

注意，讀命令無需這種機(jī)制。因為設(shè)備從閃存中獲得數(shù)據(jù)后，是設(shè)備控制數(shù)據(jù)的傳輸。對主機(jī)來說，它在發(fā)讀命令之前，已經(jīng)準(zhǔn)備好足夠的空間用以接收數(shù)據(jù)，所以不存在主機(jī)沒有空間接收數(shù)據(jù)的情況。

狀態(tài)UPIU

前面看到，主機(jī)有三種請求：SCSI命令，任務(wù)管理器發(fā)出的Task Management Request，以及設(shè)備管理器發(fā)出的Query request。針對不同的命令或者請求，設(shè)備在執(zhí)行完相應(yīng)的任務(wù)后，分別返回對應(yīng)的狀態(tài)UPIU給主機(jī)。

其它UPIU

除了以上常規(guī)的UPIU，還有其它一些UPIU作為他用。

設(shè)備上電后，主機(jī)檢測是否與之連接，會發(fā)NOP OUT UPIU給設(shè)備。我們平時想看看跟某個電腦或者網(wǎng)站能否連接上，會發(fā)一個ping命令。NOP OUT UPIU跟ping命令作用類似。

當(dāng)設(shè)備收到NOP OUT UPIU后，會返回NOP IN UPIU。主機(jī)收到該UPIU后，確認(rèn)與設(shè)備連接，然后可以進(jìn)行后續(xù)操作。

最后一個UPIU就是REJECT UPIU。當(dāng)設(shè)備收到一個無效的UPIU時，它會發(fā)REJECT UPIU拒絕無效的UPIU。

UPIU匯總

偷個懶，我就直接把UFS spec這張表貼這里。數(shù)了數(shù)，一共12個UPIU。經(jīng)過我之前的解釋，讀者現(xiàn)在應(yīng)該清楚每個UPIU的作用了。

讀寫命令中UPIU交互例子

前面我們都是單個來看UPIU，現(xiàn)在我們以讀寫命令為例，看看他們是如何組合完成命令處理的。

首先是一個“主機(jī)往設(shè)備讀取96KB數(shù)據(jù)”的例子。

首先，主機(jī)發(fā)送讀96KB數(shù)據(jù)的命令給設(shè)備，然后設(shè)備執(zhí)行命令，分了三批把數(shù)據(jù)返回給主機(jī)，最后返回命令執(zhí)行狀態(tài)給主機(jī)。

然后是一個“主機(jī)往設(shè)備寫64KB數(shù)據(jù)”的例子。

主機(jī)發(fā)送寫64KB數(shù)據(jù)的命令給設(shè)備，然后在那里等設(shè)備響應(yīng)。很快，設(shè)備說，你可以傳24KB數(shù)據(jù)下來了，于是主機(jī)寫24KB數(shù)據(jù)給設(shè)備；接著，設(shè)備又來通知說可以繼續(xù)傳32KB數(shù)據(jù)，主機(jī)照做。最后，設(shè)備通知說可以把最后8KB數(shù)據(jù)也傳過來，主機(jī)于是寫最后8KB數(shù)據(jù)。最后，主機(jī)收到設(shè)備命令執(zhí)行完成的響應(yīng)。

我們看到，主機(jī)必須等收到RTT后才能啟動數(shù)據(jù)傳輸！