aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--Documentation/00-INDEX2
-rw-r--r--Documentation/mmc/00-INDEX4
-rw-r--r--Documentation/mmc/mmc-dev-attrs.txt56
-rw-r--r--drivers/mmc/core/core.c346
-rw-r--r--drivers/mmc/core/core.h2
-rw-r--r--drivers/mmc/core/mmc.c47
-rw-r--r--drivers/mmc/core/sd.c82
-rw-r--r--drivers/mmc/core/sd_ops.c48
-rw-r--r--drivers/mmc/core/sd_ops.h1
-rw-r--r--include/linux/mmc/card.h20
-rw-r--r--include/linux/mmc/core.h19
-rw-r--r--include/linux/mmc/host.h1
-rw-r--r--include/linux/mmc/mmc.h26
-rw-r--r--include/linux/mmc/sd.h5
14 files changed, 651 insertions, 8 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 9e642c5bf526..8dfc6708a257 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -232,6 +232,8 @@ memory.txt
232 - info on typical Linux memory problems. 232 - info on typical Linux memory problems.
233mips/ 233mips/
234 - directory with info about Linux on MIPS architecture. 234 - directory with info about Linux on MIPS architecture.
235mmc/
236 - directory with info about the MMC subsystem
235mono.txt 237mono.txt
236 - how to execute Mono-based .NET binaries with the help of BINFMT_MISC. 238 - how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
237mutex-design.txt 239mutex-design.txt
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
new file mode 100644
index 000000000000..fca586f5b853
--- /dev/null
+++ b/Documentation/mmc/00-INDEX
@@ -0,0 +1,4 @@
100-INDEX
2 - this file
3mmc-dev-attrs.txt
4 - info on SD and MMC device attributes
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
new file mode 100644
index 000000000000..ff2bd685bced
--- /dev/null
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -0,0 +1,56 @@
1SD and MMC Device Attributes
2============================
3
4All attributes are read-only.
5
6 cid Card Identifaction Register
7 csd Card Specific Data Register
8 scr SD Card Configuration Register (SD only)
9 date Manufacturing Date (from CID Register)
10 fwrev Firmware/Product Revision (from CID Register) (SD and MMCv1 only)
11 hwrev Hardware/Product Revision (from CID Register) (SD and MMCv1 only)
12 manfid Manufacturer ID (from CID Register)
13 name Product Name (from CID Register)
14 oemid OEM/Application ID (from CID Register)
15 serial Product Serial Number (from CID Register)
16 erase_size Erase group size
17 preferred_erase_size Preferred erase size
18
19Note on Erase Size and Preferred Erase Size:
20
21 "erase_size" is the minimum size, in bytes, of an erase
22 operation. For MMC, "erase_size" is the erase group size
23 reported by the card. Note that "erase_size" does not apply
24 to trim or secure trim operations where the minimum size is
25 always one 512 byte sector. For SD, "erase_size" is 512
26 if the card is block-addressed, 0 otherwise.
27
28 SD/MMC cards can erase an arbitrarily large area up to and
29 including the whole card. When erasing a large area it may
30 be desirable to do it in smaller chunks for three reasons:
31 1. A single erase command will make all other I/O on
32 the card wait. This is not a problem if the whole card
33 is being erased, but erasing one partition will make
34 I/O for another partition on the same card wait for the
35 duration of the erase - which could be a several
36 minutes.
37 2. To be able to inform the user of erase progress.
38 3. The erase timeout becomes too large to be very
39 useful. Because the erase timeout contains a margin
40 which is multiplied by the size of the erase area,
41 the value can end up being several minutes for large
42 areas.
43
44 "erase_size" is not the most efficient unit to erase
45 (especially for SD where it is just one sector),
46 hence "preferred_erase_size" provides a good chunk
47 size for erasing large areas.
48
49 For MMC, "preferred_erase_size" is the high-capacity
50 erase size if a card specifies one, otherwise it is
51 based on the capacity of the card.
52
53 For SD, "preferred_erase_size" is the allocation unit
54 size specified by the card.
55
56 "preferred_erase_size" is in bytes.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 83240faa1dc8..5db49b124ffa 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1050,6 +1050,352 @@ void mmc_detect_change(struct mmc_host *host, unsigned long delay)
1050 1050
1051EXPORT_SYMBOL(mmc_detect_change); 1051EXPORT_SYMBOL(mmc_detect_change);
1052 1052
1053void mmc_init_erase(struct mmc_card *card)
1054{
1055 unsigned int sz;
1056
1057 if (is_power_of_2(card->erase_size))
1058 card->erase_shift = ffs(card->erase_size) - 1;
1059 else
1060 card->erase_shift = 0;
1061
1062 /*
1063 * It is possible to erase an arbitrarily large area of an SD or MMC
1064 * card. That is not desirable because it can take a long time
1065 * (minutes) potentially delaying more important I/O, and also the
1066 * timeout calculations become increasingly hugely over-estimated.
1067 * Consequently, 'pref_erase' is defined as a guide to limit erases
1068 * to that size and alignment.
1069 *
1070 * For SD cards that define Allocation Unit size, limit erases to one
1071 * Allocation Unit at a time. For MMC cards that define High Capacity
1072 * Erase Size, whether it is switched on or not, limit to that size.
1073 * Otherwise just have a stab at a good value. For modern cards it
1074 * will end up being 4MiB. Note that if the value is too small, it
1075 * can end up taking longer to erase.
1076 */
1077 if (mmc_card_sd(card) && card->ssr.au) {
1078 card->pref_erase = card->ssr.au;
1079 card->erase_shift = ffs(card->ssr.au) - 1;
1080 } else if (card->ext_csd.hc_erase_size) {
1081 card->pref_erase = card->ext_csd.hc_erase_size;
1082 } else {
1083 sz = (card->csd.capacity << (card->csd.read_blkbits - 9)) >> 11;
1084 if (sz < 128)
1085 card->pref_erase = 512 * 1024 / 512;
1086 else if (sz < 512)
1087 card->pref_erase = 1024 * 1024 / 512;
1088 else if (sz < 1024)
1089 card->pref_erase = 2 * 1024 * 1024 / 512;
1090 else
1091 card->pref_erase = 4 * 1024 * 1024 / 512;
1092 if (card->pref_erase < card->erase_size)
1093 card->pref_erase = card->erase_size;
1094 else {
1095 sz = card->pref_erase % card->erase_size;
1096 if (sz)
1097 card->pref_erase += card->erase_size - sz;
1098 }
1099 }
1100}
1101
1102static void mmc_set_mmc_erase_timeout(struct mmc_card *card,
1103 struct mmc_command *cmd,
1104 unsigned int arg, unsigned int qty)
1105{
1106 unsigned int erase_timeout;
1107
1108 if (card->ext_csd.erase_group_def & 1) {
1109 /* High Capacity Erase Group Size uses HC timeouts */
1110 if (arg == MMC_TRIM_ARG)
1111 erase_timeout = card->ext_csd.trim_timeout;
1112 else
1113 erase_timeout = card->ext_csd.hc_erase_timeout;
1114 } else {
1115 /* CSD Erase Group Size uses write timeout */
1116 unsigned int mult = (10 << card->csd.r2w_factor);
1117 unsigned int timeout_clks = card->csd.tacc_clks * mult;
1118 unsigned int timeout_us;
1119
1120 /* Avoid overflow: e.g. tacc_ns=80000000 mult=1280 */
1121 if (card->csd.tacc_ns < 1000000)
1122 timeout_us = (card->csd.tacc_ns * mult) / 1000;
1123 else
1124 timeout_us = (card->csd.tacc_ns / 1000) * mult;
1125
1126 /*
1127 * ios.clock is only a target. The real clock rate might be
1128 * less but not that much less, so fudge it by multiplying by 2.
1129 */
1130 timeout_clks <<= 1;
1131 timeout_us += (timeout_clks * 1000) /
1132 (card->host->ios.clock / 1000);
1133
1134 erase_timeout = timeout_us / 1000;
1135
1136 /*
1137 * Theoretically, the calculation could underflow so round up
1138 * to 1ms in that case.
1139 */
1140 if (!erase_timeout)
1141 erase_timeout = 1;
1142