UniPro 的上面就是 UTP 和 SCSI 命令集,由于涉及的 SCSI 命令是很大一块需要单独来讲,所以这里只简单两笔。正如最开始提到的,UTP 和 SCSI 是属于 SCSI 这部分,在 JEDEC 的标准里能找到它们的具体说明。
UTP(UFS Transport Protocol):这层软件主要有两个目的,一是把 UniPro 的 segment 打包成 UFS 直接可以识别的命令格式;二是通过这层可以让 UFS 自己来掌握发送数据的节奏、控制自身的状态等,这样既可以免去 host 端持续的查询 UFS 的状态所带来的系统消耗,也是因为只有 UFS 本身最了解自己的内部状态,能够选择以最佳的方式在最佳时间把数据传递出去。
UFS Application Command Layer:这层是 UFS 命令集,分为 UFS 的独有内建命令集和 SCSI(Small Computer System Interface)的命令集。SCSI 命令分为 SBC 和 SPC,分别是 SCSI Block Commands 和 SCSI Primary Command。
在 SCSI 架构中,主机上的 SCSI 接口卡称为 Initiator,与其相连接的 SCSI 磁盘等设备称为 Target,在逻辑上,Initiator 和 Target 之间通信的工作模式,与两个网络设备之间的模式相似,他们之间采用 client-server 的“请求-回应”模式:
SCSI 的 Initiator 与 Target 共同构成了一个典型的 C/S 模型,每个指令都是“请求/应答”这样的模型来实现:
* Initiator主要任务:发出SCSI请求;
* Target主要任务:回答SCSI请求,通过 LU 提供业务,并通过任务管理器提供任务管理功能;
LU(Logical Unit):逻辑单元,是指一个可被操作系统识别和访问的逻辑存储单元。一个 UFS 设备可以包含多个 LU,每个 LU 可以被视为一个独立的存储设备;
LUs : LU 的复数形式;
LUN(Logical Unit Number):逻辑单元号码,是用来标识不同 LU 的唯一编号。每个 LU 都有一个对应的 LUN,它可以用来在系统中唯一地标识和访问该 LU;
UFS 设备有若干个 LU,LU 接收主机发过来的命令或请求可能来自应用层的 SCSI 模块、设备管理器或者任务管理器:
每个 LU 都是独立的,“独立”表现在下面几个方面:
总结来说,划分不同 LU 有以下作用:
UFS 架构以 HCI(Host Controller Interface,主机控制器接口)为界划分为三部分。如下图,蓝色框上方调用 HCI 的为主机软件部分,蓝色框下方的为 HCI 封装的硬件处理细节部分,即 HC(Host Controller,主机控制器)
数据结构服务于软件,主机的软件通过内存中的一系列主机 register 和数据结构 Transfer Request Descriptors 来与 Host controller 硬件进行交互。UFSHCI 定义了两种接口:IO Memory/Registar Space 以及 Host Memory Space,下图展示了 UFS HCI 的框图:
IO Memory/Registar Space:在这个空间,主机 register 被定义为主机的软件接口,通过 MMIO[4](Memory-Mapped I/O,内存映射 I/O)的方式被实现,主要包含了下面三种类型的寄存器:
Host Controller Capability Registers:这些寄存器提供了关于 HC 功能的描述。包括 UFS 标准版本、主机控制器支持的命令队列的大小以及主机控制器标识数据;
Runtime and Operation Registers:
Vendor Specific Registers:由供应商进行定义;
Host Memory Space:该空间中包含了能够描述将执行命令和命令中数据缓存的数据结构。简单地可以理解为——UTP Transfer Request List 负责通用的 IO 命令,UTP Task Mangement Request List 负责管理命令。
UTP Transfer Request List(传输请求列表)由一系列数据结构 UTRD (UTP Transfer Request Descriptor,传输请求描述符) 组成。UFS host controller 命令队列中的命令槽(slot)被 MMIO 到 UTRD,32 个 UTRD 对应最多 32 个 slot,UTRD 描述了要执行的命令及相关数据。
UFS 主机软件通过将要执行的命令及相关数据放置在 UTRD,再敲响主机控制器门铃(Offset 58h: UTRLDBR – UTP Transfer Request List Door Bell Register )向主机控制器发出命令。传输请求列表中的命令被 UFSHCI 顺序执行,但可能会按照不同的顺序完成。所有命令都可以产生命令完成中断或者更新在列表中的 UTRD 命令状态字段。UFS 主机软件可以在运行时向列表中添加命令。主机控制器支持中断聚合,即在预定义的命令完成设定的数量后生成单个命令完成中断。
UFS Task Management 在代码中的表示如下:
设置ufs电源为active状态
#define ufshcd_set_ufs_dev_active(h) \
((h)->curr_dev_pwr_mode = UFS_ACTIVE_PWR_MODE)
/**
* ufshcd_runtime_resume - runtime resume routine
* @hba: per adapter instance
*
* This function basically brings the UFS device, UniPro link and controller
* to active state. Following operations are done in this function:
*
* 1. Turn on all the controller related clocks
* 2. Bring the UniPro link out of Hibernate state
* 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
* to active state.
* 4. If auto-bkops is enabled on the device, disable it.
*
* So following would be the possible power state after this function return
* successfully:
* S1: UFS device in Active state with VCC rail ON
* UniPro link in Active state
* All the UFS/UniPro controller clocks are ON
*
* Returns 0 for success and non-zero for failure
*/
int ufshcd_runtime_resume(struct ufs_hba *hba)
{
int ret = 0;
ktime_t start = ktime_get();
if (!hba)
return -EINVAL;
if (!hba->is_powered)
goto out;
else
ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
out:
trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
ktime_to_us(ktime_sub(ktime_get(), start)),
hba->curr_dev_pwr_mode, hba->uic_link_state);
return ret;
}
EXPORT_SYMBOL(ufshcd_runtime_resume);
debug ufs信息
ls /sys/kernel/debug/4804000.ufshc
crash_on_err dump_device_desc host_regs reset_controller
dbg_print_en err_inj_scenario inject_fault show_hba
dme_local_read err_inj_stats power_mode stats
dme_peer_read err_state qcom
UFS低功耗,当ufs没有读写操作会断开电源进入sleep模式。
不对ufs操作和往ufs写数据对比