2006-12-31 07:11:32 +08:00
|
|
|
/*
|
2007-07-12 02:04:50 +08:00
|
|
|
* linux/drivers/mmc/core/mmc.c
|
2006-12-31 07:11:32 +08:00
|
|
|
*
|
|
|
|
|
* Copyright (C) 2003-2004 Russell King, All Rights Reserved.
|
|
|
|
|
* Copyright (C) 2005-2007 Pierre Ossman, All Rights Reserved.
|
|
|
|
|
* MMCv4 support Copyright (C) 2006 Philip Langdale, All Rights Reserved.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/err.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
#include <linux/mmc/host.h>
|
|
|
|
|
#include <linux/mmc/card.h>
|
|
|
|
|
#include <linux/mmc/mmc.h>
|
|
|
|
|
|
|
|
|
|
#include "core.h"
|
2007-05-19 19:39:01 +08:00
|
|
|
#include "bus.h"
|
2006-12-31 07:11:32 +08:00
|
|
|
#include "mmc_ops.h"
|
|
|
|
|
|
|
|
|
|
static const unsigned int tran_exp[] = {
|
|
|
|
|
10000, 100000, 1000000, 10000000,
|
|
|
|
|
0, 0, 0, 0
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const unsigned char tran_mant[] = {
|
|
|
|
|
0, 10, 12, 13, 15, 20, 25, 30,
|
|
|
|
|
35, 40, 45, 50, 55, 60, 70, 80,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const unsigned int tacc_exp[] = {
|
|
|
|
|
1, 10, 100, 1000, 10000, 100000, 1000000, 10000000,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const unsigned int tacc_mant[] = {
|
|
|
|
|
0, 10, 12, 13, 15, 20, 25, 30,
|
|
|
|
|
35, 40, 45, 50, 55, 60, 70, 80,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define UNSTUFF_BITS(resp,start,size) \
|
|
|
|
|
({ \
|
|
|
|
|
const int __size = size; \
|
|
|
|
|
const u32 __mask = (__size < 32 ? 1 << __size : 0) - 1; \
|
|
|
|
|
const int __off = 3 - ((start) / 32); \
|
|
|
|
|
const int __shft = (start) & 31; \
|
|
|
|
|
u32 __res; \
|
|
|
|
|
\
|
|
|
|
|
__res = resp[__off] >> __shft; \
|
|
|
|
|
if (__size + __shft > 32) \
|
|
|
|
|
__res |= resp[__off-1] << ((32 - __shft) % 32); \
|
|
|
|
|
__res & __mask; \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Given the decoded CSD structure, decode the raw CID to our CID structure.
|
|
|
|
|
*/
|
2007-05-01 22:11:57 +08:00
|
|
|
static int mmc_decode_cid(struct mmc_card *card)
|
2006-12-31 07:11:32 +08:00
|
|
|
{
|
|
|
|
|
u32 *resp = card->raw_cid;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The selection of the format here is based upon published
|
|
|
|
|
* specs from sandisk and from what people have reported.
|
|
|
|
|
*/
|
|
|
|
|
switch (card->csd.mmca_vsn) {
|
|
|
|
|
case 0: /* MMC v1.0 - v1.2 */
|
|
|
|
|
case 1: /* MMC v1.4 */
|
|
|
|
|
card->cid.manfid = UNSTUFF_BITS(resp, 104, 24);
|
|
|
|
|
card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8);
|
|
|
|
|
card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8);
|
|
|
|
|
card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8);
|
|
|
|
|
card->cid.prod_name[3] = UNSTUFF_BITS(resp, 72, 8);
|
|
|
|
|
card->cid.prod_name[4] = UNSTUFF_BITS(resp, 64, 8);
|
|
|
|
|
card->cid.prod_name[5] = UNSTUFF_BITS(resp, 56, 8);
|
|
|
|
|
card->cid.prod_name[6] = UNSTUFF_BITS(resp, 48, 8);
|
|
|
|
|
card->cid.hwrev = UNSTUFF_BITS(resp, 44, 4);
|
|
|
|
|
card->cid.fwrev = UNSTUFF_BITS(resp, 40, 4);
|
|
|
|
|
card->cid.serial = UNSTUFF_BITS(resp, 16, 24);
|
|
|
|
|
card->cid.month = UNSTUFF_BITS(resp, 12, 4);
|
|
|
|
|
card->cid.year = UNSTUFF_BITS(resp, 8, 4) + 1997;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 2: /* MMC v2.0 - v2.2 */
|
|
|
|
|
case 3: /* MMC v3.1 - v3.3 */
|
|
|
|
|
case 4: /* MMC v4 */
|
|
|
|
|
card->cid.manfid = UNSTUFF_BITS(resp, 120, 8);
|
|
|
|
|
card->cid.oemid = UNSTUFF_BITS(resp, 104, 16);
|
|
|
|
|
card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8);
|
|
|
|
|
card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8);
|
|
|
|
|
card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8);
|
|
|
|
|
card->cid.prod_name[3] = UNSTUFF_BITS(resp, 72, 8);
|
|
|
|
|
card->cid.prod_name[4] = UNSTUFF_BITS(resp, 64, 8);
|
|
|
|
|
card->cid.prod_name[5] = UNSTUFF_BITS(resp, 56, 8);
|
|
|
|
|
card->cid.serial = UNSTUFF_BITS(resp, 16, 32);
|
|
|
|
|
card->cid.month = UNSTUFF_BITS(resp, 12, 4);
|
|
|
|
|
card->cid.year = UNSTUFF_BITS(resp, 8, 4) + 1997;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
2007-07-25 03:53:43 +08:00
|
|
|
printk(KERN_ERR "%s: card has unknown MMCA version %d\n",
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_hostname(card->host), card->csd.mmca_vsn);
|
2007-05-01 22:11:57 +08:00
|
|
|
return -EINVAL;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
2007-05-01 22:11:57 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
static void mmc_set_erase_size(struct mmc_card *card)
|
|
|
|
|
{
|
|
|
|
|
if (card->ext_csd.erase_group_def & 1)
|
|
|
|
|
card->erase_size = card->ext_csd.hc_erase_size;
|
|
|
|
|
else
|
|
|
|
|
card->erase_size = card->csd.erase_size;
|
|
|
|
|
|
|
|
|
|
mmc_init_erase(card);
|
|
|
|
|
}
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* Given a 128-bit response, decode to our card CSD structure.
|
|
|
|
|
*/
|
2007-05-01 22:11:57 +08:00
|
|
|
static int mmc_decode_csd(struct mmc_card *card)
|
2006-12-31 07:11:32 +08:00
|
|
|
{
|
|
|
|
|
struct mmc_csd *csd = &card->csd;
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
unsigned int e, m, a, b;
|
2006-12-31 07:11:32 +08:00
|
|
|
u32 *resp = card->raw_csd;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We only understand CSD structure v1.1 and v1.2.
|
|
|
|
|
* v1.2 has extra information in bits 15, 11 and 10.
|
2010-08-11 09:01:36 +08:00
|
|
|
* We also support eMMC v4.4 & v4.41.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
2010-08-11 09:01:36 +08:00
|
|
|
csd->structure = UNSTUFF_BITS(resp, 126, 2);
|
|
|
|
|
if (csd->structure == 0) {
|
2007-07-25 03:53:43 +08:00
|
|
|
printk(KERN_ERR "%s: unrecognised CSD structure version %d\n",
|
2010-08-11 09:01:36 +08:00
|
|
|
mmc_hostname(card->host), csd->structure);
|
2007-05-01 22:11:57 +08:00
|
|
|
return -EINVAL;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
csd->mmca_vsn = UNSTUFF_BITS(resp, 122, 4);
|
|
|
|
|
m = UNSTUFF_BITS(resp, 115, 4);
|
|
|
|
|
e = UNSTUFF_BITS(resp, 112, 3);
|
|
|
|
|
csd->tacc_ns = (tacc_exp[e] * tacc_mant[m] + 9) / 10;
|
|
|
|
|
csd->tacc_clks = UNSTUFF_BITS(resp, 104, 8) * 100;
|
|
|
|
|
|
|
|
|
|
m = UNSTUFF_BITS(resp, 99, 4);
|
|
|
|
|
e = UNSTUFF_BITS(resp, 96, 3);
|
|
|
|
|
csd->max_dtr = tran_exp[e] * tran_mant[m];
|
|
|
|
|
csd->cmdclass = UNSTUFF_BITS(resp, 84, 12);
|
|
|
|
|
|
|
|
|
|
e = UNSTUFF_BITS(resp, 47, 3);
|
|
|
|
|
m = UNSTUFF_BITS(resp, 62, 12);
|
|
|
|
|
csd->capacity = (1 + m) << (e + 2);
|
|
|
|
|
|
|
|
|
|
csd->read_blkbits = UNSTUFF_BITS(resp, 80, 4);
|
|
|
|
|
csd->read_partial = UNSTUFF_BITS(resp, 79, 1);
|
|
|
|
|
csd->write_misalign = UNSTUFF_BITS(resp, 78, 1);
|
|
|
|
|
csd->read_misalign = UNSTUFF_BITS(resp, 77, 1);
|
|
|
|
|
csd->r2w_factor = UNSTUFF_BITS(resp, 26, 3);
|
|
|
|
|
csd->write_blkbits = UNSTUFF_BITS(resp, 22, 4);
|
|
|
|
|
csd->write_partial = UNSTUFF_BITS(resp, 21, 1);
|
2007-05-01 22:11:57 +08:00
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
if (csd->write_blkbits >= 9) {
|
|
|
|
|
a = UNSTUFF_BITS(resp, 42, 5);
|
|
|
|
|
b = UNSTUFF_BITS(resp, 37, 5);
|
|
|
|
|
csd->erase_size = (a + 1) * (b + 1);
|
|
|
|
|
csd->erase_size <<= csd->write_blkbits - 9;
|
|
|
|
|
}
|
|
|
|
|
|
2007-05-01 22:11:57 +08:00
|
|
|
return 0;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2007-05-01 21:08:30 +08:00
|
|
|
* Read and decode extended CSD.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
2007-05-01 21:08:30 +08:00
|
|
|
static int mmc_read_ext_csd(struct mmc_card *card)
|
2006-12-31 07:11:32 +08:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
u8 *ext_csd;
|
|
|
|
|
|
|
|
|
|
BUG_ON(!card);
|
|
|
|
|
|
|
|
|
|
if (card->csd.mmca_vsn < CSD_SPEC_VER_4)
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* As the ext_csd is so large and mostly unused, we don't store the
|
|
|
|
|
* raw block in mmc_card.
|
|
|
|
|
*/
|
|
|
|
|
ext_csd = kmalloc(512, GFP_KERNEL);
|
|
|
|
|
if (!ext_csd) {
|
|
|
|
|
printk(KERN_ERR "%s: could not allocate a buffer to "
|
2007-07-23 05:08:30 +08:00
|
|
|
"receive the ext_csd.\n", mmc_hostname(card->host));
|
2007-07-23 04:18:46 +08:00
|
|
|
return -ENOMEM;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = mmc_send_ext_csd(card, ext_csd);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err) {
|
2009-09-23 07:45:26 +08:00
|
|
|
/* If the host or the card can't do the switch,
|
|
|
|
|
* fail more gracefully. */
|
|
|
|
|
if ((err != -EINVAL)
|
|
|
|
|
&& (err != -ENOSYS)
|
|
|
|
|
&& (err != -EFAULT))
|
2007-07-23 05:08:30 +08:00
|
|
|
goto out;
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* High capacity cards should have this "magic" size
|
|
|
|
|
* stored in their CSD.
|
|
|
|
|
*/
|
|
|
|
|
if (card->csd.capacity == (4096 * 512)) {
|
|
|
|
|
printk(KERN_ERR "%s: unable to read EXT_CSD "
|
|
|
|
|
"on a possible high capacity card. "
|
|
|
|
|
"Card will be ignored.\n",
|
|
|
|
|
mmc_hostname(card->host));
|
|
|
|
|
} else {
|
|
|
|
|
printk(KERN_WARNING "%s: unable to read "
|
|
|
|
|
"EXT_CSD, performance might "
|
|
|
|
|
"suffer.\n",
|
|
|
|
|
mmc_hostname(card->host));
|
2007-07-23 04:18:46 +08:00
|
|
|
err = 0;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
2007-07-23 05:08:30 +08:00
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 09:01:36 +08:00
|
|
|
/* Version is coded in the CSD_STRUCTURE byte in the EXT_CSD register */
|
|
|
|
|
if (card->csd.structure == 3) {
|
|
|
|
|
int ext_csd_struct = ext_csd[EXT_CSD_STRUCTURE];
|
|
|
|
|
if (ext_csd_struct > 2) {
|
|
|
|
|
printk(KERN_ERR "%s: unrecognised EXT_CSD structure "
|
|
|
|
|
"version %d\n", mmc_hostname(card->host),
|
|
|
|
|
ext_csd_struct);
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-23 07:44:34 +08:00
|
|
|
card->ext_csd.rev = ext_csd[EXT_CSD_REV];
|
2010-01-09 06:43:01 +08:00
|
|
|
if (card->ext_csd.rev > 5) {
|
2010-08-11 09:01:36 +08:00
|
|
|
printk(KERN_ERR "%s: unrecognised EXT_CSD revision %d\n",
|
|
|
|
|
mmc_hostname(card->host), card->ext_csd.rev);
|
2007-10-14 00:27:20 +08:00
|
|
|
err = -EINVAL;
|
|
|
|
|
goto out;
|
2007-07-23 06:34:07 +08:00
|
|
|
}
|
|
|
|
|
|
2009-09-23 07:44:34 +08:00
|
|
|
if (card->ext_csd.rev >= 2) {
|
2007-07-23 06:34:07 +08:00
|
|
|
card->ext_csd.sectors =
|
|
|
|
|
ext_csd[EXT_CSD_SEC_CNT + 0] << 0 |
|
|
|
|
|
ext_csd[EXT_CSD_SEC_CNT + 1] << 8 |
|
|
|
|
|
ext_csd[EXT_CSD_SEC_CNT + 2] << 16 |
|
|
|
|
|
ext_csd[EXT_CSD_SEC_CNT + 3] << 24;
|
2010-08-11 09:01:45 +08:00
|
|
|
|
|
|
|
|
/* Cards with density > 2GiB are sector addressed */
|
|
|
|
|
if (card->ext_csd.sectors > (2u * 1024 * 1024 * 1024) / 512)
|
2007-07-23 06:34:07 +08:00
|
|
|
mmc_card_set_blockaddr(card);
|
|
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2010-03-24 04:35:40 +08:00
|
|
|
switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
|
2010-10-01 05:37:23 +08:00
|
|
|
case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
|
|
|
|
|
EXT_CSD_CARD_TYPE_26:
|
|
|
|
|
card->ext_csd.hs_max_dtr = 52000000;
|
|
|
|
|
card->ext_csd.card_type = EXT_CSD_CARD_TYPE_DDR_52;
|
|
|
|
|
break;
|
|
|
|
|
case EXT_CSD_CARD_TYPE_DDR_1_2V | EXT_CSD_CARD_TYPE_52 |
|
|
|
|
|
EXT_CSD_CARD_TYPE_26:
|
|
|
|
|
card->ext_csd.hs_max_dtr = 52000000;
|
|
|
|
|
card->ext_csd.card_type = EXT_CSD_CARD_TYPE_DDR_1_2V;
|
|
|
|
|
break;
|
|
|
|
|
case EXT_CSD_CARD_TYPE_DDR_1_8V | EXT_CSD_CARD_TYPE_52 |
|
|
|
|
|
EXT_CSD_CARD_TYPE_26:
|
|
|
|
|
card->ext_csd.hs_max_dtr = 52000000;
|
|
|
|
|
card->ext_csd.card_type = EXT_CSD_CARD_TYPE_DDR_1_8V;
|
|
|
|
|
break;
|
2006-12-31 07:11:32 +08:00
|
|
|
case EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
|
|
|
|
|
card->ext_csd.hs_max_dtr = 52000000;
|
|
|
|
|
break;
|
|
|
|
|
case EXT_CSD_CARD_TYPE_26:
|
|
|
|
|
card->ext_csd.hs_max_dtr = 26000000;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* MMC v4 spec says this cannot happen */
|
|
|
|
|
printk(KERN_WARNING "%s: card is mmc v4 but doesn't "
|
|
|
|
|
"support any high-speed modes.\n",
|
|
|
|
|
mmc_hostname(card->host));
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-23 07:44:34 +08:00
|
|
|
if (card->ext_csd.rev >= 3) {
|
|
|
|
|
u8 sa_shift = ext_csd[EXT_CSD_S_A_TIMEOUT];
|
2011-03-20 02:10:33 +08:00
|
|
|
card->ext_csd.bootconfig = ext_csd[EXT_CSD_BOOT_CONFIG];
|
2009-09-23 07:44:34 +08:00
|
|
|
|
|
|
|
|
/* Sleep / awake timeout in 100ns units */
|
|
|
|
|
if (sa_shift > 0 && sa_shift <= 0x17)
|
|
|
|
|
card->ext_csd.sa_timeout =
|
|
|
|
|
1 << ext_csd[EXT_CSD_S_A_TIMEOUT];
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
card->ext_csd.erase_group_def =
|
|
|
|
|
ext_csd[EXT_CSD_ERASE_GROUP_DEF];
|
|
|
|
|
card->ext_csd.hc_erase_timeout = 300 *
|
|
|
|
|
ext_csd[EXT_CSD_ERASE_TIMEOUT_MULT];
|
|
|
|
|
card->ext_csd.hc_erase_size =
|
|
|
|
|
ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 10;
|
2011-04-01 07:40:00 +08:00
|
|
|
|
|
|
|
|
card->ext_csd.rel_sectors = ext_csd[EXT_CSD_REL_WR_SEC_C];
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (card->ext_csd.rev >= 4) {
|
2011-01-22 04:09:41 +08:00
|
|
|
/*
|
|
|
|
|
* Enhanced area feature support -- check whether the eMMC
|
|
|
|
|
* card has the Enhanced area enabled. If so, export enhanced
|
|
|
|
|
* area offset and size to user by adding sysfs interface.
|
|
|
|
|
*/
|
|
|
|
|
if ((ext_csd[EXT_CSD_PARTITION_SUPPORT] & 0x2) &&
|
|
|
|
|
(ext_csd[EXT_CSD_PARTITION_ATTRIBUTE] & 0x1)) {
|
|
|
|
|
u8 hc_erase_grp_sz =
|
|
|
|
|
ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE];
|
|
|
|
|
u8 hc_wp_grp_sz =
|
|
|
|
|
ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
|
|
|
|
|
|
|
|
|
|
card->ext_csd.enhanced_area_en = 1;
|
|
|
|
|
/*
|
|
|
|
|
* calculate the enhanced data area offset, in bytes
|
|
|
|
|
*/
|
|
|
|
|
card->ext_csd.enhanced_area_offset =
|
|
|
|
|
(ext_csd[139] << 24) + (ext_csd[138] << 16) +
|
|
|
|
|
(ext_csd[137] << 8) + ext_csd[136];
|
|
|
|
|
if (mmc_card_blockaddr(card))
|
|
|
|
|
card->ext_csd.enhanced_area_offset <<= 9;
|
|
|
|
|
/*
|
|
|
|
|
* calculate the enhanced data area size, in kilobytes
|
|
|
|
|
*/
|
|
|
|
|
card->ext_csd.enhanced_area_size =
|
|
|
|
|
(ext_csd[142] << 16) + (ext_csd[141] << 8) +
|
|
|
|
|
ext_csd[140];
|
|
|
|
|
card->ext_csd.enhanced_area_size *=
|
|
|
|
|
(size_t)(hc_erase_grp_sz * hc_wp_grp_sz);
|
|
|
|
|
card->ext_csd.enhanced_area_size <<= 9;
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* If the enhanced area is not enabled, disable these
|
|
|
|
|
* device attributes.
|
|
|
|
|
*/
|
|
|
|
|
card->ext_csd.enhanced_area_offset = -EINVAL;
|
|
|
|
|
card->ext_csd.enhanced_area_size = -EINVAL;
|
|
|
|
|
}
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
card->ext_csd.sec_trim_mult =
|
|
|
|
|
ext_csd[EXT_CSD_SEC_TRIM_MULT];
|
|
|
|
|
card->ext_csd.sec_erase_mult =
|
|
|
|
|
ext_csd[EXT_CSD_SEC_ERASE_MULT];
|
|
|
|
|
card->ext_csd.sec_feature_support =
|
|
|
|
|
ext_csd[EXT_CSD_SEC_FEATURE_SUPPORT];
|
|
|
|
|
card->ext_csd.trim_timeout = 300 *
|
|
|
|
|
ext_csd[EXT_CSD_TRIM_MULT];
|
2009-09-23 07:44:34 +08:00
|
|
|
}
|
|
|
|
|
|
2011-04-01 07:40:00 +08:00
|
|
|
if (card->ext_csd.rev >= 5)
|
|
|
|
|
card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
|
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
|
|
|
|
|
card->erased_byte = 0xFF;
|
|
|
|
|
else
|
|
|
|
|
card->erased_byte = 0x0;
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
out:
|
|
|
|
|
kfree(ext_csd);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2008-03-22 06:54:50 +08:00
|
|
|
MMC_DEV_ATTR(cid, "%08x%08x%08x%08x\n", card->raw_cid[0], card->raw_cid[1],
|
|
|
|
|
card->raw_cid[2], card->raw_cid[3]);
|
|
|
|
|
MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
|
|
|
|
|
card->raw_csd[2], card->raw_csd[3]);
|
|
|
|
|
MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
|
|
|
|
|
MMC_DEV_ATTR(preferred_erase_size, "%u\n", card->pref_erase << 9);
|
2008-03-22 06:54:50 +08:00
|
|
|
MMC_DEV_ATTR(fwrev, "0x%x\n", card->cid.fwrev);
|
|
|
|
|
MMC_DEV_ATTR(hwrev, "0x%x\n", card->cid.hwrev);
|
|
|
|
|
MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
|
|
|
|
|
MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
|
|
|
|
|
MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
|
|
|
|
|
MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial);
|
2011-01-22 04:09:41 +08:00
|
|
|
MMC_DEV_ATTR(enhanced_area_offset, "%llu\n",
|
|
|
|
|
card->ext_csd.enhanced_area_offset);
|
|
|
|
|
MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size);
|
2008-03-22 06:54:50 +08:00
|
|
|
|
|
|
|
|
static struct attribute *mmc_std_attrs[] = {
|
|
|
|
|
&dev_attr_cid.attr,
|
|
|
|
|
&dev_attr_csd.attr,
|
|
|
|
|
&dev_attr_date.attr,
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
&dev_attr_erase_size.attr,
|
|
|
|
|
&dev_attr_preferred_erase_size.attr,
|
2008-03-22 06:54:50 +08:00
|
|
|
&dev_attr_fwrev.attr,
|
|
|
|
|
&dev_attr_hwrev.attr,
|
|
|
|
|
&dev_attr_manfid.attr,
|
|
|
|
|
&dev_attr_name.attr,
|
|
|
|
|
&dev_attr_oemid.attr,
|
|
|
|
|
&dev_attr_serial.attr,
|
2011-01-22 04:09:41 +08:00
|
|
|
&dev_attr_enhanced_area_offset.attr,
|
|
|
|
|
&dev_attr_enhanced_area_size.attr,
|
2008-03-22 06:54:50 +08:00
|
|
|
NULL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct attribute_group mmc_std_attr_group = {
|
|
|
|
|
.attrs = mmc_std_attrs,
|
|
|
|
|
};
|
|
|
|
|
|
2009-06-25 01:06:31 +08:00
|
|
|
static const struct attribute_group *mmc_attr_groups[] = {
|
2008-03-22 06:54:50 +08:00
|
|
|
&mmc_std_attr_group,
|
|
|
|
|
NULL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct device_type mmc_type = {
|
|
|
|
|
.groups = mmc_attr_groups,
|
|
|
|
|
};
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
2007-05-01 22:00:02 +08:00
|
|
|
* Handle the detection and initialisation of a card.
|
|
|
|
|
*
|
2008-06-17 10:20:57 +08:00
|
|
|
* In the case of a resume, "oldcard" will contain the card
|
2007-05-01 22:00:02 +08:00
|
|
|
* we're trying to reinitialise.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
2007-05-19 22:14:43 +08:00
|
|
|
static int mmc_init_card(struct mmc_host *host, u32 ocr,
|
2007-05-01 22:00:02 +08:00
|
|
|
struct mmc_card *oldcard)
|
2006-12-31 07:11:32 +08:00
|
|
|
{
|
|
|
|
|
struct mmc_card *card;
|
2010-11-08 05:22:28 +08:00
|
|
|
int err, ddr = 0;
|
2006-12-31 07:11:32 +08:00
|
|
|
u32 cid[4];
|
|
|
|
|
unsigned int max_dtr;
|
2011-02-14 15:13:09 +08:00
|
|
|
u32 rocr;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
BUG_ON(!host);
|
2007-08-09 19:23:56 +08:00
|
|
|
WARN_ON(!host->claimed);
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Since we're changing the OCR value, we seem to
|
|
|
|
|
* need to tell some cards to go back to the idle
|
|
|
|
|
* state. We wait 1ms to give cards time to
|
|
|
|
|
* respond.
|
|
|
|
|
*/
|
|
|
|
|
mmc_go_idle(host);
|
|
|
|
|
|
|
|
|
|
/* The extra bit indicates that we support high capacity */
|
2011-02-14 15:13:09 +08:00
|
|
|
err = mmc_send_op_cond(host, ocr | (1 << 30), &rocr);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2007-05-01 22:00:02 +08:00
|
|
|
goto err;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* For SPI, enable CRC as appropriate.
|
|
|
|
|
*/
|
|
|
|
|
if (mmc_host_is_spi(host)) {
|
|
|
|
|
err = mmc_spi_set_crc(host, use_spi_crc);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* Fetch CID from card.
|
|
|
|
|
*/
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
if (mmc_host_is_spi(host))
|
|
|
|
|
err = mmc_send_cid(host, cid);
|
|
|
|
|
else
|
|
|
|
|
err = mmc_all_send_cid(host, cid);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2006-12-31 07:11:32 +08:00
|
|
|
goto err;
|
|
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
if (oldcard) {
|
2007-07-23 05:08:30 +08:00
|
|
|
if (memcmp(cid, oldcard->raw_cid, sizeof(cid)) != 0) {
|
|
|
|
|
err = -ENOENT;
|
2007-05-01 22:00:02 +08:00
|
|
|
goto err;
|
2007-07-23 05:08:30 +08:00
|
|
|
}
|
2007-05-01 22:00:02 +08:00
|
|
|
|
|
|
|
|
card = oldcard;
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* Allocate card structure.
|
|
|
|
|
*/
|
2008-03-22 06:54:50 +08:00
|
|
|
card = mmc_alloc_card(host, &mmc_type);
|
2007-07-23 05:08:30 +08:00
|
|
|
if (IS_ERR(card)) {
|
|
|
|
|
err = PTR_ERR(card);
|
2007-05-01 22:00:02 +08:00
|
|
|
goto err;
|
2007-07-23 05:08:30 +08:00
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
card->type = MMC_TYPE_MMC;
|
|
|
|
|
card->rca = 1;
|
|
|
|
|
memcpy(card->raw_cid, cid, sizeof(card->raw_cid));
|
|
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
/*
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
* For native busses: set card RCA and quit open drain mode.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
if (!mmc_host_is_spi(host)) {
|
|
|
|
|
err = mmc_set_relative_addr(card);
|
|
|
|
|
if (err)
|
|
|
|
|
goto free_card;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
mmc_set_bus_mode(host, MMC_BUSMODE_PUSHPULL);
|
|
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
if (!oldcard) {
|
|
|
|
|
/*
|
|
|
|
|
* Fetch CSD from card.
|
|
|
|
|
*/
|
|
|
|
|
err = mmc_send_csd(card, card->raw_csd);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2007-05-01 22:00:02 +08:00
|
|
|
goto free_card;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:11:57 +08:00
|
|
|
err = mmc_decode_csd(card);
|
2007-07-23 05:08:30 +08:00
|
|
|
if (err)
|
2007-05-01 22:11:57 +08:00
|
|
|
goto free_card;
|
|
|
|
|
err = mmc_decode_cid(card);
|
2007-07-23 05:08:30 +08:00
|
|
|
if (err)
|
2007-05-01 22:11:57 +08:00
|
|
|
goto free_card;
|
2007-05-01 22:00:02 +08:00
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
/*
|
2007-05-01 21:08:30 +08:00
|
|
|
* Select card, as all following commands rely on that.
|
2006-12-31 07:11:32 +08:00
|
|
|
*/
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
if (!mmc_host_is_spi(host)) {
|
|
|
|
|
err = mmc_select_card(card);
|
|
|
|
|
if (err)
|
|
|
|
|
goto free_card;
|
|
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
if (!oldcard) {
|
|
|
|
|
/*
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
* Fetch and process extended CSD.
|
2007-05-01 22:00:02 +08:00
|
|
|
*/
|
|
|
|
|
err = mmc_read_ext_csd(card);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2007-05-01 22:00:02 +08:00
|
|
|
goto free_card;
|
2011-02-14 15:13:09 +08:00
|
|
|
|
|
|
|
|
/* If doing byte addressing, check if required to do sector
|
|
|
|
|
* addressing. Handle the case of <2GB cards needing sector
|
|
|
|
|
* addressing. See section 8.1 JEDEC Standard JED84-A441;
|
|
|
|
|
* ocr register has bit 30 set for sector addressing.
|
|
|
|
|
*/
|
|
|
|
|
if (!(mmc_card_blockaddr(card)) && (rocr & (1<<30)))
|
|
|
|
|
mmc_card_set_blockaddr(card);
|
|
|
|
|
|
mmc: add erase, secure erase, trim and secure trim operations
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.
SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.
"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.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Kyungmin Park <kmpark@infradead.org>
Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-08-12 05:17:46 +08:00
|
|
|
/* Erase size depends on CSD and Extended CSD */
|
|
|
|
|
mmc_set_erase_size(card);
|
2007-05-01 22:00:02 +08:00
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2011-01-22 04:09:41 +08:00
|
|
|
/*
|
|
|
|
|
* If enhanced_area_en is TRUE, host needs to enable ERASE_GRP_DEF
|
2011-03-31 09:57:33 +08:00
|
|
|
* bit. This bit will be lost every time after a reset or power off.
|
2011-01-22 04:09:41 +08:00
|
|
|
*/
|
|
|
|
|
if (card->ext_csd.enhanced_area_en) {
|
|
|
|
|
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
|
2011-04-12 05:13:43 +08:00
|
|
|
EXT_CSD_ERASE_GROUP_DEF, 1, 0);
|
2011-01-22 04:09:41 +08:00
|
|
|
|
|
|
|
|
if (err && err != -EBADMSG)
|
|
|
|
|
goto free_card;
|
|
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
|
err = 0;
|
|
|
|
|
/*
|
|
|
|
|
* Just disable enhanced area off & sz
|
|
|
|
|
* will try to enable ERASE_GROUP_DEF
|
|
|
|
|
* during next time reinit
|
|
|
|
|
*/
|
|
|
|
|
card->ext_csd.enhanced_area_offset = -EINVAL;
|
|
|
|
|
card->ext_csd.enhanced_area_size = -EINVAL;
|
|
|
|
|
} else {
|
|
|
|
|
card->ext_csd.erase_group_def = 1;
|
|
|
|
|
/*
|
|
|
|
|
* enable ERASE_GRP_DEF successfully.
|
|
|
|
|
* This will affect the erase size, so
|
|
|
|
|
* here need to reset erase size
|
|
|
|
|
*/
|
|
|
|
|
mmc_set_erase_size(card);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-20 02:10:33 +08:00
|
|
|
/*
|
|
|
|
|
* Ensure eMMC user default partition is enabled
|
|
|
|
|
*/
|
|
|
|
|
if (card->ext_csd.bootconfig & 0x7) {
|
|
|
|
|
card->ext_csd.bootconfig &= ~0x7;
|
|
|
|
|
mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_CONFIG,
|
2011-04-12 05:13:43 +08:00
|
|
|
card->ext_csd.bootconfig, 0);
|
2011-03-20 02:10:33 +08:00
|
|
|
}
|
|
|
|
|
|
2007-05-01 21:08:30 +08:00
|
|
|
/*
|
|
|
|
|
* Activate high speed (if supported)
|
|
|
|
|
*/
|
|
|
|
|
if ((card->ext_csd.hs_max_dtr != 0) &&
|
|
|
|
|
(host->caps & MMC_CAP_MMC_HIGHSPEED)) {
|
|
|
|
|
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
|
2011-04-12 05:13:43 +08:00
|
|
|
EXT_CSD_HS_TIMING, 1, 0);
|
2009-09-23 07:44:37 +08:00
|
|
|
if (err && err != -EBADMSG)
|
2007-05-01 21:08:30 +08:00
|
|
|
goto free_card;
|
|
|
|
|
|
2009-09-23 07:44:37 +08:00
|
|
|
if (err) {
|
|
|
|
|
printk(KERN_WARNING "%s: switch to highspeed failed\n",
|
|
|
|
|
mmc_hostname(card->host));
|
|
|
|
|
err = 0;
|
|
|
|
|
} else {
|
|
|
|
|
mmc_card_set_highspeed(card);
|
|
|
|
|
mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
|
|
|
|
|
}
|
2007-05-01 21:08:30 +08:00
|
|
|
}
|
|
|
|
|
|
2006-12-31 07:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* Compute bus speed.
|
|
|
|
|
*/
|
|
|
|
|
max_dtr = (unsigned int)-1;
|
|
|
|
|
|
|
|
|
|
if (mmc_card_highspeed(card)) {
|
|
|
|
|
if (max_dtr > card->ext_csd.hs_max_dtr)
|
|
|
|
|
max_dtr = card->ext_csd.hs_max_dtr;
|
|
|
|
|
} else if (max_dtr > card->csd.max_dtr) {
|
|
|
|
|
max_dtr = card->csd.max_dtr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mmc_set_clock(host, max_dtr);
|
|
|
|
|
|
2010-10-01 05:37:23 +08:00
|
|
|
/*
|
2010-08-24 18:20:26 +08:00
|
|
|
* Indicate DDR mode (if supported).
|
2010-10-01 05:37:23 +08:00
|
|
|
*/
|
|
|
|
|
if (mmc_card_highspeed(card)) {
|
|
|
|
|
if ((card->ext_csd.card_type & EXT_CSD_CARD_TYPE_DDR_1_8V)
|
|
|
|
|
&& (host->caps & (MMC_CAP_1_8V_DDR)))
|
2010-10-11 17:43:50 +08:00
|
|
|
ddr = MMC_1_8V_DDR_MODE;
|
2010-10-01 05:37:23 +08:00
|
|
|
else if ((card->ext_csd.card_type & EXT_CSD_CARD_TYPE_DDR_1_2V)
|
|
|
|
|
&& (host->caps & (MMC_CAP_1_2V_DDR)))
|
2010-10-11 17:43:50 +08:00
|
|
|
ddr = MMC_1_2V_DDR_MODE;
|
2010-10-01 05:37:23 +08:00
|
|
|
}
|
|
|
|
|
|
2007-05-01 21:08:30 +08:00
|
|
|
/*
|
2010-08-24 18:20:26 +08:00
|
|
|
* Activate wide bus and DDR (if supported).
|
2007-05-01 21:08:30 +08:00
|
|
|
*/
|
|
|
|
|
if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
|
2008-11-17 20:35:21 +08:00
|
|
|
(host->caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
|
2010-12-15 15:14:24 +08:00
|
|
|
static unsigned ext_csd_bits[][2] = {
|
|
|
|
|
{ EXT_CSD_BUS_WIDTH_8, EXT_CSD_DDR_BUS_WIDTH_8 },
|
|
|
|
|
{ EXT_CSD_BUS_WIDTH_4, EXT_CSD_DDR_BUS_WIDTH_4 },
|
|
|
|
|
{ EXT_CSD_BUS_WIDTH_1, EXT_CSD_BUS_WIDTH_1 },
|
|
|
|
|
};
|
|
|
|
|
static unsigned bus_widths[] = {
|
|
|
|
|
MMC_BUS_WIDTH_8,
|
|
|
|
|
MMC_BUS_WIDTH_4,
|
|
|
|
|
MMC_BUS_WIDTH_1
|
|
|
|
|
};
|
|
|
|
|
unsigned idx, bus_width = 0;
|
|
|
|
|
|
|
|
|
|
if (host->caps & MMC_CAP_8_BIT_DATA)
|
|
|
|
|
idx = 0;
|
|
|
|
|
else
|
|
|
|
|
idx = 1;
|
|
|
|
|
for (; idx < ARRAY_SIZE(bus_widths); idx++) {
|
|
|
|
|
bus_width = bus_widths[idx];
|
|
|
|
|
if (bus_width == MMC_BUS_WIDTH_1)
|
|
|
|
|
ddr = 0; /* no DDR for 1-bit width */
|
|
|
|
|
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
|
|
|
|
|
EXT_CSD_BUS_WIDTH,
|
2011-04-12 05:13:43 +08:00
|
|
|
ext_csd_bits[idx][0],
|
|
|
|
|
0);
|
2010-12-15 15:14:24 +08:00
|
|
|
if (!err) {
|
2010-12-22 16:59:44 +08:00
|
|
|
mmc_set_bus_width_ddr(card->host,
|
|
|
|
|
bus_width, MMC_SDR_MODE);
|
2010-12-15 15:14:24 +08:00
|
|
|
/*
|
|
|
|
|
* If controller can't handle bus width test,
|
|
|
|
|
* use the highest bus width to maintain
|
|
|
|
|
* compatibility with previous MMC behavior.
|
|
|
|
|
*/
|
|
|
|
|
if (!(host->caps & MMC_CAP_BUS_WIDTH_TEST))
|
|
|
|
|
break;
|
|
|
|
|
err = mmc_bus_test(card, bus_width);
|
|
|
|
|
if (!err)
|
|
|
|
|
break;
|
|
|
|
|
}
|
2008-11-17 20:35:21 +08:00
|
|
|
}
|
|
|
|
|
|
2010-12-15 15:14:24 +08:00
|
|
|
if (!err && ddr) {
|
|
|
|
|
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
|
2011-04-12 05:13:43 +08:00
|
|
|
EXT_CSD_BUS_WIDTH,
|
|
|
|
|
ext_csd_bits[idx][1],
|
|
|
|
|
0);
|
2010-12-15 15:14:24 +08:00
|
|
|
}
|
2009-09-23 07:44:37 +08:00
|
|
|
if (err) {
|
2010-08-24 18:20:26 +08:00
|
|
|
printk(KERN_WARNING "%s: switch to bus width %d ddr %d "
|
2010-12-15 15:14:24 +08:00
|
|
|
"failed\n", mmc_hostname(card->host),
|
|
|
|
|
1 << bus_width, ddr);
|
|
|
|
|
goto free_card;
|
|
|
|
|
} else if (ddr) {
|
|
|
|
|
mmc_card_set_ddr_mode(card);
|
2010-08-24 18:20:26 +08:00
|
|
|
mmc_set_bus_width_ddr(card->host, bus_width, ddr);
|
2009-09-23 07:44:37 +08:00
|
|
|
}
|
2007-05-01 21:08:30 +08:00
|
|
|
}
|
|
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
if (!oldcard)
|
|
|
|
|
host->card = card;
|
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
return 0;
|
2007-05-01 22:00:02 +08:00
|
|
|
|
|
|
|
|
free_card:
|
|
|
|
|
if (!oldcard)
|
|
|
|
|
mmc_remove_card(card);
|
|
|
|
|
err:
|
|
|
|
|
|
2007-07-23 05:08:30 +08:00
|
|
|
return err;
|
2007-05-01 22:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Host is being removed. Free up the current card.
|
|
|
|
|
*/
|
|
|
|
|
static void mmc_remove(struct mmc_host *host)
|
|
|
|
|
{
|
|
|
|
|
BUG_ON(!host);
|
|
|
|
|
BUG_ON(!host->card);
|
|
|
|
|
|
|
|
|
|
mmc_remove_card(host->card);
|
|
|
|
|
host->card = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Card detection callback from host.
|
|
|
|
|
*/
|
|
|
|
|
static void mmc_detect(struct mmc_host *host)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
BUG_ON(!host);
|
|
|
|
|
BUG_ON(!host->card);
|
|
|
|
|
|
|
|
|
|
mmc_claim_host(host);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Just check if our card has been removed.
|
|
|
|
|
*/
|
|
|
|
|
err = mmc_send_status(host->card, NULL);
|
|
|
|
|
|
|
|
|
|
mmc_release_host(host);
|
|
|
|
|
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err) {
|
2007-05-19 19:39:01 +08:00
|
|
|
mmc_remove(host);
|
2007-05-01 22:00:02 +08:00
|
|
|
|
|
|
|
|
mmc_claim_host(host);
|
|
|
|
|
mmc_detach_bus(host);
|
|
|
|
|
mmc_release_host(host);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Suspend callback from host.
|
|
|
|
|
*/
|
2009-09-23 07:45:29 +08:00
|
|
|
static int mmc_suspend(struct mmc_host *host)
|
2007-05-01 22:00:02 +08:00
|
|
|
{
|
|
|
|
|
BUG_ON(!host);
|
|
|
|
|
BUG_ON(!host->card);
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
mmc_claim_host(host);
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
if (!mmc_host_is_spi(host))
|
|
|
|
|
mmc_deselect_cards(host);
|
2007-05-01 22:00:02 +08:00
|
|
|
host->card->state &= ~MMC_STATE_HIGHSPEED;
|
2006-12-31 07:11:32 +08:00
|
|
|
mmc_release_host(host);
|
2009-09-23 07:45:29 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2007-05-01 22:00:02 +08:00
|
|
|
}
|
2006-12-31 07:11:32 +08:00
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
/*
|
|
|
|
|
* Resume callback from host.
|
|
|
|
|
*
|
|
|
|
|
* This function tries to determine if the same card is still present
|
|
|
|
|
* and, if so, restore all state to it.
|
|
|
|
|
*/
|
2009-09-23 07:45:29 +08:00
|
|
|
static int mmc_resume(struct mmc_host *host)
|
2007-05-01 22:00:02 +08:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
BUG_ON(!host);
|
|
|
|
|
BUG_ON(!host->card);
|
|
|
|
|
|
|
|
|
|
mmc_claim_host(host);
|
2007-05-19 22:14:43 +08:00
|
|
|
err = mmc_init_card(host, host->ocr, host->card);
|
2007-07-22 23:52:06 +08:00
|
|
|
mmc_release_host(host);
|
|
|
|
|
|
2009-09-23 07:45:29 +08:00
|
|
|
return err;
|
2007-05-01 22:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
2010-10-02 19:54:06 +08:00
|
|
|
static int mmc_power_restore(struct mmc_host *host)
|
2009-09-23 07:44:33 +08:00
|
|
|
{
|
2010-10-02 19:54:06 +08:00
|
|
|
int ret;
|
|
|
|
|
|
2009-09-23 07:44:33 +08:00
|
|
|
host->card->state &= ~MMC_STATE_HIGHSPEED;
|
|
|
|
|
mmc_claim_host(host);
|
2010-10-02 19:54:06 +08:00
|
|
|
ret = mmc_init_card(host, host->ocr, host->card);
|
2009-09-23 07:44:33 +08:00
|
|
|
mmc_release_host(host);
|
2010-10-02 19:54:06 +08:00
|
|
|
|
|
|
|
|
return ret;
|
2009-09-23 07:44:33 +08:00
|
|
|
}
|
|
|
|
|
|
2009-09-23 07:44:34 +08:00
|
|
|
static int mmc_sleep(struct mmc_host *host)
|
|
|
|
|
{
|
|
|
|
|
struct mmc_card *card = host->card;
|
|
|
|
|
int err = -ENOSYS;
|
|
|
|
|
|
|
|
|
|
if (card && card->ext_csd.rev >= 3) {
|
|
|
|
|
err = mmc_card_sleepawake(host, 1);
|
|
|
|
|
if (err < 0)
|
|
|
|
|
pr_debug("%s: Error %d while putting card into sleep",
|
|
|
|
|
mmc_hostname(host), err);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mmc_awake(struct mmc_host *host)
|
|
|
|
|
{
|
|
|
|
|
struct mmc_card *card = host->card;
|
|
|
|
|
int err = -ENOSYS;
|
|
|
|
|
|
|
|
|
|
if (card && card->ext_csd.rev >= 3) {
|
|
|
|
|
err = mmc_card_sleepawake(host, 0);
|
|
|
|
|
if (err < 0)
|
|
|
|
|
pr_debug("%s: Error %d while awaking sleeping card",
|
|
|
|
|
mmc_hostname(host), err);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
static const struct mmc_bus_ops mmc_ops = {
|
2009-09-23 07:44:34 +08:00
|
|
|
.awake = mmc_awake,
|
|
|
|
|
.sleep = mmc_sleep,
|
2009-09-23 07:44:32 +08:00
|
|
|
.remove = mmc_remove,
|
|
|
|
|
.detect = mmc_detect,
|
|
|
|
|
.suspend = NULL,
|
|
|
|
|
.resume = NULL,
|
2009-09-23 07:44:33 +08:00
|
|
|
.power_restore = mmc_power_restore,
|
2009-09-23 07:44:32 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mmc_bus_ops mmc_ops_unsafe = {
|
2009-09-23 07:44:34 +08:00
|
|
|
.awake = mmc_awake,
|
|
|
|
|
.sleep = mmc_sleep,
|
2007-05-01 22:00:02 +08:00
|
|
|
.remove = mmc_remove,
|
|
|
|
|
.detect = mmc_detect,
|
|
|
|
|
.suspend = mmc_suspend,
|
|
|
|
|
.resume = mmc_resume,
|
2009-09-23 07:44:33 +08:00
|
|
|
.power_restore = mmc_power_restore,
|
2007-05-01 22:00:02 +08:00
|
|
|
};
|
|
|
|
|
|
2009-09-23 07:44:32 +08:00
|
|
|
static void mmc_attach_bus_ops(struct mmc_host *host)
|
|
|
|
|
{
|
|
|
|
|
const struct mmc_bus_ops *bus_ops;
|
|
|
|
|
|
2010-09-27 16:42:19 +08:00
|
|
|
if (!mmc_card_is_removable(host))
|
2009-09-23 07:44:32 +08:00
|
|
|
bus_ops = &mmc_ops_unsafe;
|
|
|
|
|
else
|
|
|
|
|
bus_ops = &mmc_ops;
|
|
|
|
|
mmc_attach_bus(host, bus_ops);
|
|
|
|
|
}
|
|
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
/*
|
|
|
|
|
* Starting point for MMC card init.
|
|
|
|
|
*/
|
2011-01-04 02:36:56 +08:00
|
|
|
int mmc_attach_mmc(struct mmc_host *host)
|
2007-05-01 22:00:02 +08:00
|
|
|
{
|
|
|
|
|
int err;
|
2011-01-04 02:36:56 +08:00
|
|
|
u32 ocr;
|
2007-05-01 22:00:02 +08:00
|
|
|
|
|
|
|
|
BUG_ON(!host);
|
2007-08-09 19:23:56 +08:00
|
|
|
WARN_ON(!host->claimed);
|
2007-05-01 22:00:02 +08:00
|
|
|
|
2011-01-04 02:36:56 +08:00
|
|
|
err = mmc_send_op_cond(host, 0, &ocr);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2009-09-23 07:44:32 +08:00
|
|
|
mmc_attach_bus_ops(host);
|
2010-12-08 17:04:30 +08:00
|
|
|
if (host->ocr_avail_mmc)
|
|
|
|
|
host->ocr_avail = host->ocr_avail_mmc;
|
2007-05-01 22:00:02 +08:00
|
|
|
|
MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-08-09 00:11:32 +08:00
|
|
|
/*
|
|
|
|
|
* We need to get OCR a different way for SPI.
|
|
|
|
|
*/
|
|
|
|
|
if (mmc_host_is_spi(host)) {
|
|
|
|
|
err = mmc_spi_read_ocr(host, 1, &ocr);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2007-05-01 22:00:02 +08:00
|
|
|
/*
|
|
|
|
|
* Sanity check the voltages that the card claims to
|
|
|
|
|
* support.
|
|
|
|
|
*/
|
|
|
|
|
if (ocr & 0x7F) {
|
|
|
|
|
printk(KERN_WARNING "%s: card claims to support voltages "
|
|
|
|
|
"below the defined range. These will be ignored.\n",
|
|
|
|
|
mmc_hostname(host));
|
|
|
|
|
ocr &= ~0x7F;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
host->ocr = mmc_select_voltage(host, ocr);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Can we support the voltage of the card?
|
|
|
|
|
*/
|
2007-07-23 06:12:10 +08:00
|
|
|
if (!host->ocr) {
|
|
|
|
|
err = -EINVAL;
|
2007-05-01 22:00:02 +08:00
|
|
|
goto err;
|
2007-07-23 06:12:10 +08:00
|
|
|
}
|
2007-05-01 22:00:02 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Detect and init the card.
|
|
|
|
|
*/
|
2007-05-19 22:14:43 +08:00
|
|
|
err = mmc_init_card(host, host->ocr, NULL);
|
2007-07-23 04:18:46 +08:00
|
|
|
if (err)
|
2007-05-01 22:00:02 +08:00
|
|
|
goto err;
|
|
|
|
|
|
|
|
|
|
mmc_release_host(host);
|
2007-05-19 19:39:01 +08:00
|
|
|
err = mmc_add_card(host->card);
|
2011-01-04 02:36:56 +08:00
|
|
|
mmc_claim_host(host);
|
2006-12-31 07:11:32 +08:00
|
|
|
if (err)
|
2007-07-22 23:52:06 +08:00
|
|
|
goto remove_card;
|
2006-12-31 07:11:32 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
2007-07-22 23:52:06 +08:00
|
|
|
remove_card:
|
2011-01-04 02:36:56 +08:00
|
|
|
mmc_release_host(host);
|
2007-05-01 22:00:02 +08:00
|
|
|
mmc_remove_card(host->card);
|
2007-07-22 23:52:06 +08:00
|
|
|
mmc_claim_host(host);
|
2011-01-04 02:36:56 +08:00
|
|
|
host->card = NULL;
|
2006-12-31 07:11:32 +08:00
|
|
|
err:
|
|
|
|
|
mmc_detach_bus(host);
|
|
|
|
|
|
2007-07-23 06:12:10 +08:00
|
|
|
printk(KERN_ERR "%s: error %d whilst initialising MMC card\n",
|
|
|
|
|
mmc_hostname(host), err);
|
|
|
|
|
|
2007-07-23 05:08:30 +08:00
|
|
|
return err;
|
2006-12-31 07:11:32 +08:00
|
|
|
}
|
