docs: mmc: move it to the driver-api

Most of the stuff here is related to the kAPI.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

5 files changed, 0 insertions, 280 deletions

diff --git a/Documentation/mmc/index.rst b/Documentation/mmc/index.rst
deleted file mode 100644
index 3305478ddadb..000000000000
--- a/Documentation/mmc/index.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-: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
deleted file mode 100644
index 0f7197c9c3b5..000000000000
--- a/Documentation/mmc/mmc-async-req.rst
+++ /dev/null
@@ -1,98 +0,0 @@
-========================
-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-dev-attrs.rst b/Documentation/mmc/mmc-dev-attrs.rst
deleted file mode 100644
index 4f44b1b730d6..000000000000
--- a/Documentation/mmc/mmc-dev-attrs.rst
+++ /dev/null
@@ -1,91 +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
deleted file mode 100644
index 995922f1f744..000000000000
--- a/Documentation/mmc/mmc-dev-parts.rst
+++ /dev/null
@@ -1,41 +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
deleted file mode 100644
index 54406093768b..000000000000
--- a/Documentation/mmc/mmc-tools.rst
+++ /dev/null
@@ -1,37 +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.