linux-stable.git/drivers/mmc, branch v5.4.34

mmc: sdhci: Refactor sdhci_set_timeout()

2020-04-17T08:50:25+00:00

[ Upstream commit 7d76ed77cfbd39468ae58d419f537d35ca892d83 ]

Refactor sdhci_set_timeout() such that platform drivers can do some
functionality in a set_timeout() callback and then call
__sdhci_set_timeout() to complete the operation.

Signed-off-by: Faiz Abbas 
Acked-by: Adrian Hunter 
Link: https://lore.kernel.org/r/20200116105154.7685-7-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: Convert sdhci_set_timeout_irq() to non-static

2020-04-17T08:50:25+00:00

[ Upstream commit 7907ebe741a7f14ed12889ebe770438a4ff47613 ]

Export sdhci_set_timeout_irq() so that it is accessible from platform drivers.

Signed-off-by: Faiz Abbas 
Acked-by: Adrian Hunter 
Link: https://lore.kernel.org/r/20200116105154.7685-6-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-of-esdhc: fix esdhc_reset() for different controller versions

2020-04-17T08:50:16+00:00

commit 2aa3d826adb578b26629a79b775a552cfe3fedf7 upstream.

This patch is to fix operating in esdhc_reset() for different
controller versions, and to add bus-width restoring after data
reset for eSDHC (verdor version <= 2.2).

Also add annotation for understanding.

Signed-off-by: Yangbo Lu 
Acked-by: Adrian Hunter 
Link: https://lore.kernel.org/r/20200108040713.38888-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-tegra: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

2020-04-01T09:01:29+00:00

[ Upstream commit d2f8bfa4bff5028bc40ed56b4497c32e05b0178f ]

It has turned out that the sdhci-tegra controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.

Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.

Reported-by: Bitan Biswas 
Reported-by: Peter Geis 
Suggested-by: Sowjanya Komatineni 
Cc: 
Tested-by: Sowjanya Komatineni 
Tested-By: Peter Geis 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

2020-04-01T09:01:28+00:00

[ Upstream commit 055e04830d4544c57f2a5192a26c9e25915c29c0 ]

It has turned out that the sdhci-omap controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.

Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.

Reported-by: Naresh Kamboju 
Reported-by: Anders Roxell 
Reported-by: Faiz Abbas 
Cc: 
Tested-by: Anders Roxell 
Tested-by: Faiz Abbas 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command

2020-04-01T09:01:28+00:00

[ Upstream commit 18d200460cd73636d4f20674085c39e32b4e0097 ]

The busy timeout for the CMD5 to put the eMMC into sleep state, is specific
to the card. Potentially the timeout may exceed the host->max_busy_timeout.
If that becomes the case, mmc_sleep() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.

However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.

Suggested-by: Sowjanya Komatineni 
Cc: 
Link: https://lore.kernel.org/r/20200311092036.16084-1-ulf.hansson@linaro.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard

2020-04-01T09:01:27+00:00

[ Upstream commit 43cc64e5221cc6741252b64bc4531dd1eefb733d ]

The busy timeout that is computed for each erase/trim/discard operation,
can become quite long and may thus exceed the host->max_busy_timeout. If
that becomes the case, mmc_do_erase() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.

However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.

Suggested-by: Sowjanya Komatineni 
Cc: 
Tested-by: Anders Roxell 
Tested-by: Sowjanya Komatineni 
Tested-by: Faiz Abbas 
Tested-By: Peter Geis 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: Allow host controllers to require R1B for CMD6

2020-04-01T09:01:27+00:00

[ Upstream commit 1292e3efb149ee21d8d33d725eeed4e6b1ade963 ]

It has turned out that some host controllers can't use R1B for CMD6 and
other commands that have R1B associated with them. Therefore invent a new
host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this.

In __mmc_switch(), let's check the flag and use it to prevent R1B responses
from being converted into R1. Note that, this also means that the host are
on its own, when it comes to manage the busy timeout.

Suggested-by: Sowjanya Komatineni 
Cc: 
Tested-by: Anders Roxell 
Tested-by: Sowjanya Komatineni 
Tested-by: Faiz Abbas 
Tested-By: Peter Geis 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-cadence: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN for UniPhier

2020-03-25T07:25:54+00:00

commit 18b587b45c13bb6a07ed0edac15f06892593d07a upstream.

The SDHCI_PRESET_FOR_* registers are not set for the UniPhier platform
integration. (They are all read as zeros).

Set the SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk flag. Otherwise, the
High Speed DDR mode on the eMMC controller (MMC_TIMING_MMC_DDR52)
would not work.

I split the platform data to give no impact to other platforms,
although the UniPhier platform is currently only the upstream user
of this IP.

The SDHCI_QUIRK2_PRESET_VALUE_BROKEN flag is set if the compatible
string matches to "socionext,uniphier-sd4hc".

Signed-off-by: Masahiro Yamada 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200312104257.21017-1-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-at91: fix cd-gpios for SAMA5D2

2020-03-25T07:25:54+00:00

commit 53dd0a7cd65edc83b0c243d1c08377c8b876b2ee upstream.

SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least
SAMA5D27 doesn't). Fix this by forcing card-detect in the module
if module-controlled CD is not used.

Fixed commit addresses the problem only for non-removable cards. This
amends it to also cover gpio-cd case.

Cc: stable@vger.kernel.org
Fixes: 7a1e3f143176 ("mmc: sdhci-of-at91: force card detect value for non removable devices")
Signed-off-by: Michał Mirosław 
Acked-by: Adrian Hunter 
Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman