From f408510c4ff38965289bb53e8462861ad05dfada Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Date: Thu, 18 Apr 2019 14:44:06 -0300 Subject: docs: mmc: convert to ReST Rename the mmc documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> --- Documentation/mmc/index.rst | 13 +++++ Documentation/mmc/mmc-async-req.rst | 98 +++++++++++++++++++++++++++++++++++++ Documentation/mmc/mmc-async-req.txt | 87 -------------------------------- Documentation/mmc/mmc-dev-attrs.rst | 91 ++++++++++++++++++++++++++++++++++ Documentation/mmc/mmc-dev-attrs.txt | 77 ----------------------------- Documentation/mmc/mmc-dev-parts.rst | 41 ++++++++++++++++ Documentation/mmc/mmc-dev-parts.txt | 40 --------------- Documentation/mmc/mmc-tools.rst | 37 ++++++++++++++ Documentation/mmc/mmc-tools.txt | 34 ------------- 9 files changed, 280 insertions(+), 238 deletions(-) create mode 100644 Documentation/mmc/index.rst create mode 100644 Documentation/mmc/mmc-async-req.rst delete mode 100644 Documentation/mmc/mmc-async-req.txt create mode 100644 Documentation/mmc/mmc-dev-attrs.rst delete mode 100644 Documentation/mmc/mmc-dev-attrs.txt create mode 100644 Documentation/mmc/mmc-dev-parts.rst delete mode 100644 Documentation/mmc/mmc-dev-parts.txt create mode 100644 Documentation/mmc/mmc-tools.rst delete mode 100644 Documentation/mmc/mmc-tools.txt (limited to 'Documentation/mmc') diff --git a/Documentation/mmc/index.rst b/Documentation/mmc/index.rst new file mode 100644 index 000000000000..3305478ddadb --- /dev/null +++ b/Documentation/mmc/index.rst @@ -0,0 +1,13 @@ +:orphan: + +======================== +MMC/SD/SDIO card support +======================== + +.. toctree:: + :maxdepth: 1 + + mmc-dev-attrs + mmc-dev-parts + mmc-async-req + mmc-tools diff --git a/Documentation/mmc/mmc-async-req.rst b/Documentation/mmc/mmc-async-req.rst new file mode 100644 index 000000000000..0f7197c9c3b5 --- /dev/null +++ b/Documentation/mmc/mmc-async-req.rst @@ -0,0 +1,98 @@ +======================== +MMC Asynchronous Request +======================== + +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-async-req.txt b/Documentation/mmc/mmc-async-req.txt deleted file mode 100644 index ae1907b10e4a..000000000000 --- 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.rst b/Documentation/mmc/mmc-dev-attrs.rst new file mode 100644 index 000000000000..4f44b1b730d6 --- /dev/null +++ b/Documentation/mmc/mmc-dev-attrs.rst @@ -0,0 +1,91 @@ +================================== +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 Identification 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) + prv Product Revision (from CID Register) + (SD and MMCv4 only) + serial Product Serial Number (from CID Register) + erase_size Erase group size + preferred_erase_size Preferred erase size + raw_rpmb_size_mult RPMB partition size + rel_sectors Reliable write sector count + ocr Operation Conditions Register + dsr Driver Stage Register + cmdq_en Command Queue enabled: + + 1 => enabled, 0 => not enabled + ====================== =============================================== + +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. + +Note on raw_rpmb_size_mult: + + "raw_rpmb_size_mult" is a multiple of 128kB block. + + RPMB size in byte is calculated by using the following equation: + + RPMB partition size = 128kB x raw_rpmb_size_mult diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt deleted file mode 100644 index 4ad0bb17f343..000000000000 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ /dev/null @@ -1,77 +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 Identification 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) - prv Product Revision (from CID Register) (SD and MMCv4 only) - serial Product Serial Number (from CID Register) - erase_size Erase group size - preferred_erase_size Preferred erase size - raw_rpmb_size_mult RPMB partition size - rel_sectors Reliable write sector count - ocr Operation Conditions Register - dsr Driver Stage Register - cmdq_en Command Queue enabled: 1 => enabled, 0 => not enabled - -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. - -Note on raw_rpmb_size_mult: - "raw_rpmb_size_mult" is a multiple of 128kB block. - RPMB size in byte is calculated by using the following equation: - RPMB partition size = 128kB x raw_rpmb_size_mult diff --git a/Documentation/mmc/mmc-dev-parts.rst b/Documentation/mmc/mmc-dev-parts.rst new file mode 100644 index 000000000000..995922f1f744 --- /dev/null +++ b/Documentation/mmc/mmc-dev-parts.rst @@ -0,0 +1,41 @@ +============================ +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. diff --git a/Documentation/mmc/mmc-dev-parts.txt b/Documentation/mmc/mmc-dev-parts.txt deleted file mode 100644 index f08d078d43cf..000000000000 --- 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. diff --git a/Documentation/mmc/mmc-tools.rst b/Documentation/mmc/mmc-tools.rst new file mode 100644 index 000000000000..54406093768b --- /dev/null +++ b/Documentation/mmc/mmc-tools.rst @@ -0,0 +1,37 @@ +====================== +MMC tools introduction +====================== + +There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, +you can find it at the below public git repository: + + http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + +Functions +========= + +The mmc-utils tools can do the following: + + - Print and parse extcsd data. + - Determine the eMMC writeprotect status. + - Set the eMMC writeprotect status. + - Set the eMMC data sector size to 4KB by disabling emulation. + - Create general purpose partition. + - Enable the enhanced user area. + - Enable write reliability per partition. + - Print the response to STATUS_SEND (CMD13). + - Enable the boot partition. + - Set Boot Bus Conditions. + - Enable the eMMC BKOPS feature. + - Permanently enable the eMMC H/W Reset feature. + - Permanently disable the eMMC H/W Reset feature. + - Send Sanitize command. + - Program authentication key for the device. + - Counter value for the rpmb device will be read to stdout. + - Read from rpmb device to output. + - Write to rpmb device from data file. + - Enable the eMMC cache feature. + - Disable the eMMC cache feature. + - Print and parse CID data. + - Print and parse CSD data. + - Print and parse SCR data. diff --git a/Documentation/mmc/mmc-tools.txt b/Documentation/mmc/mmc-tools.txt deleted file mode 100644 index 735509c165d5..000000000000 --- a/Documentation/mmc/mmc-tools.txt +++ /dev/null @@ -1,34 +0,0 @@ -MMC tools introduction -====================== - -There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, -you can find it at the below public git repository: -http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ - -Functions -========= - -The mmc-utils tools can do the following: - - Print and parse extcsd data. - - Determine the eMMC writeprotect status. - - Set the eMMC writeprotect status. - - Set the eMMC data sector size to 4KB by disabling emulation. - - Create general purpose partition. - - Enable the enhanced user area. - - Enable write reliability per partition. - - Print the response to STATUS_SEND (CMD13). - - Enable the boot partition. - - Set Boot Bus Conditions. - - Enable the eMMC BKOPS feature. - - Permanently enable the eMMC H/W Reset feature. - - Permanently disable the eMMC H/W Reset feature. - - Send Sanitize command. - - Program authentication key for the device. - - Counter value for the rpmb device will be read to stdout. - - Read from rpmb device to output. - - Write to rpmb device from data file. - - Enable the eMMC cache feature. - - Disable the eMMC cache feature. - - Print and parse CID data. - - Print and parse CSD data. - - Print and parse SCR data. -- cgit v1.2.1