|
gem5
v20.1.0.0
|
#include <deque>#include <functional>#include "base/addr_range.hh"#include "base/bitfield.hh"#include "base/statistics.hh"#include "debug/UFSHostDevice.hh"#include "dev/arm/abstract_nvm.hh"#include "dev/arm/base_gic.hh"#include "dev/storage/disk_image.hh"#include "dev/dma_device.hh"#include "dev/io_device.hh"#include "mem/packet.hh"#include "mem/packet_access.hh"#include "params/UFSHostDevice.hh"#include "sim/serialize.hh"#include "sim/stats.hh"Go to the source code of this file.
Classes | |
| class | UFSHostDevice |
| UFS command flow state machine digraph CommandFlow{ node [fontsize=10]; IDLE -> transferHandler [ label=" transfer/task/command request " fontsize=6]; transferHandler -> command [ label=" It is a command " fontsize=6]; command -> IDLE [ label=" Command done, no further action " fontsize=6]; transferHandler -> taskStart [ label=" It is a task " fontsize=6]; taskStart -> finalUTP [ label=" Task handled, now acknowledge (UFS) " fontsize=6]; transferHandler -> transferStart [ label=" It is a transfer " fontsize=6]; transferStart -> SCSIResume [ label=" Transfer, obtain the specific command " fontsize=6]; SCSIResume -> DiskDataFlowPhase [ label=" Disk data transfer (see other graphs) " fontsize=6]; SCSIResume -> DeviceDataPhase [ label=" Device info transfer (handled in SCSIResume) " fontsize=6]; DiskDataFlowPhase -> transferDone [ label=" Transfer done, acknowledge SCSI command " fontsize=6]; DeviceDataPhase -> transferDone [ label=" Transfer done, acknowledge SCSI command " fontsize=6]; transferDone -> finalUTP [ label=" Transfer handled, now acknowledge (UFS) " fontsize=6]; finalUTP -> readDone [ label=" All handled, clear data structures " fontsize=6]; readDone -> IDLE [ label=" All handled, nothing outstanding " fontsize=6]; readDone -> transferHandler [ label=" All handled, handle next outstanding " fontsize=6]; }. More... | |
| struct | UFSHostDevice::HCIMem |
| Host Controller Interface This is a set of registers that allow the driver to control the transactions to the flash devices. More... | |
| struct | UFSHostDevice::UTPUPIUHeader |
| All the data structures are defined in the UFS standard This standard be found at the JEDEC website free of charge (login required): http://www.jedec.org/standards-documents/results/jesd220. More... | |
| struct | UFSHostDevice::UTPUPIURSP |
| struct UTPUPIURSP - Response UPIU structure header: UPIU header DW-0 to DW-2 residualTransferCount: Residual transfer count DW-3 reserved: Reserved DW-4 to DW-7 senseDataLen: Sense data length DW-8 U16 senseData: Sense data field DW-8 to DW-12 More... | |
| struct | UFSHostDevice::UTPUPIUTaskReq |
| struct UTPUPIUTaskReq - Task request UPIU structure header - UPIU header structure DW0 to DW-2 inputParam1: Input param 1 DW-3 inputParam2: Input param 2 DW-4 inputParam3: Input param 3 DW-5 reserved: Reserver DW-6 to DW-7 More... | |
| struct | UFSHostDevice::UFSHCDSGEntry |
| struct UFSHCDSGEntry - UFSHCI PRD Entry baseAddr: Lower 32bit physical address DW-0 upperAddr: Upper 32bit physical address DW-1 reserved: Reserved for future use DW-2 size: size of physical segment DW-3 More... | |
| struct | UFSHostDevice::UTPTransferCMDDesc |
| struct UTPTransferCMDDesc - UFS Commad Descriptor structure commandUPIU: Command UPIU Frame address responseUPIU: Response UPIU Frame address PRDTable: Physcial Region Descriptor All lengths as defined by JEDEC220 More... | |
| struct | UFSHostDevice::UPIUMessage |
| UPIU tranfer message. More... | |
| struct | UFSHostDevice::UTPTransferReqDesc |
| struct UTPTransferReqDesc - UTRD structure header: UTRD header DW-0 to DW-3 commandDescBaseAddrLo: UCD base address low DW-4 commandDescBaseAddrHi: UCD base address high DW-5 responseUPIULength: response UPIU length DW-6 responseUPIUOffset: response UPIU offset DW-6 PRDTableLength: Physical region descriptor length DW-7 PRDTableOffset: Physical region descriptor offset DW-7 More... | |
| struct | UFSHostDevice::UTPTransferReqDesc::RequestDescHeader |
| struct RequestDescHeader dword0: Descriptor Header DW0 dword1: Descriptor Header DW1 dword2: Descriptor Header DW2 dword3: Descriptor Header DW3 More... | |
| struct | UFSHostDevice::SCSIReply |
| SCSI reply structure. More... | |
| struct | UFSHostDevice::LUNInfo |
| Logic unit information structure. More... | |
| struct | UFSHostDevice::transferInfo |
| Different events, and scenarios require different types of information. More... | |
| struct | UFSHostDevice::transferDoneInfo |
| transfer completion info. More... | |
| struct | UFSHostDevice::transferStart |
| Transfer start information. More... | |
| struct | UFSHostDevice::taskStart |
| Task start information. More... | |
| struct | UFSHostDevice::SCSIResumeInfo |
| After a SCSI command has been identified, the SCSI resume function will handle it. More... | |
| struct | UFSHostDevice::writeToDiskBurst |
| Disk transfer burst information. More... | |
| struct | UFSHostDevice::UFSHostDeviceStats |
| Statistics. More... | |
| class | UFSHostDevice::UFSSCSIDevice |
| device layer: This is your Logic unit This layer implements the SCSI functionality of the UFS Device One logic unit controls one or more disk partitions More... | |
This is a base class for UFS devices The UFS interface consists out of one host controller which connects a number of devices which together contain up to 8 logic units. A Logical Unit is an externally addressable, independent, processing entity that processes SCSI tasks (commands) and performs task management functions. The decision has been made to abstract the device away, and model the different logic units. Effectively this means that there is one Host layer which handles all the UFS commands (everything UTP, UPIU and UNIpro related) and a SCSI layer, which handles the SCSI interpretation and the interaction with the "disk" (effectively the LBA that that particular Logic Unit controls). Each Logic unit should therefor control a disk image and a timing model. The UFS protocol has three types of commands (explained later). Each has different phases and each phase need to wait for its particular data. This is the reason that this model contains a lot of events. For clarity, a state diagram in doxygen has been provided. To fully apreciate the stages that the model flows through, the states have been broken into three state diagrams. It is best if one imagines the command flow state machine to be happening in the UFSHost layer, and the other two to flow through all the layers of the model (UFS host, SCSI and NVM model). See it as a quarry, one state diagram is moving the crane into place, and the other ones are transporting the dirt down, or the valuables up. For complete information about the working of UFS please refer to http://www.jedec.org/standards-documents/results/jesd220 or http://www.jedec.org/standards-documents/results/jesd223 The documents are available free of charge, although you will need to have an acount.
Definition in file ufs_device.hh.