linux-stable.git/drivers/mmc/core/core.c, branch v4.2

mmc: core: Factor out common code in drive strength selection

2015-06-01T07:07:12+00:00

Make a new function out of common code used for drive
strength selection.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Reset driver type to default

2015-06-01T07:07:10+00:00

IO state variable drv_type could be set during card
initialization. Consequently, it must be reset to the
default value when setting the initial state.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Increase delay for voltage to stabilize from 3.3V to 1.8V

2015-06-01T07:07:07+00:00

Since the regulator used for the SDMMC IO voltage is not expected to
draw a lot of current, most systems will probably use an inexpensive
LDO for it.  LDO regulators apparently have the feature that they
don't actively drive the voltage down--they wait for other components
in the system to drag the voltage down.  Thus they will transition
faster under heavy loads and slower under light loads.

During an SDMMC voltage change from 3.3V to 1.8V, we are almost
certainly under a light load.  To be specific:
* The regulator is hooked through pulls to CMD0-3 and DAT.  Probably
  the CMD pulls are something like 47K and the DAT is something like
  10K.
* The card is supposed to be driving DAT0-3 low during voltage change
  which will draw _some_ current, but not a lot.
* The regulator is also provided to the SDMMC host controller, but the
  SDMMC host controller is in open drain mode during the voltage
  change and so shouldn't be drawing much current.

In order to keep the SDMMC host working properly (or for noise
reasons), there might also be a capacitor attached to the SDMMC IO
regulator.  This also will have the effect of slowing down transitions
of the regulator, especially under light loads.

From experimental evidence, we've seen the voltage change fail if the
card doesn't detect that the voltage fell to less than about 2.3V when
we turn on the clock.  On one device (that admittedly had a 47K CMD
pullup instead of a 10K CMD pullup) we saw that the voltage was just
about 2.3V after 5ms and thus the voltage change would sometimes fail.
Doubling the delay gave margin and made the voltage change work 100%
of the time, despite the slightly weaker CMD pull.

At the moment submitting this as an RFC patch since my problem _could_
be fixed by increasing the pull strength (or using a smaller
capacitor).  However being a little bit more lenient to strange
hardware could also be a good thing.

Signed-off-by: Doug Anderson 
Acked-by: Mark Brown 
Signed-off-by: Ulf Hansson

mmc: core: Don't print reset warning if reset is not supported

2015-06-01T07:06:59+00:00

Check the error code for EOPNOTSUPP and do not print
reset warning in that case.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Flag re-tuning is needed on CRC errors

2015-06-01T07:06:58+00:00

CRC errors could possibly be alleviated by
re-tuning so flag re-tuning needed in those cases.
Note this has no effect if re-tuning has not been
enabled.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Hold re-tuning while bkops ongoing

2015-06-01T07:06:55+00:00

Hold re-tuning during bkops to prevent
it from conflicting with the busy state.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Hold re-tuning during erase commands

2015-06-01T07:06:55+00:00

Hold re-tuning during erase commands to prevent
it from conflicting with the sequence of commands.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Add support for re-tuning before each request

2015-06-01T07:06:54+00:00

At the start of each request, re-tune if needed and
then hold off re-tuning again until the request is done.

Note that though there is one function that starts
requests (mmc_start_request) there are two that wait for
the request to be done (mmc_wait_for_req_done and
mmc_wait_for_data_req_done).  Also note that
mmc_wait_for_data_req_done can return even when the
request is not done (which allows the block driver
to prepare a newly arrived request while still
waiting for the previous request).

This patch ensures re-tuning is held for the duration
of a request.  Subsequent patches will also hold
re-tuning at other times when it might cause a
conflict.

In addition, possibly a command is failing because
re-tuning is needed. Use mmc_retune_recheck() to check
re-tuning. At that point re-tuning is held, at least by
the request, so mmc_retune_recheck() flags host->retune_now
if the hold count is 1.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Enable / disable re-tuning

2015-06-01T07:06:54+00:00

Enable re-tuning when tuning is executed and
disable re-tuning when card is no longer initialized.

In the case of SDIO suspend, the card can keep power.
In that case, re-tuning need not be disabled, but, if
a re-tuning timer is being used, ensure it is disabled
and assume that re-tuning will be needed upon resume
since it is not known how long the suspend will last.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

2015-05-04T08:33:33+00:00

The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko 
Signed-off-by: Ulf Hansson