Ufs3 Usb Driver
Casimiro Lurten
The Application layer is composed of the UFS command set layer (UCS),Task Manager and Device manager. The UFS interface is designed to beprotocol agnostic, however SCSI has been selected as a baselineprotocol for versions 1.0 and 1.1 of the UFS protocol layer.
It handles device level operations and deviceconfiguration operations. Device level operations mainly involvedevice power management operations and commands to Interconnectlayers. Device level configurations involve handling of queryrequests which are used to modify and retrieve configurationinformation of the device.
UIC is the lowest layer of the UFS layered architecture. It handlesthe connection between UFS host and UFS device. UIC consists ofMIPI UniPro and MIPI M-PHY. UIC provides 2 service access pointsto upper layer:
Transfer request handling module of UFSHCD receives SCSI commandsfrom the SCSI Midlayer, forms UPIUs and issues the UPIUs to the UFS Hostcontroller. Also, the module decodes responses received from the UFShost controller in the form of UPIUs and intimates the SCSI Midlayerof the status of the command.
This is done through UFSHCD SCSI error handling routines registeredwith the SCSI Midlayer. Examples of some of the error handling commandsissues by the SCSI Midlayer are Abort task, LUN reset and host reset.UFSHCD Routines to perform these tasks are registered withSCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and.eh_host_reset_handler.
This transport driver supports exchanging UFS protocol information units(UPIUs) with a UFS device. Typically, user space will allocatestruct ufs_bsg_request and struct ufs_bsg_reply (see ufs_bsg.h) asrequest_upiu and reply_upiu respectively. Filling those UPIUs shouldbe done in accordance with JEDEC spec UFS2.1 paragraph 10.7.Caveat emptor: The driver makes no further input validations and sends theUPIU to the device as it is. Open the bsg device in /dev/ufs-bsg andsend SG_IO with the applicable sg_io_v4:
Universal Flash Storage (UFS) is a flash storage specification aimed at providing high performance and low power storage memory for mobile phones. UFS has been supported in the Linux kernel since v3.4. Specifications for UFS and its associated Host Controller Interface (UFSHCI) are maintained by the JEDEC standards committee. Specifications like these are periodically updated to meet industry needs. The JEDEC committee has recently released v4.0 of the UFS and UFSHCI specifications, improving the performance and data protection of UFS based systems.
One of the key performance features added to the UFSHCI specification is Multi-Circular Queue (MCQ) support that allows each CPU core to handle data transfer simultaneously to boost performance of multi-core systems. Qualcomm Technologies, Inc developers Asutosh Das and Can Guo have recently submitted a series of patches adding MCQ support to the UFS subsystem in Linux Kernel, which Linaro helped review, and the patches were merged for v6.3 kernel release. The rest of this article discusses the internals of MCQ support and how it is implemented in the Linux kernel.
The UFSHCI specification defines an interface for a device driver to access a UFS host controller in a standard way. This allows a generic driver to manage UFS Host Controllers (HCIs) from different hardware vendors.
The data transfer between the HCI driver and the UFS device happens through an array of data structures called UTP Transfer Request Descriptors (UTRD). These descriptors are contained in a list called UTP Transfer Request List (UTRL) in host memory. A descriptor contains the information required for the host controller to create the command UPIU to be sent to the device and also to pass the response from the device received over response UPIU. The data associated with both command and response UPIUs are transferred using the Physical Region Description Table (PRDT) which consists of an array of pointer and sizeof data buffers.
The UTRL has a doorbell register associated with it, which indicates which UTRDs are available for processing. When the HCI driver writes (rings) to the doorbell register, the controller is signaled of a new work item added to the list. And when the host controller has received the response from the device, it generates an interrupt that allows the HCI driver to handle the completion.
UFS supports a subset of SCSI commands and uses them to communicate with the device. Each SCSI command is identified using a unique task tag, an identifier defined by SCSI. To service a SCSI request, the HCI driver prepares a UTRD, places it on the UTRL and rings the doorbell indicating to the host controller that the UTRD is ready for processing. The host controller parses the UTRDs in the order they were placed on the list and issues the commands to UFS device. On receiving the response from the device, controller updates the response UPIU fields of the corresponding UTRD on the list and notifies the HCI driver through interrupt if applicable. The host controller and driver make use of the task tag to identify the UTRDs in the list.
In response to the interrupt, the HCI driver reads the UTRL doorbell register and compares the value to the list of commands that have been submitted by the driver and not yet completed. Finally, it completes the commands that are outstanding and makes room for the successive commands in the list.
The queues are circular, in that the head pointer in a queue always refers to the next free (or unused) entry in the queue and the tail pointer always refers to the last in-use entry. As the head and tail pointers advance, they wrap to the beginning when they reach the end. When the head and tail pointers are equal, the queue is considered to be empty. When they are not equal, the queue contains one or more entries.
An SQ is implemented as a circular queue of UTRDs, where the HCI driver is the producer and the host controller is the consumer. The HCI driver submits the commands to the host controller by adding UTRDs to the SQ and increments the doorbell tail pointer associated with it. Each SQ is mapped to a Completion Queue (CQ) through which it receives the command completion notification from the host controller. A CQ can be shared by multiple SQs, but the MCQ support added only supports a 1:1 mapping between an SQ and a CQ.
A CQ is also implemented as a circular queue, where the host controller is the producer and the HCI driver is the consumer. After receiving the response UPIU from the device, the host controller updates the relevant head entry of the CQ and raises the interrupt to the HCI driver. The content of the CQ entries looks similar to the UTRDs but they vary slightly by the addition of ID corresponding to the SQ and the Overall Command Status (OCS) field.
Upon receiving a SCSI request, the HCI driver determines the SQ to which the request should be queued, prepares a UTRD and writes it to an entry corresponding to the current doorbell tail pointer of the SQ. Then, it increments the doorbell tail pointer to indicate that it has consumed this entry. This generates a doorbell notification to the host controller.
On receiving the doorbell notification, the host controller fetches the entry from SQ and increments the doorbell head pointer indicating that the entry is free for consumption. It prepares the command UPIU based on the SQ entry and sends it to the device. The device will process the UPIU and when the transfer is complete, it sends a response UPIU back.
After receiving the response from the device, the host controller updates the entry corresponding to the current doorbell tail pointer of the CQ associated with the SQ. The updated entry includes response UPIU, command status, and the SQ ID. Then the host controller increments the doorbell tail pointer, indicating that it has produced (filled) another entry. This causes an interrupt to the CPU, which will be serviced by the driver.
On receiving the interrupt, the driver reads the Interrupt Status register (CQIS) to find out which CQ has generated the interrupt. After finding out the CQ, the driver looks for the task tag associated with the CQ entry.
Currently, the driver uses only shared task tags across all of the SQ/CQ queues i.e., the SCSI layer will use the same set of task tags for each of the queues supported by the host controller. Using shared task tags simplifies the MCQ implementation, but on the other hand, the per-queue task tags may also give performance boost.
The MCQ support has been verified on Qualcomm and MediaTek SoCs. Although it is reported that the MCQ series brings performance improvements to the UFS subsystem, there are no performance metrics available from the vendors at this time. The MCQ support added is an initial one and further improvements are possible, including:
Developing the Linux kernel is a complex and continually evolving process that demands significant technical expertise and computational resources. One of the primary challenges faced by developers is the constant...
The Linux kernel is the heart of any Linux-based operating system. It orchestrates hardware, memory, and other crucial system resources. Building a Linux kernel from source code offers immense flexibility...
Paving the way for automotive applications of the future, KIOXIA offers a broad capacity lineup of UFS(1) for automotive applications, and is well positioned to support data storage demands of increasingly complex automotive applications. KIOXIA automotive UFS supports a temperature range of -40C to +105C, meets AEC-Q100 Grade 2(2) requirements and offers high reliability required by demanding automotive applications.
WriteBooster enhances write performance by utilizing the existing user data area as a temporary SLC buffer without sacrificing capacity. Maximum SLC buffer size can be configured by the host at device configuration and the host can keep writing data to the buffer until the buffer is filled. This feature is enabled dynamically during operation by the host depending on system performance requirements of 5G and other applications.
c80f0f1006