Diffstat (limited to 'Documentation/mmc')
4 files changed, 0 insertions, 211 deletions
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
deleted file mode 100644
@@ -1,8 +0,0 @@
- - this file
- - info on SD and MMC device attributes
- - info on SD and MMC device partitions
- - 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
@@ -1,87 +0,0 @@
-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 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
-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 */
- * 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.
- /* flush pending desc to the DMAC (dmaengine.h) */
- * 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.
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
deleted file mode 100644
@@ -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
- 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
- "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
@@ -1,40 +0,0 @@
-SD and MMC Device Partitions
-Device partitions are additional logical block devices present on the
-As of this writing, MMC boot partitions as supported and exposed as
-/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
-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
-To enable write access to /dev/mmcblkXbootY, disable the forced read-only
-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,
-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