diff options
Diffstat (limited to 'Documentation/mmc')
| -rw-r--r-- | Documentation/mmc/00-INDEX | 8 | ||||
| -rw-r--r-- | Documentation/mmc/mmc-async-req.txt | 87 | ||||
| -rw-r--r-- | Documentation/mmc/mmc-dev-attrs.txt | 76 | ||||
| -rw-r--r-- | Documentation/mmc/mmc-dev-parts.txt | 40 |
4 files changed, 0 insertions, 211 deletions
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX deleted file mode 100644 index a9ba6720ffd..00000000000 --- a/Documentation/mmc/00-INDEX +++ /dev/null @@ -1,8 +0,0 @@ -00-INDEX - - this file -mmc-dev-attrs.txt - - info on SD and MMC device attributes -mmc-dev-parts.txt - - info on SD and MMC device partitions -mmc-async-req.txt - - info on mmc asynchronous requests diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt deleted file mode 100644 index ae1907b10e4..00000000000 --- a/Documentation/mmc/mmc-async-req.txt +++ /dev/null @@ -1,87 +0,0 @@ -Rationale -========= - -How significant is the cache maintenance overhead? -It depends. Fast eMMC and multiple cache levels with speculative cache -pre-fetch makes the cache overhead relatively significant. If the DMA -preparations for the next request are done in parallel with the current -transfer, the DMA preparation overhead would not affect the MMC performance. -The intention of non-blocking (asynchronous) MMC requests is to minimize the -time between when an MMC request ends and another MMC request begins. -Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and -dma_unmap_sg are processing. Using non-blocking MMC requests makes it -possible to prepare the caches for next job in parallel with an active -MMC request. - -MMC block driver -================ - -The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking. -The increase in throughput is proportional to the time it takes to -prepare (major part of preparations are dma_map_sg() and dma_unmap_sg()) -a request and how fast the memory is. The faster the MMC/SD is the -more significant the prepare request time becomes. Roughly the expected -performance gain is 5% for large writes and 10% on large reads on a L2 cache -platform. In power save mode, when clocks run on a lower frequency, the DMA -preparation may cost even more. As long as these slower preparations are run -in parallel with the transfer performance won't be affected. - -Details on measurements from IOZone and mmc_test -================================================ - -https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req - -MMC core API extension -====================== - -There is one new public function mmc_start_req(). -It starts a new MMC command request for a host. The function isn't -truly non-blocking. If there is an ongoing async request it waits -for completion of that request and starts the new one and returns. It -doesn't wait for the new request to complete. If there is no ongoing -request it starts the new request and returns immediately. - -MMC host extensions -=================== - -There are two optional members in the mmc_host_ops -- pre_req() and -post_req() -- that the host driver may implement in order to move work -to before and after the actual mmc_host_ops.request() function is called. -In the DMA case pre_req() may do dma_map_sg() and prepare the DMA -descriptor, and post_req() runs the dma_unmap_sg(). - -Optimize for the first request -============================== - -The first request in a series of requests can't be prepared in parallel -with the previous transfer, since there is no previous request. -The argument is_first_req in pre_req() indicates that there is no previous -request. The host driver may optimize for this scenario to minimize -the performance loss. A way to optimize for this is to split the current -request in two chunks, prepare the first chunk and start the request, -and finally prepare the second chunk and start the transfer. - -Pseudocode to handle is_first_req scenario with minimal prepare overhead: - -if (is_first_req && req->size > threshold) - /* start MMC transfer for the complete transfer size */ - mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); - - /* - * Begin to prepare DMA while cmd is being processed by MMC. - * The first chunk of the request should take the same time - * to prepare as the "MMC process command time". - * If prepare time exceeds MMC cmd time - * the transfer is delayed, guesstimate max 4k as first chunk size. - */ - prepare_1st_chunk_for_dma(req); - /* flush pending desc to the DMAC (dmaengine.h) */ - dma_issue_pending(req->dma_desc); - - prepare_2nd_chunk_for_dma(req); - /* - * The second issue_pending should be called before MMC runs out - * of the first chunk. If the MMC runs out of the first data chunk - * before this call, the transfer is delayed. - */ - dma_issue_pending(req->dma_desc); diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt deleted file mode 100644 index 22ae8441489..00000000000 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ /dev/null @@ -1,76 +0,0 @@ -SD and MMC Block Device Attributes -================================== - -These attributes are defined for the block devices associated with the -SD or MMC device. - -The following attributes are read/write. - - force_ro Enforce read-only access even if write protect switch is off. - -SD and MMC Device Attributes -============================ - -All attributes are read-only. - - cid Card Identifaction Register - csd Card Specific Data Register - scr SD Card Configuration Register (SD only) - date Manufacturing Date (from CID Register) - fwrev Firmware/Product Revision (from CID Register) (SD and MMCv1 only) - hwrev Hardware/Product Revision (from CID Register) (SD and MMCv1 only) - manfid Manufacturer ID (from CID Register) - name Product Name (from CID Register) - oemid OEM/Application ID (from CID Register) - serial Product Serial Number (from CID Register) - erase_size Erase group size - preferred_erase_size Preferred erase size - -Note on Erase Size and Preferred Erase Size: - - "erase_size" is the minimum size, in bytes, of an erase - operation. For MMC, "erase_size" is the erase group size - reported by the card. Note that "erase_size" does not apply - to trim or secure trim operations where the minimum size is - always one 512 byte sector. For SD, "erase_size" is 512 - if the card is block-addressed, 0 otherwise. - - SD/MMC cards can erase an arbitrarily large area up to and - including the whole card. When erasing a large area it may - be desirable to do it in smaller chunks for three reasons: - 1. A single erase command will make all other I/O on - the card wait. This is not a problem if the whole card - is being erased, but erasing one partition will make - I/O for another partition on the same card wait for the - duration of the erase - which could be a several - minutes. - 2. To be able to inform the user of erase progress. - 3. The erase timeout becomes too large to be very - useful. Because the erase timeout contains a margin - which is multiplied by the size of the erase area, - the value can end up being several minutes for large - areas. - - "erase_size" is not the most efficient unit to erase - (especially for SD where it is just one sector), - hence "preferred_erase_size" provides a good chunk - size for erasing large areas. - - For MMC, "preferred_erase_size" is the high-capacity - erase size if a card specifies one, otherwise it is - based on the capacity of the card. - - For SD, "preferred_erase_size" is the allocation unit - size specified by the card. - - "preferred_erase_size" is in bytes. - -SD/MMC/SDIO Clock Gating Attribute -================================== - -Read and write access is provided to following attribute. -This attribute appears only if CONFIG_MMC_CLKGATE is enabled. - - clkgate_delay Tune the clock gating delay with desired value in milliseconds. - -echo <desired delay> > /sys/class/mmc_host/mmcX/clkgate_delay diff --git a/Documentation/mmc/mmc-dev-parts.txt b/Documentation/mmc/mmc-dev-parts.txt deleted file mode 100644 index f08d078d43c..00000000000 --- a/Documentation/mmc/mmc-dev-parts.txt +++ /dev/null @@ -1,40 +0,0 @@ -SD and MMC Device Partitions -============================ - -Device partitions are additional logical block devices present on the -SD/MMC device. - -As of this writing, MMC boot partitions as supported and exposed as -/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the -parent /dev/mmcblkX. - -MMC Boot Partitions -=================== - -Read and write access is provided to the two MMC boot partitions. Due to -the sensitive nature of the boot partition contents, which often store -a bootloader or bootloader configuration tables crucial to booting the -platform, write access is disabled by default to reduce the chance of -accidental bricking. - -To enable write access to /dev/mmcblkXbootY, disable the forced read-only -access with: - -echo 0 > /sys/block/mmcblkXbootY/force_ro - -To re-enable read-only access: - -echo 1 > /sys/block/mmcblkXbootY/force_ro - -The boot partitions can also be locked read only until the next power on, -with: - -echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on - -This is a feature of the card and not of the kernel. If the card does -not support boot partition locking, the file will not exist. If the -feature has been disabled on the card, the file will be read-only. - -The boot partitions can also be locked permanently, but this feature is -not accessible through sysfs in order to avoid accidental or malicious -bricking. |