Commit | Line | Data |
---|---|---|
7a3e97b0 SY |
1 | Universal Flash Storage |
2 | ======================= | |
3 | ||
4 | ||
5 | Contents | |
6 | -------- | |
7 | ||
8 | 1. Overview | |
9 | 2. UFS Architecture Overview | |
10 | 2.1 Application Layer | |
11 | 2.2 UFS Transport Protocol(UTP) layer | |
12 | 2.3 UFS Interconnect(UIC) Layer | |
13 | 3. UFSHCD Overview | |
14 | 3.1 UFS controller initialization | |
15 | 3.2 UTP Transfer requests | |
16 | 3.3 UFS error handling | |
17 | 3.4 SCSI Error handling | |
18 | ||
19 | ||
20 | 1. Overview | |
21 | ----------- | |
22 | ||
23 | Universal Flash Storage(UFS) is a storage specification for flash devices. | |
24 | It is aimed to provide a universal storage interface for both | |
25 | embedded and removable flash memory based storage in mobile | |
26 | devices such as smart phones and tablet computers. The specification | |
27 | is defined by JEDEC Solid State Technology Association. UFS is based | |
28 | on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the | |
29 | physical layer and MIPI Unipro as the link layer. | |
30 | ||
31 | The main goals of UFS is to provide, | |
32 | * Optimized performance: | |
33 | For UFS version 1.0 and 1.1 the target performance is as follows, | |
34 | Support for Gear1 is mandatory (rate A: 1248Mbps, rate B: 1457.6Mbps) | |
35 | Support for Gear2 is optional (rate A: 2496Mbps, rate B: 2915.2Mbps) | |
36 | Future version of the standard, | |
37 | Gear3 (rate A: 4992Mbps, rate B: 5830.4Mbps) | |
38 | * Low power consumption | |
39 | * High random IOPs and low latency | |
40 | ||
41 | ||
42 | 2. UFS Architecture Overview | |
43 | ---------------------------- | |
44 | ||
45 | UFS has a layered communication architecture which is based on SCSI | |
46 | SAM-5 architectural model. | |
47 | ||
48 | UFS communication architecture consists of following layers, | |
49 | ||
50 | 2.1 Application Layer | |
51 | ||
52 | The Application layer is composed of UFS command set layer(UCS), | |
53 | Task Manager and Device manager. The UFS interface is designed to be | |
54 | protocol agnostic, however SCSI has been selected as a baseline | |
55 | protocol for versions 1.0 and 1.1 of UFS protocol layer. | |
56 | UFS supports subset of SCSI commands defined by SPC-4 and SBC-3. | |
57 | * UCS: It handles SCSI commands supported by UFS specification. | |
58 | * Task manager: It handles task management functions defined by the | |
59 | UFS which are meant for command queue control. | |
60 | * Device manager: It handles device level operations and device | |
61 | configuration operations. Device level operations mainly involve | |
62 | device power management operations and commands to Interconnect | |
63 | layers. Device level configurations involve handling of query | |
64 | requests which are used to modify and retrieve configuration | |
65 | information of the device. | |
66 | ||
67 | 2.2 UFS Transport Protocol(UTP) layer | |
68 | ||
69 | UTP layer provides services for | |
70 | the higher layers through Service Access Points. UTP defines 3 | |
71 | service access points for higher layers. | |
72 | * UDM_SAP: Device manager service access point is exposed to device | |
73 | manager for device level operations. These device level operations | |
74 | are done through query requests. | |
75 | * UTP_CMD_SAP: Command service access point is exposed to UFS command | |
76 | set layer(UCS) to transport commands. | |
77 | * UTP_TM_SAP: Task management service access point is exposed to task | |
78 | manager to transport task management functions. | |
79 | UTP transports messages through UFS protocol information unit(UPIU). | |
80 | ||
81 | 2.3 UFS Interconnect(UIC) Layer | |
82 | ||
83 | UIC is the lowest layer of UFS layered architecture. It handles | |
84 | connection between UFS host and UFS device. UIC consists of | |
85 | MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points | |
86 | to upper layer, | |
87 | * UIC_SAP: To transport UPIU between UFS host and UFS device. | |
88 | * UIO_SAP: To issue commands to Unipro layers. | |
89 | ||
90 | ||
91 | 3. UFSHCD Overview | |
92 | ------------------ | |
93 | ||
94 | The UFS host controller driver is based on Linux SCSI Framework. | |
95 | UFSHCD is a low level device driver which acts as an interface between | |
96 | SCSI Midlayer and PCIe based UFS host controllers. | |
97 | ||
98 | The current UFSHCD implementation supports following functionality, | |
99 | ||
100 | 3.1 UFS controller initialization | |
101 | ||
102 | The initialization module brings UFS host controller to active state | |
103 | and prepares the controller to transfer commands/response between | |
104 | UFSHCD and UFS device. | |
105 | ||
106 | 3.2 UTP Transfer requests | |
107 | ||
108 | Transfer request handling module of UFSHCD receives SCSI commands | |
109 | from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host | |
110 | controller. Also, the module decodes, responses received from UFS | |
111 | host controller in the form of UPIUs and intimates the SCSI Midlayer | |
112 | of the status of the command. | |
113 | ||
114 | 3.3 UFS error handling | |
115 | ||
116 | Error handling module handles Host controller fatal errors, | |
117 | Device fatal errors and UIC interconnect layer related errors. | |
118 | ||
119 | 3.4 SCSI Error handling | |
120 | ||
121 | This is done through UFSHCD SCSI error handling routines registered | |
122 | with SCSI Midlayer. Examples of some of the error handling commands | |
123 | issues by SCSI Midlayer are Abort task, Lun reset and host reset. | |
124 | UFSHCD Routines to perform these tasks are registered with | |
125 | SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and | |
126 | .eh_host_reset_handler. | |
127 | ||
128 | In this version of UFSHCD Query requests and power management | |
129 | functionality are not implemented. | |
130 | ||
df032bf2 AA |
131 | 4. BSG Support |
132 | ------------------ | |
133 | ||
134 | This transport driver supports exchanging UFS protocol information units | |
135 | (UPIUs) with a UFS device. Typically, user space will allocate | |
136 | struct ufs_bsg_request and struct ufs_bsg_reply (see ufs_bsg.h) as | |
137 | request_upiu and reply_upiu respectively. Filling those UPIUs should | |
138 | be done in accordance with JEDEC spec UFS2.1 paragraph 10.7. | |
139 | *Caveat emptor*: The driver makes no further input validations and sends the | |
140 | UPIU to the device as it is. Open the bsg device in /dev/ufs-bsg and | |
141 | send SG_IO with the applicable sg_io_v4: | |
142 | ||
143 | io_hdr_v4.guard = 'Q'; | |
144 | io_hdr_v4.protocol = BSG_PROTOCOL_SCSI; | |
145 | io_hdr_v4.subprotocol = BSG_SUB_PROTOCOL_SCSI_TRANSPORT; | |
146 | io_hdr_v4.response = (__u64)reply_upiu; | |
147 | io_hdr_v4.max_response_len = reply_len; | |
148 | io_hdr_v4.request_len = request_len; | |
149 | io_hdr_v4.request = (__u64)request_upiu; | |
4eaa329e AA |
150 | if (dir == SG_DXFER_TO_DEV) { |
151 | io_hdr_v4.dout_xfer_len = (uint32_t)byte_cnt; | |
152 | io_hdr_v4.dout_xferp = (uintptr_t)(__u64)buff; | |
5c17f87a AA |
153 | } else { |
154 | io_hdr_v4.din_xfer_len = (uint32_t)byte_cnt; | |
155 | io_hdr_v4.din_xferp = (uintptr_t)(__u64)buff; | |
4eaa329e AA |
156 | } |
157 | ||
5c17f87a AA |
158 | If you wish to read or write a descriptor, use the appropriate xferp of |
159 | sg_io_v4. | |
160 | ||
df032bf2 | 161 | |
7a3e97b0 SY |
162 | UFS Specifications can be found at, |
163 | UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf | |
164 | UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf |