linux-stable.git/drivers/mmc/core, branch linux-3.16.y

mmc: mmc: fix switch timeout issue caused by jiffies precision

2020-01-11T02:04:57+00:00

commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 upstream.

with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.

Signed-off-by: Chaotian Jing 
Signed-off-by: Ulf Hansson 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

mmc: core: fix using wrong io voltage if mmc_select_hs200 fails

2020-01-11T02:04:44+00:00

commit e51534c806609c806d81bfb034f02737461f855c upstream.

Currently MMC core will keep going if HS200/HS timing switch failed
with -EBADMSG error by the assumption that the old timing is still valid.

However, for mmc_select_hs200 case, the signal voltage may have already
been switched. If the timing switch failed, we should fall back to
the old voltage in case the card is continue run with legacy timing.

If fall back signal voltage failed, we explicitly report an EIO error
to force retry during the next power cycle.

Signed-off-by: Dong Aisheng 
Signed-off-by: Ulf Hansson 
Cc: Arnd Bergmann 
[bwh: Backported to 3.16:
 - Delete now-unused err label
 - Adjust context]
Signed-off-by: Ben Hutchings

mmc: core: shut up "voltage-ranges unspecified" pr_info()

2020-01-11T02:04:43+00:00

commit 10a16a01d8f72e80f4780e40cf3122f4caffa411 upstream.

Each time a driver such as sdhci-esdhc-imx is probed, we get a info
printk complaining that the DT voltage-ranges property has not been
specified.

However, the DT binding specifically says that the voltage-ranges
property is optional.  That means we should not be complaining that
DT hasn't specified this property: by indicating that it's optional,
it is valid not to have the property in DT.

Silence the warning if the property is missing.

Signed-off-by: Russell King 
Signed-off-by: Ulf Hansson 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

mmc: sanitize 'bus width' in debug output

2020-01-11T02:04:43+00:00

commit ed9feec72fc1fa194ebfdb79e14561b35decce63 upstream.

The bus width is sometimes the actual bus width, and sometimes indices
to different arrays encoding the bus width. In my debugging case "2"
could mean 8-bit as well as 4-bit, which was extremly confusing. Let's
use the human-readable actual bus width in all places.

Signed-off-by: Wolfram Sang 
Signed-off-by: Ulf Hansson 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

mmc: debugfs: Add a restriction to mmc debugfs clock setting

2020-01-11T02:04:42+00:00

commit e5905ff1281f0a0f5c9863c430ac1ed5faaf5707 upstream.

Clock frequency values written to an mmc host should not be less than
the minimum clock frequency which the mmc host supports.

Signed-off-by: Yuan Juntao 
Signed-off-by: Pawel Wodkowski 
Signed-off-by: Ulf Hansson 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

mmc: core: Fix init of SD cards reporting an invalid VDD range

2019-11-22T15:57:25+00:00

commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.

When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.

Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.

Reported-by: Philip Langdale 
Signed-off-by: Ulf Hansson 
Reviewed-by: Philip Langdale 
Tested-by: Philip Langdale 
Tested-by: Manuel Presnitz 
Signed-off-by: Ben Hutchings

mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl

2019-02-11T17:54:27+00:00

commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream.

Some eMMCs from Micron have been reported to need ~800 ms timeout, while
enabling the CACHE ctrl after running sudden power failure tests. The
needed timeout is greater than what the card specifies as its generic CMD6
timeout, through the EXT_CSD register, hence the problem.

Normally we would introduce a card quirk to extend the timeout for these
specific Micron cards. However, due to the rather complicated debug process
needed to find out the error, let's simply use a minimum timeout of 1600ms,
the double of what has been reported, for all cards when enabling CACHE
ctrl.

Reported-by: Sjoerd Simons 
Reported-by: Andreas Dannenberg 
Reported-by: Faiz Abbas 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mmc: core: Reset HPI enabled state during re-init and in case of errors

2019-02-11T17:54:26+00:00

commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream.

During a re-initialization of the eMMC card, we may fail to re-enable HPI.
In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
bit, as it keeps being set. This may cause following attempts to use HPI,
even if's not enabled. Let's fix this!

Fixes: eb0d8f135b67 ("mmc: core: support HPI send command")
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mmc: core: fix multi-bit bus width without high-speed mode

2017-03-16T02:27:13+00:00

commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 upstream.

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mmc: longer timeout for long read time quirk

2016-08-22T21:38:04+00:00

commit 32ecd320db39bcb007679ed42f283740641b81ea upstream.

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel 
Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings