The intention of this check was to prevent the conflict between
hotplug and removing driver for whatever reason. Currently it
doesn't improve anything and the following rescan process could
still saftly perform the scan flow. So these code seems pointless
now and let's remove them.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add host capability MMC_CAP_CD_WAKE to enable irq wake on the card detect
irq.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The mmc_flush_cache() is a eMMC specific function, let's move it to
mmc_ops.c to make that clear.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The mmc_interrupt_hpi() is a eMMC specific function, let's move it to
mmc_ops.c to make that clear. The move also enables us to make
mmc_send_hpi_cmd() static, so let's do that change as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The mmc_start_bkops(), mmc_stop_bkops() and mmc_read_bkops_status()
functions are all specific to eMMCs. To make this clear, let's move them
from from core.c to mmc_ops.c and take the opportunity to make
mmc_read_bkops_status() static.

While moving them, get rid of MMC_BKOPS_MAX_TIMEOUT (4 min) and use the
common default timeout MMC_OPS_TIMEOUT_MS (10 min) instead, as there is no
need to have specific default timeout for bkops.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The mmc_start|stop_bkops(), mmc_read_bkops_status() and mmc_interrupt_hpi()
functions are all used from within the mmc core module, thus there are no
need to use EXPORT_SYMBOL() for them, so let's remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

In case if a pwrseq-emmc has been bound to the host, a call to
mmc_power_up() triggers an eMMC HW reset via the pwrseq_emmc's
->post_power_on() callback. This isn't really what we want, as
mmc_power_up() is called each time when resuming the card.

As a matter of fact, the current approach may also violate the eMMC spec,
as the involved delays managed in pwrseq_emmc assumes both VCC and VCCQ has
been turned on, which isn't the case for VCCQ, unless the regulator is
always on.

Fix this behaviour by aligning to the same procedure used when the mmc host
implements the ->hw_reset() callback and has the MMC_CAP_HW_RESET flag set.
In this way the eMMC HW reset is issued at card detection scan, to cope
with bogus bootloaders and in the error recovery path via the mmc specific
bus_ops->reset() callback.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>

Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSteven J. Hill <Steven.Hill@cavium.com>
Acked-by: NDavid Daney <david.daney@cavium.com>

The host may issue an I/O abort by writing to the CCCR at any time
during I/O read operation via CMD52. And host may need suspend
transcation during write busy stage in SDIO suspend/resume scenario.
>From other side, a card may accept CMD52 during data transfer phase.

Previous implement would block issuing above command in busy stage.
It cause function driver can't implement as proper way and has no
opportunity to do some coverage in error case via I/O abort etc.

We need bypass some necessary operation during busy check stage.
Signed-off-by: NJiajie Hao <jiajie.hao@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We have this construction:

if (a && b && !c)
   finalize;
else
   block;
   finalize;

Which is equivalent by boolean logic to:

if (!a || !b || c)
   block;
finalize;

Which is simpler code.
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_wait_for_data_req_done() is called in exactly one place,
and having it spread out is making things hard to oversee.
Factor this function into mmc_finalize_areq().
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

"previous" is a better name for the variable storing the previous
asynchronous request, better than the opaque name "data" atleast.
We see that we assign the return status to the returned variable
on all code paths, so we might as well just do that immediately
after calling mmc_finalize_areq().
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation to reuse the code for CQE support.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation to reuse the code for CQE support.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This function is doing to many clever things at the same time under
too many various conditions.

Start to make things clearer by refactoring: break out the
finalization of the previous asynchronous request to its own
function mmc_finalize_areq(). We can get rid of the default
assignment of status and let the call deal with this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

With the coexisting __mmc_start_request(), mmc_start_request()
and __mmc_start_req() it is a bit confusing that mmc_start_req()
actually does not start a normal request, but an asynchronous
request.

Rename it to mmc_start_areq() to make it explicit what the
function is doing, also fix the kerneldoc for this function
while we're at it.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

commit 64b12a68
"mmc: core: fix prepared requests while doing bkops"
is fixing a bug in the wrong way. A bug in the MMCI
device driver is fixed by amending the MMC core.

Thinking about it: what the pre- and post-callbacks
are doing is to essentially map and unmap SG lists
for DMA transfers. Why would we not be able to do that
just because a BKOPS command is sent inbetween?
Having to unprepare/prepare the next asynchronous
request for DMA seems wrong.

Looking the backtrace in that commit we can see what
the real problem actually is:

mmci_data_irq() is calling mmci_dma_unmap() twice
which is goung to call arm_dma_unmap_sg() twice
and v7_dma_inv_range() twice for the same sglist
and that will crash.

This happens because a request is prepared, then
a BKOPS is sent. The IRQ completing the BKOPS command
goes through mmci_data_irq() and thinks that a DMA
operation has just been completed because
dma_inprogress() reports true. It then proceeds to
unmap the sglist.

But that was wrong! dma_inprogress() should NOT be
true because no DMA was actually in progress! We had
just prepared the sglist, and the DMA channel
dma_current has been configured, but NOT started!

Because of this, the sglist is already unmapped when
we get our actual data completion IRQ, and we are
unmapping the sglist once more, and we get this crash.

Therefore, we need to revert this solution pushing
the problem to the core and causing problems, and
instead augment the implementation such that
dma_inprogress() only reports true if some DMA has
actually been started.

After this we can keep the request prepared during the
BKOPS and we need not unprepare/reprepare it.

Fixes: 64b12a68 ("mmc: core: fix prepared requests while doing bkops")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Earlier the mmc_set_signal_voltage() existed, but since it has been renamed
to mmc_set_uhs_voltage(), we can now use that name instead.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NJan Glauber <jglauber@cavium.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>

The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. To clarify this let's do the following changes.

- We are always providing MMC_SIGNAL_VOLTAGE_180 as the signal_voltage
  parameter to the function. Then, let's just remove the parameter as it
  serves no purpose.
- Rename the function to mmc_set_uhs_voltage().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NJan Glauber <jglauber@cavium.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>

The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. Therefore let's remove the redundant code dealing with
MMC_SIGNAL_VOLTAGE_330.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NJan Glauber <jglauber@cavium.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>

A significant amount of functions and other definitions are available
through the public mmc card.h header file. Let's slim down this public mmc
interface, as to prevent users from abusing it, by moving some of the
functions/definitions to private mmc header files.

This change concentrates on moving the functions into private mmc headers,
following changes may continue with additional clean-ups.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

In the MMC subsystem, we see such initializers that only clears the
first member explicitly.

For example,

  struct mmc_request mrq = {NULL};

sets the first member (.sbc) to NULL explicitly.  However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)

So, using a designated initializer is preferred coding style.  The
expression above is equivalent to:

  struct mmc_request mrq = { .sbc = NULL };

Of course, this does not express our intention.  We want to fill
all struct members with zeros.  Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.

After all, the most reasonable (and stable) form is:

  struct mmc_request mrq = {};

Do likewise for mmc_command, mmc_data as well.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Commit e0097cf5 ("mmc: queue: Fix queue thread wake-up") did not go far
enough. mmc_wait_for_data_req_done() still contains some problems and can
be further simplified.  First it should not touch
context_info->is_waiting_last_req because that is a wake-up control used by
the owner of the context. Secondly, it should always return when one of its
wake-up conditions is met because, again, that is contolled by the owner of
the context.

While the current block driver does not have an issue, these problems were
exposed during testing of the Software Command Queue patches.

Fixes: e0097cf5 ("mmc: queue: Fix queue thread wake-up")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NHarjani Ritesh <riteshh@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

BUG_ONs doesn't help anything except for stop the system from
running. If it occurs, it implies we should deploy proper error
handling for that. So this patch is gonna discard these meaningless
BUG_ONs and deploy error handling if needed.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The only time the driver sleeps expecting to be woken upon the arrival of
a new request, is when the dispatch queue is empty. The only time that it
is known whether the dispatch queue is empty is after NULL is returned
from blk_fetch_request() while under the queue lock.

Recognizing those facts, simplify the synchronization between the queue
thread and the request function. A couple of flags tell the request
function what to do, and the queue lock and barriers associated with
wake-ups ensure synchronization.

The result is simpler and allows the removal of the context_info lock.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHarjani Ritesh <riteshh@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The void (*pre_req) callback in the struct mmc_host_ops vtable
is passing an argument "is_first_req" indicating whether this is
the first request or not.

None of the in-kernel users use this parameter: instead, since
they all just do variants of dma_map* they use the DMA cookie
to indicate whether a pre* callback has already been done for
a request when they decide how to handle it.

Delete the parameter from the callback and all users, as it is
just pointless cruft.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In cases when a speed mode change is requested for mmc cards, a CMD6 is
sent by calling __mmc_switch() during the card initialization. The CMD6
leads to the card entering a busy period. When that is completed, the host
must parse the CMD6 status to find out whether the change of the speed mode
succeeded.

To enable the mmc core to poll the card by using CMD13 to find out when the
busy period is completed, it's reasonable to make sure polling is done by
having the mmc host and the mmc card, being configured to operate at the
same selected bus speed timing.

Therefore, let's extend __mmc_switch() to take yet another parameter, which
allow its callers to update the bus speed timing of the mmc host. In this
way, __mmc_switch() also becomes capable of reading and validating the CMD6
status by sending a CMD13, in cases when that's desired.

If __mmc_switch() encounters a failure, we make sure to restores the old
bus speed timing for the mmc host, before propagating the error code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

There were several instances of code using the
enum mmc_blk_status by arbitrarily converting it to an int and
throwing it around to different functions. This makes the code
hard to understand to may give rise to strange errors.

Especially the function prototype mmc_start_req() had to be
modified to take a pointer to an enum mmc_blk_status and the
function pointer .err_check() inside struct mmc_async_req
needed to return an enum mmc_blk_status.

In every case: instead of assigning the block layer error code
to an int, use the enum, also change the signature of all
functions actually passing this enum to use the enum.

To make it possible to use the enum everywhere applicable, move
it to <linux/mmc/core.h> so that all code actually using it can
also see it.

An interesting case was encountered in the MMC test code which
did not return a enum mmc_blk_status at all in the .err_check
function supposed to check whether asynchronous requests worked
or not: instead it returned a normal -ERROR or even the test
frameworks internal error codes.

The test code would also pass on enum mmc_blk_status codes as
error codes inside the test code instead of converting them
to the local RESULT_* codes.

I have tried to fix all instances properly and run some tests
on the result.

Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
Cc: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The MMC_CAP2_NO_PRESCAN_POWERUP was invented to avoid running the power up
sequence, mmc_power_up(), during ->probe() of the mmc host driver, but
instead defer this to the mmc detect work. This is especially useful for
those hosts that suffers from a long initialization time, as this time
would otherwise add up to the total boot time.

However, due to the introduction of runtime PM of mmc host devices in the
mmc core, this behaviour changed a bit. More precisely, it caused the mmc
core to runtime resume the host device during ->probe() of the host driver.
In cases like the rtsx_usb_sdmmc, runtime resuming the device may be costly
and thus affecting the total boot time.

To improve this behaviour when using MMC_CAP2_NO_PRESCAN_POWERUP, let's
postpone also calling mmc_power_off() when starting the host. This change
allows the mmc core to avoid runtime resuming the device, as it don't need
to claim the host for that execution path.

Cc: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Per spec, block size should always be 512 bytes for dual rate mode,
so any attempts to switch the block size under dual rate mode should
be neglected.
Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

A host controller driver exposes its capability using caps flag
MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests
that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the
upper layers when the command line is available for further commands by
calling mmc_command_done(). Because of that, the driver will not then
automatically send STOP commands, and it is the responsibility of the upper
layer to send a STOP command if it is required.

For requests submitted through the mmc_wait_for_req() interface, the caller
sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact
not to wait. The caller can then send commands that do not use the data
lines. Finally the caller can wait for the transfer to complete by calling
mmc_wait_for_req_done() which is now exported.

For requests submitted through the mmc_start_req() interface, the caller
again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does
not wait. The caller can then send commands that do not use the data
lines. Finally the caller can wait for the transfer to complete in the
normal way i.e. calling mmc_start_req() again.

Irrespective of how a cap_cmd_during_tfr request is started,
mmc_is_req_done() can be called if the upper layer needs to determine if
the request is done. However the appropriate waiting function (either
mmc_wait_for_req_done() or mmc_start_req()) must still be called.

The implementation consists primarily of a new completion
mrq->cmd_completion which notifies when the command line is available for
further commands. That completion is completed by mmc_command_done().
When there is an ongoing data transfer, calls to mmc_wait_for_req() will
automatically wait on that completion, so the caller does not have to do
anything special.

Note, in the case of errors, the driver may call mmc_request_done() without
calling mmc_command_done() because mmc_request_done() always calls
mmc_command_done().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In most cases the 'card->erase_size' is power of 2, then the round_up/down()
function is more efficient than '%' operation when the 'card->erase_size' is
power of 2.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Tested-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In order to clean up the mmc_erase() function and do some optimization
for erase size alignment, factor out the guts of erase size alignment
into mmc_align_erase_size() function.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Tested-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In cases when the host->max_busy_timeout isn't specified, the calculated
number of maximum discard sectors defaults to UINT_MAX. This may cause a
too long timeout for a discard request.

Avoid this by using a default maximum erase timeout of 60s, used when we
calculate the maximum number of sectors that are allowed to be discarded
per request.

Do note that the minimum number of sectors to be discarded is still at
least one "preferred erase size".
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

When mmc host HW supports busy signalling (using R1B as response), don't
use the host->max_busy_timeout as the limitation when deciding the max
discard sectors, which we inform the generic BLOCK layer about. Instead,
let's use at least one preferred erase size as the max discard sectors.

In cases when the host controller supports HW busy signalling and the
timeout for the erase operation doesn't exceed the max_busy_timeout, we
keep the R1B response, otherwise we prevent the host from doing HW busy
detection by converting to a R1 response.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Host drivers which needs to valdiate for non-supported MMC
commands and returnn error code for such requests.

To improve and simplify the behaviour, let's invent MMC_CAP2_NO_MMC
which these host drivers can set to tell the mmc core to skip sending MMC
commands during card initialization.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There are host drivers which needs to valdiate for non-supported SD
commands and returnn error code for such requests.

To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD
which these host drivers can set to tell the mmc core to skip sending SD
commands during card initialization.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase
size. As some high capacity eMMC (64MB) reports this size to 512kB, the
discard operations end up taking very long time.

Improve the behaviour by instead calculating the preferred erase size
based on the eMMC size. In this way the discard operations becomes faster.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
[Ulf: Updated changelog and improved comment in code]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NMatt Gumbel <matthew.k.gumbel@intel.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>