Contributors: Venkatraman S
Packages affected: Linux Kernel MMC Stack
- High Priority Interrupt (HPI) is a procedure defined in eMMC specification v4.41 and v4.5. The procedure provides the flexibility to alter the First In, First Out sequence of MMC command execution, to service emergency requests. HPI can be used under 2 circumstances.
- To interrupt background operations (BKOPS)
- To interrupt foreground operations (Single block or multi block writes)
HPI with Background operations
- Background operations is a procedure defined in eMMC specification v4.41. It is a mechanism for the MMC card to indicate to the host controller the level of urgency of Garbage Collection (GC) operations. This helps the host controller driver to schedule time for house keeping operations (BKOPS) for the card, as the host controller is in a better position to know of any pending transactions with the card.
Procedure for Background operations (BKOPS)
- Host controller sets BKOPS_EN in EXT_CSD at init. This lets the device (card) know that the host controller will help in scheduling maintenance operations better.
- Host controller queries the BKOPS requirement status from the card periodically. The card might report the requirement under 4 different levels
- * No Operation required
- * Operation outstanding - non critical
- * Operation outstanding - performance being impacted
- * Operation outstanding - critical
- Based on the above information, host controller can start background operations using the BKOPS_START setting in EXT_CSD. Obviously, this should be started when there are no other pending transactions.
- If the background operations are either in 'critical' or in 'performance impacted' state, such states can also be specified in every response of type R1 by the card.
- If the host controller has started the BKOPS (to let the card execute it's maintenance operations), and it requires a normal transaction to be executed urgently, it has to interrupt the BKOPS abruptly. The host controller can use the HPI command for this.
- The HPI command is either a CMD12 (STOP) or CMD13(STATUS), with the HPI bit set as an argument.
- On a successful response for HPI command, the host controller can service the actual command.
- If there are no further commands that required urgent attention, the host controller can resume BKOPS using the BKOPS_START as above.
Implementation of HPI with Background operations
Implementation of usage of HPI for Background operations is already proposed. For details, see http://www.spinics.net/lists/linux-mmc/msg04786.html
HPI with foreground operations
- On some systems, reads and writes may have different priorities for the host. For example, a multi block write operation might take a long time to complete, during this time a process waiting to read a short section of data has to wait. This might not be desirable and HPI is one of the way to service
urgent read requests by aborting (or suspending) a write procedure, service the read request, and resume the write request again.
Procedure for using HPI for foreground operations
- The host controller issues either WRITE or WRITE_MULTIPLE_BLOCK or ERASE (CMD24/CMD25/CMD38) command to the device.
- The host controller receives a read request from application and decides that is of higher priority than the ongoing command.
- The device is in busy (also called as 'programming state') as it executes the writing or erase operation.
- The host controller issues a HPI command (either a STOP command or SEND_STATUS command). The device aborts the write operation.
- The host controller can query the successful part of the aborted operation using the CORRECTLY_PRG_SECTORS_NUM field in EXT_CSD. This will be useful while resuming the aborted command.
- The host controller can now issue the higher priority command.
- The host controller can now compose a new command which contains the incomplete portion of the aborted command (or if required, the entire command).
For more details, refer to the eMMC4.41 specification and this WhitePaper
HPI implementation on Linux MMC stack - Design aspects and problems
Fundamentally, the MMC stack deals with one transaction (or command) at a time. After issuing a mmc_host_ops->request operation, the stack waits for the operation to complete or timeout. Since period encomposes the issuing of command, setting up the DMA, and programming the card. A response is received from the controller driver only after the programming has been completed.
- * To work around this, a new primitive in mmc_host_ops, called abort, is proposed. When an abort is issued, the controller driver should possibly stop executing the ongoing command. If the transfer has already been completed, the abort can be ignored.
- ** In some host controller drivers, the DMA is programmed for one element of sg_list, waiting for it to complete, and setting up the DMA for the next element in sg_list, till every element is programmed. In such a situation, the abort implementation should stop such a procedure from continuing.
- ** Because of the software involvement in programming the content of sg_list, the duration of the 'programming state' in the card, as specified in Fig.28 of eMMC4.41 specification is very short. If an HPI command is issued when the device is not in programming state, the device could either ignore the command or return an error.
- Priority decision making: At the MMC stack level, transactions are received one at a time. The mmc-core lacks the global view necessary to check if there are pending read requests, and if they are important enough to preempt the ongoing write. MMC stack can look at the ongoing request and prepares the next request.
WorkingGroups/KernelArchived/Specs/Utilize-emmc-hpi-to-minimze-flash-latency (last modified 2013-01-14 19:40:45)