ahci_msm.txt 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323
  1. Introduction
  2. ============
  3. The SATA Host Controller developed for Qualcomm SoC is used
  4. to facilitate SATA storage devices that connect to SoC through a
  5. standard SATA cable interface. The MSM Advanced Host Controller
  6. Interface (AHCI) driver interfaces with the generic Linux AHCI driver
  7. and communicates with the AHCI controller for data movement between
  8. system memory and SATA devices (persistent storage).
  9. Hardware description
  10. ====================
  11. Serial Advanced Technology Attachment (SATA) is a communication
  12. protocol designed to transfer data between a computer and storage
  13. devices (Hard Disk Drive(HDD), Solid State Drives(SSD) etc.).
  14. First generation (Gen1) SATA interfaces communicate at a serial
  15. rate of 1.5Gb/s and use low-voltage differential signaling on
  16. serial links. With 8b-10b encoding, the effective data throughput
  17. for Gen1 interface is 150MB/s.
  18. The SATA host controller in Qualcomm chipsets adheres to the AHCI 1.3
  19. specification which describes the interface between system software
  20. and the host controller, as well as the functional behavior needed
  21. for software to communicate with the SATA host controller.
  22. The SATA PHY hardware macro in Qualcomm chipsets adheres to the
  23. SATA 3.0 specification with Gen1 serial interface. This is used to
  24. serialize and de-serialize data and communicates with SATA HDD. Also,
  25. the PHY can detect SATA HDD during hot swap and raise an interrupt to
  26. the CPU through AHCI controller to notify about the detection/removal.
  27. The following figure shows the SATA architecture block diagram as
  28. implemented in MSM chipsets.
  29. +---------+
  30. |SATA Disk|
  31. | Drive |
  32. +---------+
  33. ^ ^
  34. Tx | | Rx
  35. v v
  36. +--------------+ +--------------+ +-----------+
  37. | System Memory| | SATA PHY | | CPU |
  38. +--------------+ +--------------+ +-----------+
  39. ^ ^ ^ ^ ^
  40. | | | | |
  41. | v v | |
  42. | +------------------+(Interrupt)|
  43. | | SATA CONTROLLER |-----+ |
  44. | +------------------+ |
  45. | ^ ^ |
  46. | | | |
  47. v v v v
  48. <--------------------------------------------------------->
  49. < System Fabric (Control and Data) >
  50. <--------------------------------------------------------->
  51. Some controller capabilities:
  52. - Supports 64-bit addressing
  53. - Supports native command queueing (upto 32 commands)
  54. - Supports First-party DMA to move data to and from system memory
  55. - ATA-7 command set compliant
  56. - Port multiplier support for some chipsets
  57. - Supports aggressive power management (partial, slumber modes)
  58. - Supports asynchronous notification
  59. Software description
  60. ====================
  61. The SATA driver uses the generic interface to read/write data to
  62. the Hard Disk Drive (HDD). It uses following components in Linux
  63. to interface with the generic block layer which then interfaces
  64. with file system or user processes.
  65. 1) AHCI platform Driver (includes MSM-specific glue driver)
  66. 2) LIBAHCI
  67. 3) LIBATA
  68. 4) SCSI
  69. AHCI platform driver registers as a device driver for platform
  70. device registered during SoC board initialization. It is responsible
  71. for platform specific tasks like PHY configuration, clock initial-
  72. ization, claiming memory resources etc. Also, implements certain
  73. functionality that deviates from the standard specification.
  74. Library "LIBAHCI" implements software layer functionality described
  75. in the standard AHCI specification. It interfaces with the LIBATA
  76. framework to execute SATA the command set. It converts ATA task files
  77. into AHCI command descriptors and pass them to the controller for
  78. execution. It handles controller interrupts and sends command
  79. completion events to the upper layers. It implements a controller-
  80. specific reset and recover mechanism in case of errors. It implements
  81. link power management policies - partial, slumber modes, runtime power
  82. management and platform power management. It abstracts the low-level
  83. controller details from the LIBATA framework.
  84. "LIBATA" is a helper library for implementing ATA and SATA command
  85. protocol as described in standard ATA and SATA specifications. It
  86. builds read/write requests from SCSI commands and pass them to the
  87. low-level controller driver (LLD). It handshakes with the SATA
  88. device using standard commands to understand capabilities and carry
  89. out device configurations. It interfaces with the SCSI layer to manage
  90. underlying disks. It manages different devices connected to each host
  91. port using a port multiplier. Also, it manages the link PHY component,
  92. the interconnect interface and any external interface (cables, etc.)
  93. that follow the SATA electrical specification.
  94. The SCSI layer is a helper library for translating generic block layer
  95. commands to SCSI commands and pass them on to the LIBATA framework.
  96. Certain generic stuff like device scan, media change, and hot plug
  97. detection are handled. This layer handles all types of SCSI devices,
  98. and SATA storage devices are one class of SCSI devices. It also provides
  99. the IOCTL interface to manage disks from userspace.
  100. Following is the logical code flow:
  101. +------------------------+
  102. | File System (ext4 etc.)|
  103. +------------------------+
  104. ^
  105. |
  106. v
  107. +------------------------+
  108. | Generic Block Layer |
  109. +------------------------+
  110. ^
  111. |
  112. v
  113. +------------------------+
  114. | SCSI Layer |
  115. +------------------------+
  116. ^
  117. |
  118. v
  119. +------------------------+
  120. | LIBATA library |
  121. +------------------------+
  122. ^
  123. |
  124. v
  125. +------------------------+
  126. | LIBAHCI library |
  127. +------------------------+
  128. ^
  129. |
  130. v
  131. +------------------------+
  132. | AHCI platform driver + |
  133. | MSM AHCI glue driver |
  134. +------------------------+
  135. Design
  136. ======
  137. The MSM AHCI driver acts as a glue driver for the Linux
  138. AHCI controller driver. It provides the following functionality:
  139. - Registers as a driver for msm_sata device which has an AHCI-compliant
  140. controller and PHY as resources.
  141. - Registers an AHCI platform device in the probe function providing
  142. ahci platform data
  143. - AHCI platform data consists of the following callbacks:
  144. - init
  145. o PHY resource acquisition
  146. o Clock and voltage regulator initialization
  147. o PHY calibration
  148. - exit
  149. o PHY power down
  150. o Clock and voltage regulator turn off
  151. - suspend
  152. - resume
  153. o Sequence described in the next section.
  154. - The Linux AHCI platform driver then probes the AHCI device and
  155. initializes it according to the standard AHCI specification.
  156. - The SATA drive is detected as part of scsi_scan_host() called by
  157. LIBAHCI after controller initialization.
  158. Power Management
  159. ================
  160. Various power modes are supported by this driver.
  161. Platform suspend/resume:
  162. During suspend:
  163. - PHY analog blocks are powered down
  164. - Controller and PHY is kept in Power-on-Reset (POR) mode
  165. - Clocks and voltage regulators are gated
  166. During resume:
  167. - Clocks and voltage regulators are ungated
  168. - PHY is powered up and calibrated to functional mode
  169. - Controller is re-initialized to process commands.
  170. Runtime suspend/resume:
  171. - Execute the same steps as in platform suspend/resume.
  172. - Runtime suspend/resume is disabled by default due to regressions
  173. in hot-plug detection (specification limitation). The users can
  174. enable runtime power management with following shell commands.
  175. # cd /sys/devices/platform/msm_sata.0/ahci.0/
  176. # echo auto > ./power/control
  177. # echo auto > ./ata1/power/control
  178. # echo auto > ./ata1/host0/target0:0:0/0:0:0:0/power/control
  179. Note: The device will be runtime-suspended only when user unmounts
  180. all the partitions.
  181. Link power management (defined by AHCI 1.3 specification):
  182. - Automatic low power mode transition are supported.
  183. - AHCI supports two power modes: partial and slumber.
  184. - Software uses Inteface Communication Control (ICC) bits in AHCI
  185. register space to enable automatic partial/slumber state.
  186. - Partial mode:
  187. - Software asserts automatic partial mode when the use
  188. case demands low latency resume.
  189. - Upon receiving partial mode signal, PHY disables byte clocks
  190. and re-enables them during resume and thus has low latency.
  191. - Slumber mode:
  192. - Software asserts automatic slumber mode when the use
  193. case demands low power consumption and can withstand
  194. high resume latencies.
  195. - Upon receiving slumber mode signal, PHY disables byte
  196. clocks and some internal circuitry. Upon resume PHY
  197. enables byte clocks and reacquires the PLL lock.
  198. - Once the software enables partial/slumber modes, the transitioning
  199. into these modes are automatic and is handled by hardware without
  200. software intervention while the controller is idle with no outstanding
  201. commands to process.
  202. - The Linux AHCI link power management defines three modes:
  203. - max_performance (default mode)
  204. Doesn't allow partial/slumber transition when host is idle.
  205. - medium_power (Partial mode)
  206. Following shell commands are used to enable this mode:
  207. # cd /sys/devices/platform/msm_sata.0/ahci.0/
  208. # echo medium_power > ./ata1/host0/scsi_host/host0/link_power_management_policy
  209. - min_power (Slumber mode)
  210. Following shell commands are used to enable this mode:
  211. # cd /sys/devices/platform/msm_sata.0/ahci.0/
  212. # echo min_power > ./ata1/host0/scsi_host/host0/link_power_management_policy
  213. SMP/multi-core
  214. ==============
  215. The MSM AHCI driver hooks only init, exit, suspend, resume callbacks to
  216. the AHCI driver which are serialized by design and hence the driver, which
  217. is inherently SMP safe.
  218. Security
  219. ========
  220. None.
  221. Performance
  222. ===========
  223. The theoretical performance with Gen1 SATA PHY is 150MB/s (8b/10b encoding).
  224. The performance is dependent on various factors, mainly:
  225. - Capabilities of the external SATA hard disk connected to the MSM SATA port
  226. - Various system bus frequencies and system loads
  227. - System memory capabilities
  228. - Benchmark test applications that collect performance numbers
  229. One example of the maximum performance achieved in a specific system
  230. configuration follows:
  231. Benchmark: Iozone sequential performance
  232. Block size: 128K
  233. File size: 1GB
  234. Platform: APQ8064 V2 CDP
  235. CPU Governor: Performance
  236. SanDisk SSD (i100 64GB):
  237. Read - 135MB/s
  238. Write - 125MB/s
  239. Western Digital HDD (WD20EURS 2TB):
  240. Read - 121MB/s
  241. Write - 98MB/s
  242. Interface
  243. =========
  244. The MSM AHCI controller driver provides function pointers as the
  245. required interface to the Linux AHCI controller driver. The main
  246. routines implemented are init, exit, suspend, and resume for handling
  247. MSM-specific initialization, freeing of resources on exit, and
  248. MSM-specific power management tweaks during suspend power collapse.
  249. Driver parameters
  250. =================
  251. None.
  252. Config options
  253. ==============
  254. Config option SATA_AHCI_MSM in drivers/ata/Kconfig enables this driver.
  255. Dependencies
  256. ============
  257. The MSM AHCI controller driver is dependent on Linux AHCI driver,
  258. Linux ATA framework, Linux SCSI framework and Linux generic block layer.
  259. While configuring the kernel, the following options should be set:
  260. - CONFIG_BLOCK
  261. - CONFIG_SCSI
  262. - CONFIG_ATA
  263. - CONFIG_SATA_AHCI_PLATFORM
  264. User space utilities
  265. ====================
  266. Any user space component that can mount a block device can be used to
  267. read/write data into persistent storage. However, at the time of this
  268. writing there are no utilities that author is aware of that can manage
  269. h/w from userspace.
  270. Other
  271. =====
  272. None.
  273. Known issues
  274. ============
  275. None.
  276. To do
  277. =====
  278. - Device tree support.
  279. - MSM bus frequency voting support.