linux-toradex.git/drivers/mmc/core/core.c, branch v3.4.41

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

2012-04-21T01:52:13+00:00

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

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

2012-04-06T00:32:34+00:00

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

mmc: core: Clean up after mmc_pre_req if card was removed

2012-03-27T16:20:04+00:00

Make sure mmc_start_req cancels the prepared job, if the request
was prevented to be started due to the card has been removed.

This bug was introduced in commit:
mmc: allow upper layers to know immediately if card has been removed

Signed-off-by: Ulf Hansson 
Reviewed-by: Per Forlin 
Tested-by: Jaehoon Chung 
Signed-off-by: Chris Ball

mmc: start removing enable / disable API

2012-03-27T16:20:03+00:00

Most parts of the enable / disable API are no longer used and
can be removed.

Signed-off-by: Adrian Hunter 
Tested-by: Venkatraman S 
Tested-by: Jaehoon Chung 
Signed-off-by: Chris Ball

mmc: core: Detect card removal on I/O error

2012-03-27T16:19:58+00:00

To prevent I/O as soon as possible at card removal, a new detect work is
re-scheduled without a delay to let a rescan remove the card device as
soon as possible.

Additionally, MMC_CAP2_DETECT_ON_ERR can now be used to handle "slowly"
removed cards that a scheduled detect work did not detect as removed.
To prevent further I/O requests for these lingering removed cards,
check if card has been removed and then schedule a detect work to
properly remove it.

Signed-off-by: Ulf Hansson 
Reviewed-by: Namjae Jeon 
Acked-by: Linus Walleij 
Signed-off-by: Chris Ball

mmc: core: add a debug message for SET_BLOCK_COUNT

2012-03-25T23:33:45+00:00

This patch is added just debug message.  Almost features need to use the
CMD23.  But we didn't see the debug message for sbc.  If sbc's message
can see, should be help for debugging.  (We can check whether use the
cmd23 or not.)

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Chris Ball

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

2012-03-04T17:25:15+00:00

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: core: Fix PowerOff Notify suspend/resume

2012-02-14T01:39:02+00:00

Modified the mmc_poweroff to resume before sending the poweroff
notification command. In sleep mode only AWAKE and RESET commands are
allowed, so before sending the poweroff notification command resume from
sleep mode and then send the notification command.

PowerOff Notify is tested on a Synopsis Designware Host Controller
(eMMC 4.5). The suspend to RAM and resume works fine.

Signed-off-by: Girish K S 
Tested-by: Girish K S 
Reviewed-by: Saugata Das 
Signed-off-by: Chris Ball