user/sven/linux.git/drivers/mmc, branch v3.3.6

mmc: unbreak sdhci-esdhc-imx on i.MX25

2012-04-27T17:16:35Z

commit b89152824f993a9572b47eb31f4579feadeac34c upstream. This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read). Signed-off-by: Eric Bénard Acked-by: Wolfram Sang Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: refine non-removable card checking for card detection

2012-04-27T17:16:35Z

commit 87b87a3fc0eec58d95e4216392f889a26439ad22 upstream. Commit c79396c191bc19 ("mmc: sdhci: prevent card detection activity for non-removable cards") disables card detection where the cards are marked as non-removable. This makes sense, but the implementation detail of calling mmc_card_is_removable() causes some problems, because mmc_card_is_removable() is overloaded with CONFIG_MMC_UNSAFE_RESUME semantics. In the OLPC XO case, we need CONFIG_MMC_UNSAFE_RESUME because our root filesystem is stored on SD, but we also have external SD card slots where we want automatic card detection. Refine the check to only apply to hosts marked as MMC_CAP_NONREMOVABLE, which is defined to mean that the card is *really* nonremovable. This could be revisited in future if we find a way to improve CONFIG_MMC_UNSAFE_RESUME semantics. Signed-off-by: Daniel Drake Acked-by: Chuanxiao Dong Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: fixes for eMMC v4.5 sanitize operation

2012-04-27T17:16:35Z

commit 283028122db37621b124f079ca8eae5b64807ad4 upstream. 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 Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: fixes for eMMC v4.5 discard operation

2012-04-27T17:16:35Z

commit 7194efb8f063ee3aa0cb50d9002348887e68ec10 upstream. 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 Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: atmel-mci: correct data timeout computation

2012-04-13T16:13:55Z

commit 66292ad92c6d3f2f1c137a1c826b331ca8595dfd upstream. The HSMCI operates at a rate of up to Master Clock divided by two. Moreover previous calculation can cause overflows and so wrong timeouts. Signed-off-by: Ludovic Desroches Acked-by: Nicolas Ferre Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-dove: Fix compile error by including module.h

2012-04-13T16:13:55Z

commit 8c2fc8e413ecc2c96b696e28d4eb1bc6cee8dc84 upstream. This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c by including the linux/module.h file. Signed-off-by: Alf Høgemark Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdio: Use empty system suspend/resume callbacks at the bus level

2012-04-13T16:13:55Z

commit e841a7c69b708eeaf784fd517978006e8319b03a upstream. Neil Brown reports that commit 35cd133c PM: Run the driver callback directly if the subsystem one is not there breaks suspend for his libertas wifi, because SDIO has a protocol where the suspend method can return -ENOSYS and this means "There is no point in suspending, just turn me off". Moreover, the suspend methods provided by SDIO drivers are not supposed to be called by the PM core or bus-level suspend routines (which aren't presend for SDIO). Instead, when the SDIO core gets to suspend the device's ancestor, it calls the device driver's suspend function, catches the ENOSYS, and turns the device off. The commit above breaks the SDIO core's assumption that the device drivers' callbacks won't be executed if it doesn't provide any bus-level callbacks. If fact, however, this assumption has never been really satisfied, because device class or device type suspend might very well use the driver's callback even without that commit. The simplest way to address this problem is to make the SDIO core tell the PM core to ignore driver callbacks, for example by providing no-operation suspend/resume callbacks at the bus level for it, which is implemented by this change. Reported-and-tested-by: Neil Brown Signed-off-by: Rafael J. Wysocki Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: Fixup suspend/resume issues for UHS-I cards

2012-03-04T17:25:15Z

Even if cards supports 1.8V I/O voltage those should anyway be initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs. Some eMMC and embedded SDIO devices are able to be initialized at 1.8V as well, but it is better to be safe. Do note that initialization in this context means that the card has been completely powered off, otherwise the card will remain at the last I/O voltage level that were negotitiated. Due to the above being taken care of the suspend/resume issues for UHS-I SD-cards has been fixed. Signed-off-by: Ulf Hansson Acked-by: Philip Rakity Acked-by: Linus Walleij Tested-by: Subhash Jadavani Signed-off-by: Chris Ball

mmc: mmci: reduce max_blk_count to avoid overflowing max_req_size

2012-03-04T17:25:14Z

On a system with large pages (64k in my case), the following BUG is triggered in MMC core: [ 2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()! [ 2.338102] Kernel panic - not syncing: BUG! [ 2.338155] Call trace: [ 2.338228] [] dump_backtrace+0x0/0x120 [ 2.338317] [] dump_stack+0x14/0x1c [ 2.338403] [] panic+0xbc/0x1f0 [ 2.338498] [] mmc_start_request+0x154/0x184 [ 2.338600] [] mmc_start_req+0x110/0x140 [ 2.338701] [] mmc_blk_issue_rw_rq+0x7c/0x39c [ 2.338804] [] mmc_blk_issue_rq+0x1c0/0x468 [ 2.338905] [] mmc_queue_thread+0x68/0x118 [ 2.338995] [] kthread+0x84/0x8c This is because of a 64k request with a max_req_size of 64k-1 bytes. The following patch fixes the problem by limiting the max_blk_count such that max_blk_count * max_blk_size == max_req_size. I couldn't pursuade the compiler to emit a shift instead of a div without encoding the shift explicitly. Signed-off-by: Will Deacon Signed-off-by: Chris Ball

mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5

2012-03-04T17:25:02Z

On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION command. This works for SD cards. However, with MMC cards the MMC_SET_BLOCK_COUNT command is used instead, but this needs the same handling. Fix MMC cards by testing for the MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53 board with a Transcend MMC+ card and eMMC. The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this is a regression for these boards introduced in 3.0; it should go to 3.0/3.1/3.2-stable. Signed-off-by: Sascha Hauer Acked-by: Shawn Guo Cc: Signed-off-by: Chris Ball