UFS子系统架构
1.UFS协议
无论是ufs host controller部分还是ufs device部分,他们都将遵循统一的UFS规范
-
UFS Application Layer(UAP)应用层
1.UFS command set (UCS)
UCS处理命令集,如读、写命令等,.使用的命令是简化的SCSI命令(基于SBC和SPC),也可以扩展UFS本地命令集,目前暂时没有定义
2.Task Manager
任务管理器用以管理命令队列中的命令。比如任务管理器可以发Abort命令,终止之前发下去的命令。它也可以清空命令队列中的所有命令 -
device manager(Query Request)
设备管理器用以管理UFS设备,包括:
(1)处理设备级操作
设备功耗管理、数据传输设置、后台操作使能和其它的特定操作
(2)管理设备级配置
维护和存储一组描述符,例如查询请求命令允许修改和查询设备的配置信息 -
The UFS Transport Protocol (UTP)传输层
主要功能在UFS host端和ufs device端传输UPIU,将应用层的命令封装成UPIU,命令的数据、状态等对应不同的UPIU。UPIU是主机和设备进行信息交换的基本数据单元,它使用数据帧可以最小限度的减少HOST的处理时间,同时由device端控制数据传输的节奏,无需host端poll -
UFS Interconnect Layer(UIC)互联层
主要包括MIPI UniPro 数据链路层和MIPI M-PHY 物理层。其中,MIPI UniPro 数据链路层负责主机和设备的链接,它本身是一个完整的协议栈; MIPI M-PHY 物理层负责传输实实在在的物理信号,使用8/10编码、差分信号串行数据传输,数据传输分高低速模式,每种模式下又有几种不同的速度档
在 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;
2.UFS 重要 Layer
此外,设备管理器可以略过传输层,直接管理与控制互联层:
主机设备管理器可以通过原语(Primitive)直接与UFS互联层(UIC,即MIPI的UniPro和M-PHY)通信。除了上图中所示的reset原语,UFS还包括让UIC进入和退出休眠的原语:DME_HIBERNATE_ENTER和DME_HIBERNATE_EXIT。
这是UFS主机和设备之间链路的省电模式,对UFS设备来说,链路只是整个UFS设备的一部分。一个UFS设备是否省电,除了看其链路,还需要考虑UFS控制器、存储介质等是否省电,即看整个UFS设备是否有好的电源管理。
Logical unit
UFS 设备有若干个 LU,LU 接收主机发过来的命令或请求可能来自应用层的 SCSI 模块、设备管理器或者任务管理器:
每个 LU 都是独立的,“独立”表现在下面几个方面:
- 逻辑地址空间是独立的,都是从LBA[2] 0(Logical Block Addressing,逻辑块寻址)开始;
- 逻辑块大小可以不同,可以为4KB,…;
- 可以有不同的安全属性,比如可以设置不同的写保护属性;
- 每个 LU 可以有自己的命令队列;
- LU 可以启动代码、应用程序代码和应用数据;
总结来说,划分不同 LU 有以下作用:
- 外部可寻址;
- 存储实体(可以单独做 Boot 启动、写保护或 RPMB[3](Replay Protected Memory Block,重播保护内存块) );
- 内部任务队列;
3.UFS 架构
UFS 架构以 HCI(Host Controller Interface,主机控制器接口)为界划分为三部分。如下图,蓝色框上方调用 HCI 的为主机软件部分,蓝色框下方的为 HCI 封装的硬件处理细节部分,即 HC(Host Controller,主机控制器)
HCI 接口架构
数据结构服务于软件,主机的软件通过内存中的一系列主机 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:
-
- Interrupt status:这些寄存器为主机软件提供了使能/中止以及中断状态的接口;
- Host status:该寄存器显示 HC 的状态,并允许主机软件初始化/禁用 HC;
- UTP Transfer Request:这些寄存器给 UTP Transfer Request List 提供了接口;
- UTP Task Management Request:这些寄存器为 UTP Task Management request list 提供了一个接口;
- UIC Command:这些寄存器为 Unipro 配置以及控制提供了接口;
-
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 host驱动通过分配和使用UTRD描述符和UTMRD描述符来与host控制器硬件通信。host控制器系统内存可以同时接受多达32个UTRD描述符和8个UTMRD描述符。每个UTRD描述符指向了一块内存区域,这块内存区域包含:命令UPIU(UCD),response UPIU,并包含了一块物理区域描述符表(PRDT),表中每一项指向一个数据buffer,存储需要传输的数据(command upiu)或要接收的数据(response upiu)。UCD的command和response将被分别组装成UPIU并通过UTP层进行传输。
- UTP UTRD
This section defines Transfer Request Descriptor for UTP commands.
对应数据结构为struct utp_transfer_req_desc
- UTP command descriptor
A UTP command descriptor contains the UPIU for the command, offset and length of the data buffer associated with the command, and offset and length of the PRDT.
对应的数据结构为struct utp_transfer_cmd_desc
UTP TMR descriptor (UTMRD)
对应的数据结构为struct utp_task_req_desc
4.UFS电源管理
UFS定义了4种基本功耗模式:Active,Idle,Power Down和Sleep(简称AIDS),外加3个过渡功耗模式:Pre-Active, Pre-Sleep和Pre-PowerDown,一共是7种功耗模式。非常4+3!
Active模式:UFS设备在执行命令或者做后台任务(Background Operation)时处于这种状态;
Idle模式:UFS设备空闲时,即既没有来自UFS主机的命令,自身也没有后台任务需要处理,设备就处于该状态;
Sleep模式:闲得瞌睡了。睡眠模式下,VCC电源可能被切断(取决UFS设备设计)。VCC一般给闪存供电,即切断闪存供电。
Power Down模式:掉电模式下,所有电源供电VCC, VCCQ和VCCQ2都可能被掐断(取决UFS设备设计),该模式是最省电的功耗模式了。
这些模式之间的转换如下图:我们只需要重点关注sleep->active->idle状态
5.实战:通过一个ufs缺陷了解ufs
缺陷描述:一直cat /sys/devices/platform/soc/4804000.ufshc/life_time_est_a 这个节点查看ufs寿命,会概率性出现系统重启。
有用的日志信息:
[ 333.848513] ufshcd-qcom 4804000.ufshc: pwr ctrl cmd 0x18 with mode 0x0 completion timeout
[ 334.360545] ufshcd-qcom 4804000.ufshc: pwr ctrl cmd 0x18 with mode 0x0 completion timeout
[ 334.868572] ufshcd-qcom 4804000.ufshc: pwr ctrl cmd 0x18 with mode 0x0 completion timeout
[ 334.972668] ufshcd-qcom 4804000.ufshc: pwr ctrl cmd 0x18 failed, host upmcrs:0x5
[ 334.980372] ufshcd-qcom 4804000.ufshc: UFS Host state=2
[ 334.985868] ufshcd-qcom 4804000.ufshc: lrb in use=0x0, outstanding reqs=0x0 tasks=0x0
[ 334.994068] ufshcd-qcom 4804000.ufshc: saved_err=0x0, saved_uic_err=0x0, saved_ce_err=0x0
[ 335.002634] ufshcd-qcom 4804000.ufshc: Device power mode=2, UIC link state=2
[ 335.009929] ufshcd-qcom 4804000.ufshc: PM in progress=1, sys. suspended=0
[ 335.016949] ufshcd-qcom 4804000.ufshc: Auto BKOPS=0, Host self-block=1
[ 335.023709] ufshcd-qcom 4804000.ufshc: Clk gate=1, hibern8 on idle=4
[ 335.030709] ufshcd-qcom 4804000.ufshc: error handling flags=0x0, req. abort count=0
[ 335.038709] ufshcd-qcom 4804000.ufshc: Host capabilities=0x1587031f, caps=0x8f
[ 335.046185] ufshcd-qcom 4804000.ufshc: quirks=0x0, dev. quirks=0xe2
[ 335.052757] ufshcd-qcom 4804000.ufshc: pa_err_cnt_total=0, pa_lane_0_err_cnt=0, pa_lane_1_err_cnt=0, pa_line_reset_err_cnt=0
通过Device power mode=2,UIC link state=0可以知道,电源进入sleep模式,链路状态进入disabeld状态。
思路1:想办法保证power和link是active状态,直接调ufshcd_resume回复power和link为正常状态。
设置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);
int ufshcd_resume();
int ufshcd_vreg_set_hpm()
int ufshcd_setup_vreg(hba, true);
ufshcd_toggle_vreg(dev, info->vcc, on);//给ufs设备供电
ufshcd_toggle_vreg(dev, info->vccq, on);
ufshcd_toggle_vreg(dev, info->vccq2, on);
ufshcd_vops_resume(hba, pm_op);
hba->vops->resume(hba, op);
ret = ufshcd_uic_hibern8_exit(hba);//退出链路休眠模式(hibern8是链路休眠模式)
ufshcd_set_link_active(hba);//激活链路
补充:三个供电电压,VCC,VCCQ和VCCQ2,分别给UFS设备模块供电。UFS设备主要包括三部分:前端UFS接口(M-PHY),UFS控制器 和 闪存介质(图中的Memory模块)。VCC 给 闪存介质供电,VCCQ 一般给闪存输入输出接口 和 UFS控制器供电,VCCQ2一般给 M-PHY或其它一些低电压模块供电。
思路2:想办法保证power和link是active状态,直接调用pm_runtime_get_sync进入resume恢复power 为active状态。
pm_runtime_get_sync/pm_runtime_put_sync 增加/减少计数值,并判断是否进入suspend/resume。
-
在struct dev_pm_ops提供了3个回调函数:runtime_suspend,runtime_resume,runtime_idle,一般runtime_idle这个空闲函数不需要提供
-
上面2个函数不会直接导致runtime_suspend,runtime_resume,runtime_idle被调用,只是使能和修改计数值,当引用计数减为0,调用suspend,从0变为大于0调用resume。
pm_runtime_get_sync
__pm_runtime_resume(dev, RPM_GET_PUT)
atomic_inc(&dev->power.usage_count); // 若上级arg2&RPM_GET_PUT为真,才调用
rpm_resume(dev, rpmflags) //关闭本地CPU中断后调用它
if (dev->power.disable_depth > 0) retval = -EACCES;
//若要使用runtime PM的函数,需要首先pm_runtime_enable。
if (!dev->power.timer_autosuspends)
/*为了防止设备频繁的开关,可以设置timer_autosuspends的值*/
pm_runtime_deactivate_timer(dev);
if (dev->power.runtime_status == RPM_ACTIVE) {
/*如果已经是ACTIVE,就没有必要再次resume*/
if (dev->power.runtime_status == RPM_RESUMING || dev->power.runtime_status == RPM_SUSPENDING) 如果设备正处于RPM_RESUMING和RPM_SUSPENDING状态,等待其完成
if (!parent && dev->parent)
//增加父级的使用计数器并在必要时恢复它,在resume设备本身之前先resume父设备。
开始resume设备自己:
dev->pm_domain->ops->runtime_resume //或
dev->type->pm->runtime_resume //或
dev->class->pm->runtime_resume //或
dev->bus->pm->runtime_resume
//或 前4个被称为subsystem level的callback,优先调用,第5个是驱动级别的。
dev->driver->pm->runtime_resume //或
__update_runtime_status(dev, RPM_SUSPENDED);
//如果resume失败,重新设置回SUSPENDED状态
if (parent) atomic_inc(&parent->power.child_count);
//如果resume成功时给父亲的child_count加1
wake_up_all(&dev->power.wait_queue); //唤醒其它进程
pm_runtime_put_sync
__pm_runtime_idle(dev, RPM_GET_PUT)
if (!atomic_dec_and_test(&dev->power.usage_count)) //减少usage_count引用计数
rpm_idle(dev, rpmflags); //让设备进入idle状态
rpm_check_suspend_allowed
//检查是否允许设备进入suspend状态,看来内核把idle和suspend一样看待了。
if (dev->power.disable_depth > 0) retval = -EACCES;
//调用时还没有pm_runtime_enable,就失败。
if (atomic_read(&dev->power.usage_count) > 0) retval = -EAGAIN;
if (!dev->power.ignore_children && atomic_read(&dev->power.child_count)) retval = -EBUSY; //它的孩子不全睡眠它是不能睡眠的
if (dev->power.runtime_status != RPM_ACTIVE) retval = -EAGAIN;
//如果不是出于ACTIVE状态直接返回。
开始suspend设备自己:
dev->pm_domain->ops->runtime_suspend //或
dev->type->pm->runtime_suspend //或
dev->class->pm->runtime_suspend //或
dev->bus->pm->runtime_suspend
//或 前4个被称为subsystem level的callback,优先调用,第5个是驱动级别的。
dev->driver->pm->runtime_suspend //或
wake_up_all(&dev->power.wait_queue); //唤醒其它进程
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
可以通过cat show_hba将ufs设备信息全部打印出来。也可以通过cat host_regs将host的寄存器的值打印出来。
static int ufsdbg_show_hba_show(struct seq_file *file, void *data)
{
struct ufs_hba *hba = (struct ufs_hba *)file->private;
seq_printf(file, "hba->outstanding_tasks = 0x%x\n",
(u32)hba->outstanding_tasks);
seq_printf(file, "hba->outstanding_reqs = 0x%x\n",
(u32)hba->outstanding_reqs);
seq_printf(file, "hba->capabilities = 0x%x\n", hba->capabilities);
seq_printf(file, "hba->nutrs = %d\n", hba->nutrs);
seq_printf(file, "hba->nutmrs = %d\n", hba->nutmrs);
seq_printf(file, "hba->ufs_version = 0x%x\n", hba->ufs_version);
seq_printf(file, "hba->irq = 0x%x\n", hba->irq);
seq_printf(file, "hba->auto_bkops_enabled = %d\n",
hba->auto_bkops_enabled);
seq_printf(file, "hba->ufshcd_state = 0x%x\n", hba->ufshcd_state);
seq_printf(file, "hba->clk_gating.state = 0x%x\n",
hba->clk_gating.state);
seq_printf(file, "hba->eh_flags = 0x%x\n", hba->eh_flags);
seq_printf(file, "hba->intr_mask = 0x%x\n", hba->intr_mask);
seq_printf(file, "hba->ee_ctrl_mask = 0x%x\n", hba->ee_ctrl_mask);
/* HBA Errors */
seq_printf(file, "hba->errors = 0x%x\n", hba->errors);
seq_printf(file, "hba->uic_error = 0x%x\n", hba->uic_error);
seq_printf(file, "hba->saved_err = 0x%x\n", hba->saved_err);
seq_printf(file, "hba->saved_uic_err = 0x%x\n", hba->saved_uic_err);
seq_printf(file, "power_mode_change_cnt = %d\n",
hba->ufs_stats.power_mode_change_cnt);
seq_printf(file, "hibern8_exit_cnt = %d\n",
hba->ufs_stats.hibern8_exit_cnt);
seq_printf(file, "pa_err_cnt_total = %d\n",
hba->ufs_stats.pa_err_cnt_total);
seq_printf(file, "pa_lane_0_err_cnt = %d\n",
hba->ufs_stats.pa_err_cnt[UFS_EC_PA_LANE_0]);
seq_printf(file, "pa_lane_1_err_cnt = %d\n",
hba->ufs_stats.pa_err_cnt[UFS_EC_PA_LANE_1]);
seq_printf(file, "pa_line_reset_err_cnt = %d\n",
hba->ufs_stats.pa_err_cnt[UFS_EC_PA_LINE_RESET]);
seq_printf(file, "dl_err_cnt_total = %d\n",
hba->ufs_stats.dl_err_cnt_total);
seq_printf(file, "dl_nac_received_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_NAC_RECEIVED]);
seq_printf(file, "dl_tcx_replay_timer_expired_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_TCx_REPLAY_TIMER_EXPIRED]);
seq_printf(file, "dl_afcx_request_timer_expired_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_AFCx_REQUEST_TIMER_EXPIRED]);
seq_printf(file, "dl_fcx_protection_timer_expired_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_FCx_PROTECT_TIMER_EXPIRED]);
seq_printf(file, "dl_crc_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_CRC_ERROR]);
seq_printf(file, "dll_rx_buffer_overflow_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_RX_BUFFER_OVERFLOW]);
seq_printf(file, "dl_max_frame_length_exceeded_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_MAX_FRAME_LENGTH_EXCEEDED]);
seq_printf(file, "dl_wrong_sequence_number_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_WRONG_SEQUENCE_NUMBER]);
seq_printf(file, "dl_afc_frame_syntax_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_AFC_FRAME_SYNTAX_ERROR]);
seq_printf(file, "dl_nac_frame_syntax_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_NAC_FRAME_SYNTAX_ERROR]);
seq_printf(file, "dl_eof_syntax_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_EOF_SYNTAX_ERROR]);
seq_printf(file, "dl_frame_syntax_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_FRAME_SYNTAX_ERROR]);
seq_printf(file, "dl_bad_ctrl_symbol_type_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_BAD_CTRL_SYMBOL_TYPE]);
seq_printf(file, "dl_pa_init_err_cnt = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_PA_INIT_ERROR]);
seq_printf(file, "dl_pa_error_ind_received = %d\n",
hba->ufs_stats.dl_err_cnt[UFS_EC_DL_PA_ERROR_IND_RECEIVED]);
seq_printf(file, "dme_err_cnt = %d\n", hba->ufs_stats.dme_err_cnt);
return 0;
}
不对ufs操作和往ufs写数据对比
UFS访问硬件资源信息
ufshcd_read_desc_param()
ufshcd_query_descriptor_retry()
__ufshcd_query_descriptor()
ufshcd_hold_all(hba);//退出hibern8模式进入active
ufshcd_init_query()//构造请求reqest初始化
ufshcd_exec_dev_cmd()//执行命令查询ufs寿命
ufshcd_compose_dev_cmd()//构造lrbp结构体
ufshcd_send_command()//发送命令
ufshcd_wait_for_dev_cmd()//等待命令执行结果
参考资料:
https://blog.csdn.net/jasonactions/article/details/116295649
https://blog.csdn.net/don_chiang709/article/details/89314552
https://blog.csdn.net/Frank_sample/article/details/119033341
https://blog.csdn.net/jasonactions/article/details/116293944
https://blog.csdn.net/jasonactions/article/details/116932302
https://blog.csdn.net/don_chiang709/category_8805138.html文章来源:https://www.toymoban.com/news/detail-803874.html
https://blog.csdn.net/frank_sample/category_11016468.html文章来源地址https://www.toymoban.com/news/detail-803874.html
到了这里,关于SCSI/UFS储存架构/协议/电源管理/命令处理流程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!