linux-toradex.git/drivers/mmc/card, branch v3.6.1

mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.

2012-09-04T17:58:10+00:00

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

References:

http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Signed-off-by: Ian Chen 
Reviewed-by: Namjae Jeon 
Acked-by: Jaehoon Chung 
Reviewed-by: Linus Walleij 
Cc: stable  [3.0+]
Signed-off-by: Chris Ball

mmc: block: replace __blk_end_request() with blk_end_request()

2012-07-11T03:04:05+00:00

For completing any block request, MMC block driver is calling:
	spin_lock_irq(queue)
	__blk_end_request()
	spin_unlock_irq(queue)

But if we analyze the sources of latency in kernel using ftrace,
__blk_end_request() function at times may take up to 6.5ms with
spinlock held and irq disabled.

__blk_end_request() calls couple of functions and ftrace output
shows that blk_update_bidi_request() function is almost taking 6ms.
There are 2 function to end the current request: ___blk_end_request()
and blk_end_request(). Both these functions do same thing except
that blk_end_request() function doesn't take up the spinlock
while calling the blk_update_bidi_request().

This patch replaces all __blk_end_request() calls with
blk_end_request() and __blk_end_request_all() calls with
blk_end_request_all().

Testing done: 20 process concurrent read/write on sd card
and eMMC. Ran this test for almost a day on multicore system
and no errors observed.

This change is not meant for improving MMC throughput; it's basically
about becoming fair to other threads/interrupts in the system. By
holding spin lock and interrupts disabled for longer duration, we
won't allow other threads/interrupts to run at all.  Actually slight
performance degradation at file system level can be expected as we
are not holding the spin lock during blk_update_bidi_request() which
means our mmcqd thread may get preempted for other high priority
thread or any interrupt in the system.

These are performance numbers (100MB file write) with eMMC running
in DDR mode:

Without this patch:
	Name of the Test   Value   Unit
	LMDD Read Test     53.79   MBPS
	LMDD Write Test    18.86   MBPS
	IOZONE  Read Test  51.65   MBPS
	IOZONE  Write Test 24.36   MBPS

With this patch:
	Name of the Test    Value  Unit
	LMDD Read Test      52.94  MBPS
	LMDD Write Test     16.70  MBPS
	IOZONE  Read Test   52.08  MBPS
	IOZONE  Write Test  23.29  MBPS

Read numbers are fine. Write numbers are bit down (especially LMDD
write), may be because write requests normally have large transfer
size and which means there are chances that while mmcq is executing
blk_update_bidi_request(), it may get interrupted by interrupts or
other high priority thread.

Signed-off-by: Subhash Jadavani 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: block: fix the data timeout issue with ACMD22

2012-06-26T20:10:29+00:00

If multi block write operation fails for SD card, during
error handling we send the SD_APP_SEND_NUM_WR_BLKS (ACMD22)
to know how many blocks were already programmed by card.

But mmc_sd_num_wr_blocks() function which sends the ACMD22
calculates the data timeout value from csd.tacc_ns and
csd.tacc_clks parameters which will be 0 for block addressed
(>2GB cards) SD card. This would result in timeout_ns and
timeout_clks being 0 in the mmc_request passed to host driver.
This means host controller would program its data timeout timer
value with 0 which could result in DATA TIMEOUT errors from
controller.

To fix this issue, mmc_sd_num_wr_blocks() should instead
just call the mmc_set_data_timeout() to calculate the
data timeout value. mmc_set_data_timeout() function
ensures that non zero timeout value is set even for
block addressed SD cards.

Signed-off-by: Subhash Jadavani 
Reviewed-by: Venkatraman S 
Signed-off-by: Chris Ball

mmc: block: Allow disabling 512B sector size emulation

2012-05-17T13:35:21+00:00

This patch adds support for large sector size of 4KB by disabling
emulation.  This patch passes eMMC DATA_SECTOR_SIZE as the logical
block size during mmc_blk_alloc_req.

In order to use this patch for 4KB sector size, ensure that
USE_NATIVE_SECTOR is enabled, partition table is 4KB sector size
aligned and file system block and sector size are 4KB multiples.

Signed-off-by: Saugata Das 
Reviewed-by: Subhash Jadavani 
Reviewed-by: Namjae Jeon 
Reviewed-by: Subhash Jadavani 
Signed-off-by: Chris Ball

mmc: card: Avoid null pointer dereference

2012-05-10T00:47:37+00:00

After the null check on md the code jumped to cmd_done, which then
will dereference md in mmc_blk_put. This patch avoids the possible
null pointer dereference in that case.

Signed-off-by: Philippe De Swert 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: queue: remove redundant memsets

2012-05-09T14:10:46+00:00

Not needed to memset, as they are pointers and are assigned
to proper values in the next line anyway.

Signed-off-by: Venkatraman S 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: queue: rename mmc_request function

2012-05-09T14:08:54+00:00

The name mmc_request is used for both the issue function
and a data structure, which creates conflicts in symbol lookups
in editors. Rename the function to mmc_request_fn.

Signed-off-by: Venkatraman S 
Reviewed-by: Namjae Jeon 
Signed-off-by: Chris Ball

mmc: remove MMC bus legacy suspend/resume method

2012-04-21T00:30:19+00:00

MMC bus is using legacy suspend/resume method, which is not compatible if
runtime pm callbacks are used. In this scenario, MMC bus suspend/resume
callbacks cannot be called when system entering S3. So change to use the
new defined dev_pm_ops for system sleeping mode.

Tested on AM335x Platform. Solves major issue/crash reported at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65425.html

Signed-off-by: Chuanxiao Dong 
Tested-by: Hebbar, Gururaja 
Acked-by: Linus Walleij 
Acked-by: Ulf Hansson 
Signed-off-by: Chris Ball

mmc: fixes for eMMC v4.5 sanitize operation

2012-04-21T00:28:58+00:00

eMMC v4.5 sanitize operation erases all copies of unmapped
data.  However trim or erase operations must be used first
to unmap the required sectors.  That was not being done.

Fixes apply to linux 3.2 on.

Signed-off-by: Adrian Hunter 
Cc: 
Acked-by: Jaehoon Chung 
Acked-by: Linus Walleij 
Signed-off-by: Chris Ball

mmc: fixes for eMMC v4.5 discard operation

2012-04-21T00:28:55+00:00

eMMC v4.5 discard operation is significantly different from the
existing trim operation because it is not guaranteed to work with
the new sanitize operation.  Consequently mmc_can_trim() is
separated from mmc_can_discard().

Also the new discard operation does not result in the sectors being
set to all-zeros, so discard_zeroes_data must not be set.

In addition, the new discard has the same timeout as trim, but from
v4.5 trim is defined to use the hc timeout.  The timeout calculation
is adjusted accordingly.

Fixes apply to linux 3.2 on.

Signed-off-by: Adrian Hunter 
Cc: 
Acked-by: Jaehoon Chung 
Acked-by: Linus Walleij 
Signed-off-by: Chris Ball