linux/drivers/mmc/core/core.c, branch v3.6

mmc: core: reset signal voltage on power up

2012-07-22T19:25:53Z

Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in mmc_power_up so that we do not need to touch signal voltage setting in mmc/sd/sdio init functions and rescan function. For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will lose its power and when powered on again, we will set signal voltage to 3.3v in mmc_power_up before its resume function gets called, which will re-init the card. And for sdio cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will either lose its power or not depending on if it wants to wakeup the host. If power is not maintained, it is the same case as mmc/sd cards. If power is maintained, mmc_power_up will not be called and the card's signal voltage will remain at the last setting. Signed-off-by: Aaron Lu Tested-by: Venkatraman S Signed-off-by: Chris Ball

mmc: prohibit card detection when host is not ready

2012-07-21T04:02:21Z

Currently mmc host drivers have to decide whether to enable card detection before calling mmc_add_host() -- in which case a card insertion event can arrive before the host has been completely initialised -- or after mmc_add_host(), in which case the initial card detection can be problematic. This patch adds an explicit indication of when card detection should not be carried out. With it in place enabling card detection before calling mmc_add_host() should be safe. Similarly, disabling it again after calling mmc_remove_host() will avoid any races. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Chris Ball

mmc: add a function to get regulators, supplying card's power

2012-07-21T04:02:08Z

Add a function to get regulators, supplying card's Vdd and Vccq on a specific host. If a Vdd supplying regulator is found, the function checks, whether a valid OCR mask can be obtained from it. The Vccq regulator is optional. A failure to get it is not fatal. Signed-off-by: Guennadi Liakhovetski Reviwed-by: Mark Brown Acked-by: Ulf Hansson Signed-off-by: Chris Ball

mmc: core: Export regulator_* functions as GPL

2012-07-11T03:04:06Z

The regulator API functions we're wrapping are exported as GPL, so our wrappers for the same functions should be too. Reported-by: Guennadi Liakhovetski Signed-off-by: Chris Ball

mmc: core: Fix the HPI execution sequence

2012-07-11T03:04:04Z

mmc_execute_hpi should send the HPI command only once, and only if the card is in PRG state. According to eMMC spec, the command's completion time is not dependent on OUT_OF_INTERRUPT_TIME. Only the transition out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is defined to begin at the end of sending the command itself. Specify the default timeout for the actual sending of HPI command, and then use OUT_OF_INTERRUPT_TIME to wait for the transition out of PRG state. Reported-by: Alex Lemberg Signed-off-by: Venkatraman S Reviewed-by: Namjae Jeon Reviewed-by: Subhash Jadavani Acked-by: Jaehoon Chung Signed-off-by: Chris Ball

mmc: core: Prevent eMMC VCC supply to be cut from late init

2012-05-09T16:55:01Z

For eMMC cards that has been initialized from a bootloader, the VCC voltage supply must not be cut in an uncontrolled manner, without first sending SLEEP or POWEROFF_NOTIFY. The regulator_init_complete late initcall, may cut the VCC regulator if it's reference counter is zero. To be able to prevent the regulator from being cut, mmc_start_host, which should execute at device init and thus before late init, calls mmc_power_up. Then the host driver is able to increase the reference to the regulator. Signed-off-by: Ulf Hansson Reviewed-by: Mark Brown Signed-off-by: Chris Ball

mmc: core: Do not pre-claim host in suspend

2012-04-21T01:52:13Z

Since SDIO drivers may want to do some SDIO operations in their suspend callback functions, we must not keep the host claimed when calling them. Daniel Drake reported that libertas_sdio encountered a deadlock in its suspend function. Signed-off-by: Ulf Hansson Tested-by: Daniel Drake [stable@: please apply to 3.2-stable and 3.3-stable] Cc: stable Signed-off-by: Chris Ball

mmc: fixes for eMMC v4.5 sanitize operation

2012-04-21T00:28:58Z

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:55Z

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

mmc: use really long write timeout to deal with crappy cards

2012-04-06T00:32:34Z

Several people have noticed that crappy SD cards take much longer to complete multiple block writes than the 300ms that Linux specifies. Try to work around this by using a three second write timeout instead. This is a generalized version of a patch from Chase Maupin , whose patch description said: * With certain SD cards timeouts like the following have been seen due to an improper calculation of the dto value: mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 * By removing the dto calculation and setting the timeout value to the maximum specified by the SD card specification part A2 section 2.2.15 these timeouts can be avoided. * This change has been used by beagleboard users as well as the Texas Instruments SDK without a negative impact. * There are multiple discussion threads about this but the most relevant ones are: * http://talk.maemo.org/showthread.php?p=1000707#post1000707 * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html * Original proposal for this fix was done by Sukumar Ghoral of Texas Instruments * Tested using a Texas Instruments AM335x EVM Signed-off-by: Paul Walmsley Tested-by: Tony Lindgren Signed-off-by: Chris Ball