linux-toradex.git/include/linux/mmc, branch v5.14-rc6

mmc: Improve function name when aborting a tuning cmd

2021-06-14T11:57:44+00:00

'mmc_abort_tuning()' made me think tuning gets completely aborted.
However, it sends only a STOP cmd to cancel the current tuning cmd.
Tuning process may still continue after that. So, rename the function to
'mmc_send_abort_tuning()' to better reflect all this.

Signed-off-by: Wolfram Sang 
Reviewed-by: Niklas Söderlund 
Link: https://lore.kernel.org/r/20210608180620.40059-1-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson

mmc: core: Add support for cache ctrl for SD cards

2021-06-14T11:57:38+00:00

In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. As a part of this an optional internal cache
on the SD card, can be used to improve performance.

The let the SD card use the cache, the host needs to enable it and manage
flushing of the cache, so let's add support for this.

Note that for an SD card supporting the cache it's mandatory for it, to
also support the poweroff notification feature. According to the SD spec,
if the cache has been enabled and a poweroff notification is sent to the
card, that implicitly also means that the card should flush its internal
cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block
requests is sufficient.

Reviewed-by: Linus Walleij 
Signed-off-by: Ulf Hansson 
Reviewed-by: Avri Altman 
Link: https://lore.kernel.org/r/20210511101359.83521-1-ulf.hansson@linaro.org

mmc: core: Add support for Power Off Notification for SD cards

2021-06-14T11:57:37+00:00

Rather than only deselecting the SD card via a CMD7, before we cut power to
it at system suspend, at runtime suspend or at shutdown, let's add support
for a graceful power off sequence via enabling the SD Power Off
Notification feature.

Note that, the Power Off Notification feature was added in the SD spec
v4.x, which is several years ago. However, it's still a bit unclear how
often the SD card vendors decides to implement support for it. To validate
these changes a Sandisk Extreme PRO A2 64GB has been used, which seems to
work nicely.

Signed-off-by: Ulf Hansson 
Acked-by: Avri Altman 
Reviewed-by: Linus Walleij 
Reviewed-by: Shawn Lin 
Link: https://lore.kernel.org/r/20210504161222.101536-12-ulf.hansson@linaro.org

mmc: core: Read performance enhancements registers for SD cards

2021-06-14T11:57:36+00:00

In SD spec v6.x the SD function extension registers for performance
enhancements were introduced. These registers let the SD card announce
supports for various performance related features, like "self-maintenance",
"cache" and "command queuing".

Let's extend the parsing of SD function extension registers and store the
information in the struct mmc_card. This prepares for subsequent changes to
implement the complete support for new the performance enhancement
features.

Signed-off-by: Ulf Hansson 
Acked-by: Avri Altman 
Reviewed-by: Linus Walleij 
Reviewed-by: Shawn Lin 
Link: https://lore.kernel.org/r/20210504161222.101536-11-ulf.hansson@linaro.org

mmc: core: Read the SD function extension registers for power management

2021-06-14T11:57:36+00:00

In the SD spec v4.0 the CMD48/49 and CMD58/59 were introduced as optional
commands. In the SD spec v4.1 the SD function extension registers were
introduced, which requires support for CMD48/49/58/59 to be read/written
from/to.

Moreover, a specific function extension register were added to let the card
announce support for optional features in regards to power management. The
features that were added are "Power Off Notification", "Power Down Mode"
and "Power Sustenance".

As a first step to support this, let's read and parse the register for
power management during the SD card initialization and store the
information about the supported features in the struct mmc_card. In this
way, we prepare for subsequent changes to implement the complete support
for the new features.

Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Reviewed-by: Shawn Lin 
Acked-by: Avri Altman 
Link: https://lore.kernel.org/r/20210504161222.101536-10-ulf.hansson@linaro.org

mmc: core: Parse the SD SCR register for support of CMD48/49 and CMD58/59

2021-06-14T11:57:36+00:00

In SD spec v4.x the support for CMD48/49 and CMD58/59 were introduced as
optional features. To let the card announce whether it supports the
commands, the SCR register has been extended with corresponding support
bits. Let's parse and store this information for later use.

Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Reviewed-by: Shawn Lin 
Acked-by: Avri Altman 
Link: https://lore.kernel.org/r/20210504161222.101536-9-ulf.hansson@linaro.org

mmc: core: Convert mmc_of_parse_voltage() to use device property API

2021-04-23T07:29:49+00:00

mmc_of_parse() for a few years has been using device property API.
Convert mmc_of_parse_voltage() as well.

At the same time switch users to new API.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210419112459.25241-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Ulf Hansson

mmc: core: Fix hanging on I/O during system suspend for removable cards

2021-03-30T09:42:03+00:00

The mmc core uses a PM notifier to temporarily during system suspend, turn
off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO
cards. Additionally, the notifier may be used to remove an SDIO card
entirely, if a corresponding SDIO functional driver don't have the system
suspend/resume callbacks assigned. This behaviour has been around for a
very long time.

However, a recent bug report tells us there are problems with this
approach. More precisely, when receiving the PM_SUSPEND_PREPARE
notification, we may end up hanging on I/O to be completed, thus also
preventing the system from getting suspended.

In the end what happens, is that the cancel_delayed_work_sync() in
mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since
mmc_rescan() wants to claim the host, it needs to wait for the I/O to be
completed first.

Typically, this problem is triggered in Android, if there is ongoing I/O
while the user decides to suspend, resume and then suspend the system
again. This due to that after the resume, an mmc_rescan() work gets punted
to the workqueue, which job is to verify that the card remains inserted
after the system has resumed.

To fix this problem, userspace needs to become frozen to suspend the I/O,
prior to turning off the card detection mechanism. Therefore, let's drop
the PM notifiers for mmc subsystem altogether and rely on the card
detection to be turned off/on as a part of the system_freezable_wq, that we
are already using.

Moreover, to allow and SDIO card to be removed during system suspend, let's
manage this from a ->prepare() callback, assigned at the mmc_host_class
level. In this way, we can use the parent device (the mmc_host_class
device), to remove the card device that is the child, in the
device_prepare() phase.

Reported-by: Kiwoong Kim 
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org
Reviewed-by: Kiwoong Kim

mmc: sdio: fix a typo in the comment of SDIO_SD_REV_3_00

2021-03-30T09:42:03+00:00

I believe "Spev" is typo, should be "Spec".

Signed-off-by: Jisheng Zhang 
Link: https://lore.kernel.org/r/20210311174157.561dada9@xhacker.debian
Signed-off-by: Ulf Hansson

mmc: core: Drop reference counting of the bus_ops

2021-03-30T09:41:58+00:00

When the mmc_rescan work is enabled for execution (host->rescan_disable),
it's the only instance per mmc host that is allowed to set/clear the
host->bus_ops pointer.

Besides the mmc_rescan work, there are a couple of scenarios when the
host->bus_ops pointer may be accessed. Typically, those can be described as
as below:

*)
Upper mmc driver layers (like the mmc block device driver or an SDIO
functional driver) needs to execute a host->bus_ops callback. This can be
considered as safe without having to use some special locking mechanism,
because they operate on top of the struct mmc_card. As long as there is a
card to operate upon, the mmc core guarantees that there is a host->bus_ops
assigned as well. Note that, upper layer mmc drivers are of course
responsible to clean up from themselves from their ->remove() callbacks,
otherwise things would fall apart anyways.

**)
Via the mmc host instance, we may need to force a removal of an inserted
mmc card. This happens when a mmc host driver gets unbind, for example. In
this case, we protect the host->bus_ops pointer from concurrent accesses,
by disabling the mmc_rescan work upfront (host->rescan_disable). See
mmc_stop_host() for example.

This said, it seems like the reference counting of the host->bus_ops
pointer at some point have become superfluous. As this is an old mechanism
of the mmc core, it a bit difficult to digest the history of when that
could have happened. However, let's drop the reference counting to avoid
unnecessary code-paths and lockings.

Cc: Pierre Ossman 
Cc: Russell King 
Signed-off-by: Ulf Hansson 
Reviewed-by: Adrian Hunter 
Link: https://lore.kernel.org/r/20210212131610.236843-1-ulf.hansson@linaro.org