linux-stable.git/drivers/mmc/core, branch v5.6

mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command

2020-03-12T12:36:55+00:00

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

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

2020-03-11T15:11:34+00:00

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

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

2020-03-11T15:10:36+00:00

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

mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()

2020-01-24T11:17:05+00:00

All callers of __mmc_switch() should now be specifying a valid timeout for
the CMD6 command. However, just to be sure, let's print a warning and
default to use the generic_cmd6_time in case the provided timeout_ms
argument is zero.

In this context, let's also simplify some of the corresponding code and
clarify some related comments.

Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20200122142747.5690-4-ulf.hansson@linaro.org

mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD

2020-01-24T11:16:05+00:00

The INAND_CMD38_ARG_EXT_CSD is a vendor specific EXT_CSD register, which is
used to prepare an erase/trim operation. However, it doesn't make sense to
use a timeout of 10 minutes while updating the register, which becomes the
case when the timeout_ms argument for mmc_switch() is set to zero.

Instead, let's use the generic_cmd6_time, as that seems like a reasonable
timeout to use for these cases.

Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20200122142747.5690-3-ulf.hansson@linaro.org

mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC

2020-01-24T11:16:05+00:00

The timeout values used while waiting for a CMD6 for BKOPS or a CACHE_FLUSH
to complete, are not defined by the eMMC spec. However, a timeout of 10
minutes as is currently being used, is just silly for both of these cases.
Instead, let's specify more reasonable timeouts, 120s for BKOPS and 30s for
CACHE_FLUSH.

Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20200122142747.5690-2-ulf.hansson@linaro.org

mmc: core: limit probe clock frequency to configured f_max

2020-01-20T10:54:45+00:00

Currently MMC core disregards host->f_max during card initialization
phase. Obey upper boundary for the clock frequency and skip faster
speeds when they are above the limit.

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/f471bceaf237d582d746bd289c4c4f3639cb7b45.1577962382.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson

mmc: core: Remove mmc_gpiod_request_*(invert_gpio)

2019-12-18T12:37:07+00:00

Now that invert_gpio arguments are unused, let's remove them.

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/64d766d1f8af2e22bce32f4ffa453f7234207ad6.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson

mmc: core: Rework cd-gpio handling

2019-12-18T12:36:53+00:00

There are a few places around the code that invert inverted and possibly
inverted CD line. That's really confusing. Squash them all into one place
in mmc_gpiod_request_cd(). MMC_CAP2_CD_ACTIVE_HIGH is used analogously to
WP line: in GPIO mode it is used only at probe time to switch polarity, for
native mode it is left as is.

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/db189b715596d63caf8c6a088bddc71dd69a879b.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson

mmc: core: Rework wp-gpio handling

2019-12-18T12:36:40+00:00

Use MMC_CAP2_RO_ACTIVE_HIGH flag as indicator if GPIO line is to be
inverted compared to DT/platform-specified polarity. The flag is not used
after init in GPIO mode anyway. No functional changes intended.

Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/a60f563f11bbff821da2fa2949ca82922b144860.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson