The mmc workqueue is an ordered workqueue, allowing only one work to
execute per given time. As this workqueue is used for card detection, the
conseqeunce is that cards will be detected one by one waiting for each
other.

Moreover, most of the time spent during card initialization is waiting for
the card's internal firmware to be ready. From a CPU perspective this
typically means waiting for a completion variable to be kicked via an
IRQ-handler or waiting for a sleep timer to finish.

This behaviour of detecting/initializing cards is sub-optimal, especially
for SOCs having several controllers/cards.

Let's convert to use the system_freezable_wq for the mmc detect works.
This enables several works to be executed simultaneously and thus also
cards to be detected like so.

Tests on UX500, which holds two eMMC cards and an SD-card (actually also
an SDIO card, currently not detected), shows a significant improved
behaviour due to this change.

Before this change, both the eMMC cards waited for the SD card to be
initialized as its detect work entered the workqueue first. In some cases,
depending on the characteristic of the SD-card, they got delayed 1-1.5 s.

Additionally for the second eMMC, it needed to wait for the first eMMC to
be initialized which added another 120-190 ms.

Converting to the system_freezable_wq, removed these delays and made both
the eMMC cards available far earlier in the boot sequence.

Selecting the system_freezable_wq, in favour of for example the system_wq,
is because we need card detection mechanism to be disabled once userspace
are frozen during system PM. Currently the mmc core deal with this via PM
notifiers, but following patches may utilize the behaviour of the
system_freezable_wq, to simplify the use of the PM notifiers.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Alan Cooper <alcooperx@gmail.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>

This patch introduce a new MMC_CAP2_NO_SDIO cap used to tell the mmc
core to not send SDIO specific commands.

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Turn the informative message about no vmmc/vqmmc regulator found in
debug one. There is no need to indicate that something optional is
missing. Moreover, it can bring confusion, people who doesn't know
it is optional may consider these messages as warnings or errors.

Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

_mmc_detect_card_removed() validates that the card is removable, but when
being called via the bus_ops ->detect() callbacks, the validation is
redundant as it's already done in mmc_rescan().

Move the validation of a removable card to the mmc_detect_card_removed()
API, which is where it's applicable, to allow the blk error recovery path
to get the response a bit earlier.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Instead of checking for "#ifdef" directly in the code, let's invent a pair
of mmc core functions to deal with register/unregister the MMC PM notifier
block. Implement stubs for these functions when CONFIG_PM_SLEEP is unset,
as in that case the PM notifiers isn't used.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

As mmc_claim_host() invokes pm_runtime_get_sync() for the mmc host device,
it's important that the host is kept claimed for *all* accesses to it via
the host_ops callbacks.

In mmc_rescan(), the ->card_event() and the ->get_cd() callback are being
invoked without claiming the host, let's fix this.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

The ->card_event() callback may be called when re-scan is disabled and for
non-removable cards, which both cases are unnecessary.

Instead let's move the call later in mmc_rescan() where these constraints
have been validated.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

This adds logic to the MMC core to set VQMMC.  This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.

A few notes:

* When setting the signal voltage to 3.3V we do our best to make VQMMC
  and VMMC match.  It's been reported that this makes some old cards
  happy since they were tested back in the day before UHS when VQMMC
  and VMMC were provided by the same regulator.  A nice side effect of
  this is that we don't end up on the hairy edge of VQMMC (2.7V),
  which some EEs claim is a little too close to the minimum for
  comfort.
  This is done in two steps. At first we try to find a VQMMC within
  a 0.3V tolerance of VMMC and if this is not supported by the
  supplying regulator we try to find a suitable voltage within the
  whole 2.7V-3.6V area of the spec.

* The two step approach is currently necessary, as the used
  regulator_set_voltage_triplet(min, target, max) uses a simple
  implementation that just tries two basic steps:
	regulator_set_voltage(target, max);
	regulator_set_voltage(min, target);
  So with only one step with 2.7-3.6V borders, if a suitable voltage
  is a bit below VMMC, we would directly get the lowest 2.7V
  which some boards (like Rockchips) don't like at all.

* When setting the signal voltage to 1.8V or 1.2V we aim for that
  specific voltage instead of picking the lowest one in the range.

* We very purposely don't print errors in mmc_regulator_set_vqmmc().
  There are cases where the MMC core will try several different
  voltages and we don't want to pollute the logs.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

We will shortly need the calculation of an ocr-bit to the actual
voltage in a second place too, so move it from mmc_regulator_set_ocr
to a common function mmc_ocrbitnum_to_vdd to make that possible.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

MMC_CLKGATE was once invented to save power by gating the bus clock at
request inactivity. At that time it served its purpose. The modern way to
deal with power saving for these scenarios, is by using runtime PM.

Nowadays, several host drivers have deployed runtime PM, but for those
that haven't and which still cares power saving at request inactivity,
it's certainly time to deploy runtime PM as it has been around for several
years now.

To simplify code to mmc core and thus decrease maintenance efforts, this
patch removes all code related to MMC_CLKGATE.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>