该文档描述了UFS Host Controller的主要运作流程以及在开源内核代码hisi平台中的host controller的接口函数设计
文档大部分内容参考来自JEDEC STANDARD JESD223C 标准配置文档以及 hisi平台内核ufs源代码。

UFS架构图

    UFS协议为UFS定义了一个通用的host controller interface(HCI)，主机的驱动程序通过与HCI工作，达到与UFS设备进行交互的目的。该标准定义列寄存器级的HCI设计，负责主机Software和UFS设备间的接口管理和数据传输，其架构如下图所示：

    蓝色箭头上方为主机软件部分，下方为硬件部分（即host controller以及UFS设备），该文档中分析的ufshcd代码主要是为了实现UFS host controller Interface的功能。

HCI接口架构

    主机的Software通过内存中的一系列host register和一些称为Transfer Request Descriptors 的数据结构来与 Host controller 硬件进行交互。UFSHCI定义了两种接口。MIMO Space以及Host Memory Space，下图展示了UFS HCI的框图。

• MMIO Space：在这个空间，hardware register 被定义为 host software 的接口，通过 MMIO 的方式被实现，主要包含了下面三种类型的寄存器：
  • Host Controller Capability Registers，这些寄存器提供了关于Host Controller功能的描述。包括 UFS 标准版本、主机控制器支持的命令队列的大小以及主机控制器标识数据。
  • Runtime and Operation Registers。
    • Interrupt configuration：这些寄存器为 host software 提供了使能/中止以及中断状态的接口。
    • Host controller status. 该寄存器显示 host controller 的状态，并允许主机 software 初始化/禁用 host controller。
    • UTP transfer Request List management. 这些寄存器给 UTP Transfer Request List 提供了接口。
    • UTP Task Management request lists management. 这些寄存器为 UTP Task Management request list 提供了一个接口。
    • UIC Command Registers。这些寄存器为 Unipro 配置以及控制提供了接口。
  • Vendor Specific Registers. 由供应商进行定义。
• Host Memory Space：该空间中包含了能够描述将执行命令和命令中数据缓存的数据结构。简单地可以理解为：UTP Transfer Request List 管理通用的 IO 命令，而 UTP Task Mangement Request List 对应管理命令。

传输请求接口（Transfer Request Interface）

    一个 UFS 的 host system 由一些硬件和软件层组成（host controller 和 host software）。下图展示了其层次结构。

    前面定义的数据结构和寄存器就是为了实现上图中的这 4 个 service access points(SAPs) 而定义。分别为 UIO_SAP, UDM_SAP, UTP_CMD, UTP_TM_SAP。为了管理 host software 和 UFS 设备间的通信，host controller 为主机 software 发送出传输请求提供了如下 3 个独立的接口。

• UTP Tranfer Request List：主机软件使用此列表来实现 UTP_CMD_SAP 和 UDM_SAP。
  • UTP_CMD_SAP 包括对以下命令类型的支持： UFS 采用的所有 INCITS T10 草案标准功能。本机 UFS 命令集。
  • UDM_SAP 包括对以下命令类型的支持： 通过 QUERY REQUEST UPIU/QUERY RESPONSE UPIU 和 NOP IN/NOP OUT UPIU 的设备管理功能。
    - 该列表由系列称为 UFS 传输请求描述符 (UTRD) 的数据结构组成，最多32个。 UTRD 描述了要执行的命令以及相关的数据。 UFS 主机软件通过将UTRD插入到这个列表向主机控制器发出命令，然后为列表响铃主机控制器门铃。命令由 UFSHCI 按照它们在列表中的顺序分派执行，即使它们可能不按顺序完成。主机控制器代表主机处理器管理与命令相关的所有数据传输操作。对于正在更新的列表中的命令，所有命令都可能导致命令完成中断或 UTRD 的状态字段。 UFS SW 可能会在运行时向列表添加命令。主机控制器支持中断聚合，从而为预定义数量的命令完成生成单个命令完成中断。
• UTP Task Management Request List： 主机软件使用此列表来实现 UTP_TM_SAP，该列表包名为 UFS Task Management Request Descriptor（UTMRD）的数据结构组成，最多8个。UTMRD 详细描述了 host software 希望设备执行的任务管理函数。所有的 Task Management Request 将优先于上面 UTP Transfer Request 的执行，UFS 主机软件通过在列表上放置一个 UTMRD 向主机控制器发出任务管理功能，然后为列表响铃主机控制器门铃。 UFSHCI 会按照它们在列表中的顺序分派函数执行，即使它们可能会不按顺序完成。所有任务管理功能都可能导致更新列表中功能的请求完成中断或 UTMRD 状态字段。 UFS SW 可以在运行时向列表中添加任务管理功能。此列表不支持中断聚合。
• UIC Command Register. 这个寄存器集是被主机 software 直接用来执行一个 UIC 命令

UFS 主机控制器寄存器接口（host controller Interface）

    主机控制器寄存器是内存映射的，存在于 MMIO 空间中。寄存器访问的最大大小为 64 位； 且以8字节对齐。UFSHCI 寄存器用于控制主机控制器的操作以及从主机控制器读取状态和中断信息。以下是UFSHCI的标准寄存器映射。

UTP 层数据传输

    host driver与utp层是直接通信的，而二者的数据交互被分成一系列的消息，这些消息根据标准组织为UTP Protocol Information Units(UPIU)的格式，UFS协议文档中的表10-2描述了不同种类的UPIU信息，比如 NOP Out, Command, Response，Data Out 等类型。UPIU 的内容是存放在名为 UTP Command Descriptor（UCD）的数据结构中，而前面所介绍的 UTRD（UTP Transfer Request descriptor）中存放有指向 UCD 的指针。
    数据在 host memory, host controller, device 三者之间都可以理解为以 UPIU 的形式来进行传递。下图给出了一个从 host 端到 device 端传输 577 byte 数据的例子：

    可以假设这是一个写 577 byte 到设备上的命令。由 Command UPIU 开始，告知所需要写的数据信息，收到 RTT UPIU（ready to transfer），表示 device 可以接受数据传输，通过 DATA OUT UPIU 进行数据的传输。可以看到途中 Data OUT UPIU 的顺序可以改变的。最终收到 Response UPIU 表示这一次写命令的结束。其他命令的执行过程类似。

Host Software与Host Controller的交互

    根据标准中的描述，Software 对于 UFS HCI 的操作分为三大部分：Host controller配置和控制，数据传输操作，任务任务管理。

Host Controller初始化

    当主机控制器出现上电复位时，所有 MMIO 寄存器都将处于其上电默认状态，并且链路将处于非活动状态（inactive）。 以下是主机软件将执行的操作序列以初始化 host controller：

• 启动 host controller 的第一步是正确编程系统总线接口。 这一步与控制器实现所使用的系统总线有关，因此应遵循特定系统总线的文档。该步完成时，控制器应准备好在系统总线上传输数据。
• 为了启用主机控制器，将 1 写入 HCE(host controller enable) 寄存器。 这触发了本地 UIC 层的自主基本初始化(autonomous basic initialization)。 初始化序列应由 DME_RESET 和 DME_ENABLE 命令组成。 可以根据实现需要添加其他命令，如 DME_SET 命令。 在基本初始化序列期间，HCE 的值一直为 0。
• 等待 HCE 读为 1 的时候继续。 表示基本的初始化序列已经完成。
• 附加命令（如 DME_SET 命令）可以从系统主机发送到 UFS 主机控制器，以提供配置灵活性。
• 可选地将 IE.UCCE(UIC command completion enable)设置为 1，以便使能 IS.UCCS(UIC Command Completion Status)中断。
• 发送 DME_LINKSTARTUP 命令以开始链路启动过程 (link startup procedure)
• 完成 DME_LINKSTARTUP 命令设置 IS.UCCS 位.如果设置了 IE.UCCE，则可以向系统主机标记中断, 该中断将独立于 GenericErrorCode 进行标记。
• 如果完成的 DME_LINKSTARTUP 命令的 GenericErrorCode 为 SUCCESS，那么除了 IS.UCCS 位之外，还将设置 HCS.DP(device present)
• 检查 HCS.DP 的值，并确保连接有一个设备。 如果检测到设备的存在，转到步骤 10;否则，在 IS.ULSS 设置为 1 后重新发送 DME_LINKSTARTUP 命令（转到步骤 6）。 IS.ULSS 等于 1 表示 UFS 设备已准备好进行链接启动。
• 通过编程 IE 寄存器来启用附加中断。
• 以阈值（IACTH）和超时（IATOVAL）的所需要的值来初始化中断聚合控制寄存器（UTRIACR）。注意当运行/停止寄存器（UTRLRSR）未被使能或没有请求未完成时，也可以随时执行UTRIACR初始化。
• 如果需要，通过 UIC 命令界面 (interface) 完成主机控制器配置。
• 分配和初始化 UTP 任务管理请求列表。(Allocate and initalize UTP Task Management Request List)
• 编程 UTP Task Management Request List 的起始地址，并且用一个 64 位地址指针指向它。
• 分配和初始化 UTP 传输请求列表（UTP Transfer Request List）
• 编程 UTP Transfer Request List 的起始地址，并且用一个 64 位地址指针指向它。
• 通过将 UTP 任务管理请求列表 Run-Stop Register（UTMRLRSR）设置为 1，启用 UTP Task-Mangement Request List。 该操作允许 host controller 通过 UTP Task Management Request Door Bell 机制开始接受 UTP 任务管理请求。
• 通过将 UTP 传输请求列表 Run-Stop Register（UTRLRSR）设置为 ‘1’ 来启用 UTP Transfer Request List。该操作允许主机控制器通过 UTP Transfer Request Door Bell 机制开始接受 UTP 传输请求。
• bMaxNumOfRTT 将被设置为 bDeviceRTTCap 和 NORTT 的最小值。

配置与控制

    一旦主机控制器复位，主机软件就可以使用 UIC 命令寄存器来配置和控制链路以及连接的设备。 主机软件负责配置 UFS 互连堆栈和连接的设备。 在对 UIC 命令寄存器编程时，只有在设置了所有 UIC 命令参数寄存器（UICCMDARG1，UICCMDARG2 和UICCMDARG3）之后，主机软件才能设置寄存器 UICCMD。 检查执行 UIC 命令的状态有两种选择：

• 通过中断机制。在将 UIC 命令发送到主机控制器执行之前，软件通过设置 UIC 命令完成启用寄存器 IE.UCCE 来启用 UIC 命令完成中断。命令执行完成后，主机控制器将产生一个中断，并将寄存器设置为 UIC COMMAND 完成状态寄存器 ‘1’。
• Software pulling。在将 UIC 命令发送到主机控制器执行之后，软件将持续 pulling UIC 命令完成状态，直到它返回 “1”。
  一旦命令完成，软件可以检查返回/状态代码（如果适用于该命令）

CRYPTOCFG 配置过程

    要在 CRYPTOCFG 阵列中配置一个 entry，software 需遵循以下步骤：

• 在 CRYPTOCFG 数组中选择一个条目 x-CRYPTOCFG。
• 如果条目未启用，比如 x-CRYPTOCFG.CFGE == 0，跳到步骤 5。
• 验证没有待处理的事务在其 CCI 字段中引用 x-CRYPTOCFG，即对于所有挂起的事务，UTRD.CCI≠x。验证完毕后，进入步骤 4
• 通过将 0000h 写入 x-CRYPTOCFG 的 DW16 清除 x-CRYPTOCFG.CFGE 位。此操作也会清除 CAPIDX 和 DUSIZE 字段
• 根据以下规则将加密密钥写入 x-CRYPTOCFG.CRYPTOKEY 字段：按照 6.3 节中列出的算法特定布局组织密钥。 没用过 CRYPTOKEY 的区域应该用零写；密钥以小端格式写入：CRYPTOKEY [0] 的字节 0，字节 1 到 CRYPTOKEY [1]，字节 15 到 CRYPTOKEY [15] 等；CRYPTOKEY 的内容应该从 DW0 到 DW15 顺序地在一个原子操作集中写入。
• 选择写入 x-CRYPTOCFG 的 DW17
• 用 CAPIDX，DUSIZE和CFGE = 1 写入 x-CRYPTOCFG 的 DW16
      只有在上述程序完成之后，软件才可以使用新的配置，通过 UTRD.CCI = x 来发起一个 transaction。

数据传输

    Host controller 复位和配置完成后，software 可以使用 UTP Transfer Request List（UTRL）将 UTP 命令传递到连接到链路的 UFS 设备。UTRL 是位于系统内存中的 list buffer，用于将命令从软件传递到设备。software 负责根据 CAP.NUTRS 的值选择 UTRL 大小。通常，软件应该选择 32 entry 选项，除非系统功能规定了较小的内存占用。当主机软件需要向主机控制器发送 UTP 命令时，它使用 UTP 传输请求列表。 以下是主机 software 构建 UTP 传输请求的步骤。

• 通过读取UTRLDBR寄存器找到一个空的传输请求slot，一个空的传输请求slot，其UTRLDBR中的相应位被清除为’0’。
• 主机软件在空slot中构建UTRD。
  • 编程字段CT（Command Type），用于指示命令类型：SCSI，原生UFS命令或设备管理函数。
  • 编程DD字段，其作为命令的一部分包含了数据操作的方向。
  • 如果软件请求将命令标记作为中断命令（IS.UTRCS在命令完成时设置），则I（中断）置1.如果软件请求将该命令标记为常规命令，该位将被清除。
  • 用’Fh’初始化ocs。
  • 分配和初始化UCD（UTP command descriptor）。
  • 用一个UTP command来编程UPIU Command字段，在UCD中，不包括 任务管理功能。
  • 在UCD中用’0’初始化字段response UPIU。
  • 如果需要，填写与数据相关的所有数据缓冲区的指针和PRDT(Physical Region Descriptal Table)的大小。
• 用 UCD(UTP Command Desciptor) 的起始地址编程字段 UCDBA 和 UCDBAU。
• 用在 UCD 中的 Response UPIU 的 offset 来编程 RUO（Response UPIU Offset）字段。
• 用 Response UPIU 的长度来编程 RUL 字段（Response UPIU Length）。
• 如果需要的话，用在 UCD 中的 PRDT 字段的偏移量来编程 PRDTO 字段。
• 如果需要的话，用 PRDT 的长度来编程 PRDTO 字段。对每一个将要被发送到 host controller 的命令，都要重复如上 1-7 的步骤。
• 检查寄存器 UTRLRSR（UTP Transfer Request Run-Stop Register），并确保在继续之前读取的值为“1”。
• 设置 UTP 传输请求中断聚合控制寄存器（UTRIACR）使能位为“1”以使能中断。
• 将计数器和定时器复位（CTR）位设置为’1’以复位与中断相关的计数器和定时器。
• 编程字段中断聚合计数器阈值（IACTH）与产生中断所需的命令完成次数。
• 编程字段中断聚合超时值（IATOVAL）with 允许的响应到达主机控制器之间的最大时间和产生中断。
• 设置 UTRLDBR 寄存器来 ring the doorbell register 告知 host controller 一个或多个 transfer requests 已经准备好发送给对那个的设备。Host software 应该仅仅写‘1’到对应命令的 bit position。其他在 UTRLDBR 中的位应该被写‘0’，表示当前的值没有改变。

UPIU的执行过程

由主机software产生的outbound UPIU

    除了 DATA OUT UPIU 之外，所有其他 UFS 定义的 Outbound UPIU 必须通过Software 生成并存储在 host memory 中。 然后，Host controller 通过 DMA 从 memory 中取出 outbound UPIU，并使用本地 UniPro 堆栈将其分派到 UFS 设备。 UTP 引擎仅对 outbound UPIU 的 LUN 和 task tag字段进行分析，以便能够匹配未来相应的inbound UPIU。 注意，对于QUERY REQUEST和NOP OUT UPIU，LUN字段保留，不会用于匹配(因为不需要)。由Software生成的outbound UPIUs如下：

由Host Controller生成的Outbound UPIU

    只有DATA OUT UPIU由UTP engine自动生成，无需software介入。 Data Out UPIU是为响应来自设备的Ready To Transfer（RTT）UPIU 而创建的，而RTT UPIU又由先前向设备传输command UPIU产生的。 UTP engine使用来自相应的RTT UPIU和与原始命令UPIU相关联的PRD表的信息。表 2 详细说明了特定的 UTP 引擎行为。

由Software解析的Inbound UPIUs

    UTP engine 应分析任务标签，在适用的情况下分析UFS主机接收到的所有UPIU的LUN字段，以便它们可以匹配先前从UFS主机发送到UFS设备的UPIU（请求/响应匹配）。
    具有task tag和LUN字段的UPIUs从UFS设备端传送过来被接收，并且匹配之前由UFS HOST发送的UPIU，它将被传送进入Host memory中相应的Descriptor。只有准备转移（RTT）和数据在UPIU中的处理方式不同，UTP Engine将进一步分析，以实现自主数据传输操作。对于host controller来说，接收到如Response，Task management Response等类型的UPIU是就标志着一个UTP Transaction的关闭。最终，UTRLDBR的相应位会被清除。接收 下表中列出的inbound UPIU将最终结束一个UTP事务，该事务是在发送相应的outbreakound UPIU时启动的

由Host controller/UTP Engine解析的Inbound UPIUs

    Data in 和 Ready to Transfer UPIU完全由Host controller/ UTP引擎处理，并且在处理它们时不涉及software。
    数据在UPIU中携带从UFS设备检索的数据，并对其头信息进行解析，以允许Host controller 将包含的数据传输到host memory中的正确位置。

    RTT(Ready To Transfer) UPIU由主机控制器/ UTP引擎分析，以提取UFS设备提供的有关UTP引擎预期生成的下一个DATA OUT UPIU的必要信息。

UTP Transfer Request completion 的处理

    当在 host controller 中接收到UTP传输请求完成(UTP Transfer Request Completion)时，处理的过程如下：
    如果完成是针对Regular Command（UTRD.I = 0）：

• IA中断计数器递增
• 如果计数器在递增之前为0，则IA定时器开始运行
      当满足以下四个条件中的至少一个时，设置IS.UTRCS(UTP Transfer Request Completion Status)：
• UTRD.I 位被写‘1’（Interrupt Command）
• 计数器在增长之后达到IACTH中的那个值（Interrupt aggregation counter threshold）
• 当IA计时器达到在IATOVAL（Interrupt aggregation timeout value）中配置的值。（这种情况可能随时发生，不一定与请求完成相关）。
• 完成命令的总体命令状态（OCS）不等于“SUCCESS”。

    如果完成中断未被IE.UTRCE位屏蔽（禁用），则由写操作产生中断。
    host software 处理host controller 为command completion 产生的中断。 在中断服务程序中，host software 检查寄存器IS以确定是否有中断挂起。 如果设置了IS.UTRCS位，表示一个或多个UTP Transfer Requests（TR）已完成，应该采用以下步骤：

• 如果IS寄存器中出现错误，则主机软件执行错误恢复操作。
• 在IS.UTRCS中断的情况下，主机软件清除中断，然后可以使用以下两种方法之一来确定哪些UTP TRs已经完成：
  • 读取 UTRLDBR 寄存器，并将当前值与主机软件先前发出的仍未完成的命令列表进行比较，对于outstanding的任何一个TR，UTRLDBR中位置i（其中i表示issue Transfer Request的UTRL slot）中的值0意味着TR已经完成。 UTRLDBR是一个易失性寄存器; software 只能使用其值来确定已经完成的命令，而不能确定先前已经发出的命令。
  • 读取UTRLCNR寄存器。对于每一个TR, 其中bit i的值为1表示这个位置的TR已经完成。
• 对于检测到完成的每个TR i，host software重复以下步骤：
  • 根据较高OS层（例如文件系统）的要求处理来处理 request completion.
  • 通过写’1’来清除UTRLCNR的相应位i。
  • 标记这个slot i表示可以用于重新使用了（仅限软件）
• 在处理所有先前检测到的TR之后，软件可以通过向UTRIACR寄存器写入80010000h来重置和重新启动中断聚合机制
• 通过重复步骤2中描述的两种方法之一，软件确定步骤2之后是否已经完成了新的TR。 如果新的TR已经完成，则software重复步骤3中的序列。

Task Management Function

    UTMRL(Task Management Request List)用于向连接的设备发送UTP任务管理功能。Host controller 应将Task management function放置在比UTP Transfer Request更高的优先级。当提交任务管理请求时，Host controller需要暂停所有active的UTP传输请求，转而分发task management 到相应的设备。上下文切换的粒度应该发生在UPIU边界的转移处。

创建一个 UTP Task Management Request 的基本步骤

    当host software需要向host controller发送 UTP 任务管理功能时，它使用 UTP 任务管理请求列表（UTRML）。以下是主机软件构建 UTP 任务管理请求的步骤。

• 通过读取UTMRLDBR找到一个空的transfer request slot。一个空的slot在UTMRLDBR中的相应位清零。
• Host software 在empty slot出创建一个UTMRD.
• 如果软件请求命令完成后设置IS.UTMRCE，（中断）位置1。
• 用‘Fh’设置OCS（Overall Command Status）
• 编程 Task Management Request UPIU.
• 用‘0’来初始化字段 Task Management Response UPIU.
• 对每一个将要发送给host controller执行的task management function，重复step1 到 step 7
• 检查UTMRLRSR寄存器并且保证在继续之前能够读取到’1’
• 设置UTMRCE(UTP Task Management Request Completion Enable)使能位为‘1’来启动中断。
• 设置UTMRLDBR来提醒doorbell register以向host controller表示多个transfer requests已经准备好被发送给相应的设备了。Host software只能在与新命令对应的bit position写‘1’。其他的UTMRLDBR应该写‘0’，表示对现有的值没有改变。

处理UTP Task Management Completion

    Host software 处理由host controller产生的命令完成的中断。在中断服务程序中，主机软件检查IS以确定是否有中断挂起。 如果UFSHCI有一个待处理的中断：

• 主机软件通过读取IS寄存器来确定中断的原因。 如果设置了IS.UTMRCS位，则表示UTP任务管理请求已完成。
• 主机软件根据中断原因清除IS寄存器中的相应位。
• Host software 读取UTMRLDBR寄存器，并将当前值与主机软件先前发出但仍未完成的命令列表进行比较。主机软件成功完成任何未完成的命令，其相应位已在相应寄存器中被清除。 UTMRLDBR是一个易失性寄存器; 软件只能使用其值来确定已经完成的命令，而不是确定先前已经发出的命令。
• 如果IS寄存器中出现错误，则主机软件执行错误恢复操作。

UIC Power Mode Change

    UIC 电源模式更改是使用 DME_SET 命令来执行的，以设置 UIC 属性。 UIC 电源模式更改是一个原子操作，这意味着这些属性需要按照某些规则进行设置。
    可以根据需要设置以下一个或多个属性：

• PA_ActiveTxDataLanes
• PA_ActiveRxDataLanes
• PA_TxGear
• PA_RxGear
• PA_TxTermination
• PA_RxTermination
• PA_HSSeries
• PA_PWRModeUserData
• DME_ Local_FC0ProtectionTimeOutVal
• DME_ Local_TC0ReplayTimeOutVal
• DME_ Local_ AFC0ReqTimeOutVal
• DME_ Local_FC1ProtectionTimeOutVal
• DME_ Local_TC1ReplayTimeOutVal
• DME_ Local_ AFC1ReqTimeOutVal
• PA_PWRMode

    目前，UFS 仅使用 TC0。因此，不需要设置以下值：

• DME_ Local_FC1ProtectionTimeOutVal
• DME_ Local_TC1ReplayTimeOutVal
• DME_ Local_ AFC1ReqTimeOutVal

    设置 PA_PWRMode 属性会触发 UIC 电源模式更改。因此，PA_PWRMode 应该是最后一个要设置的属性。其他属性可以在 PA_PWRMode 之前按任意顺序设置。
    当 IS.UPMS 设置为“1”时，UIC 电源模式更改操作完成。如果 IE.UPMSE 已设置，UIC 电源模式更改完成也会通过中断发出信号。 UIC 电源模式更改的状态由 HCS.UPMCRS 的值给出。如果 HCS.UPMCRS 设置为 PWR_LOCAL，则 UIC 电源模式更改已成功完成。如果 HCS.UPMCRS 设置为 PWR_ERROR_CAP 或 PWR_FATAL_ERROR，则 UIC 电源模式更改失败。 HCS.UPMCRS 不能设置为 PWR_REMOTE 或 PWR_BUSY，因为它们与来自 UFS 设备的 UIC 电源模式更改请求相关联，这在 JESD220B 协议中是不允许的。
    为了保证UIC电源模式改变操作的原子性，在用DME_SET设置PA_PWRMode属性和主机控制器接口设置IS.UPMS之间，软件不得设置上述属性。否则，由于主机控制器接口不需要阻止这些属性在UIC电源模式改变期间被设置，因此该行为是未定义的。

UFSHCI Internal Rules

命令处理顺序

    UFSHCI 处理三种类型的命令，应使用以下优先级进行处理（按优先级顺序，最高优先级在前）：

• 通过 UIC 命令寄存器发出的UIC 命令。
• 通过 UTP 任务管理请求列表发出的任务管理请求。
• 通过 UTP 传输请求列表发出的传输请求。

    软件应一次发出一个 UIC 命令。对于任务管理请求和传输请求，软件可能一次发出多个命令，并且可能在之前的命令完成之前发出新的命令。当软件设置相应的门铃寄存器时，任务管理请求和传输请求会自动获得带有其发布时间的时间戳。命令列表（任务管理列表或传输请求列表）中的命令应按照它们的时间戳顺序进行处理，从最早的时间戳开始。如果来自同一列表的多个命令具有相同的时间戳，则应按其命令列表索引的顺序从最低索引开始处理它们。由于使用单个 UIC CPort，与任务管理请求和传输请求相关联的 UPIU 被排序。因此，与这些请求关联的 UPIU 一次传输一个。
    除了软件提供的Request UPIUs（NOP Out、Command、Task Management Request和Query Request），UFS HCI还会产生Data Out UPIUs。Data Out UPIU 的顺序以及它们与request UPIU 的交错关系取决于实际情况，因此未指定。

RTT 处理规则

    RTT(Ready to transfer)，主机控制器应按照从设备接收到的顺序处理挂起的 RTT。

加密操作的数据单元处理顺序

    加密引擎的数据单元输入中的字节顺序和 UPIU 数据段的字节顺序应保持如下图所示，用于加密和解密。