This macro is currently unused, but it may be useful for debug use.
Fix it just in case.

Fixes: ff6af28f ("mmc: sdhci-cadence: add Cadence SD4HC support")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Adding dedicated flag for AUTO_BKOPS in card->ext_csd structure.
Read AUTO_BKOPS bit value from the device EXT_CSD and set to the
card->ext_csd structure.
In mmc_decode_ext_csd() add a print message in case the AUTO_BKOPS
is enabled
Signed-off-by: NUri Yanai <uri.yanai@sandisk.com>
Signed-off-by: NAlex Lemberg <alex.lemberg@sandisk.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Inverse the logic for printing the debug message.
In mmc_decode_ext_csd() print message when MAN_BKOPS_EN is set
Signed-off-by: NUri Yanai <uri.yanai@sandisk.com>
Signed-off-by: NAlex Lemberg <alex.lemberg@sandisk.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add support for HS400 mode.

The driver still misses support for tuning, therefore
highspeed modes like HS400 might not work under all
circumstances yet.

Successfully tested on a Odroid C2 (S905 GXBB).
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Tested-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The remove callback is called only if probe finished successfully.
Therefore these checks are not needed.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Tested-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

A bounce buffer of 512K isn't needed as the max request size is
511 * 512 byte.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Tested-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

So far max_blk_count isn't set what results in a default of value 8
to be used (PAGE_SIZE / block size).

Block length field has 9 bits, so set max_blk_count to 2^9-1 = 511.
In addition set max_req_size because max_blk_count is also limited
by max_req_size / block_size.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Tested-by: NKevin Hilman <khilman@baylibre.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Disabling and immediately re-enabling interrupts in meson_mmc_request
doesn't provide a benefit. Instead enable interrupts in probe already.
And disable interrupts in remove, this was missing so far.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove unneeded variable ret and simplify the if block.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The following changes are quite small, therefore I combined them in
one patch.

- ret doesn't need to be initialized with 0
- use standard !clk_rate notation to check for a zero value
- If clk_rate is zero we return here. Therefore all further checks
  in this function for clk_rate != 0 are not needed.
- switch from dev_warn to dev_err if the clock can't be set
- If due to clock source and available divider values the requested
  frequency isn't matched exactly (always the case if requested
  frequency is 52 MHz), then just print the differing values as
  debug message and not as warning.
- Also remove ret from the message as it is always 0.
- Set member current_clock to the current requested rate and
  mmc->actual_clock to the current actual rate
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

val isn't used in the switch clause and afterwards there's an
identical statement. So remove it.

In case of an unexpected bus width the error message indicates
the intention to set the bus width to 4 and to go on.
So remove the return statement. This return statement also
conflicts with "setting to 4" because nothing would be set
actually before returning. 4bit bus width are chosen as
default as the vendor driver does it too.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The current code dealing with calculating mmc->f_min is a bit complicated.
Additionally, the attempt to set an initial clock rate should explicitly
use a rate between 100KHz to 400 KHz, according the (e)MMC/SD specs, which
it doesn't.

Fix the problem and clean up the code by using clk_round_rate() to pick the
nearest minimum rate to 400KHz (rounded down from 400kHz).
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
[Heiner: Changed from 100KHz to 400KHz to get a proper rounded rate]
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>

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>

The return value from blk_end_request() is a bool but is
treated like an int. This is generally safe, but the variable
also has the opaque name "ret" and gets returned from the
helper function mmc_blk_cmd_err().

- Switch the variable to a bool, applies everywhere.

- Return a bool from mmc_blk_cmd_err() and rename the function
  mmc_blk_rw_cmd_err() to indicate through the namespace that
  this is a helper for mmc_blk_issue_rw_rq().

- Rename the variable from "ret" to "req_pending" inside the
  while() loop inside mmc_blk_issue_rq_rq(), which finally
  makes it very clear what this while loop is waiting for.

- Augment the argument "ret" to mmc_blk_rq_cmd_err() to
  old_req_pending so it becomes evident that this is an
  older state, and it is returned only if we fail to get
  the number of written blocks from an SD card in the
  function mmc_sd_num_wr_blocks().

- Augment the while() loop in mmc_blk_rq_cmd_abort(): it
  is evident now that we know this is a bool variable,
  that the function is just spinning waiting for
  blk_end_request() to return false.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_sd_num_wr_blocks() has an interesting construction that
saves one return argument by casting (u32)-1 as error code
if something goes wrong.

This is however a bit confusing when the normal kernel
pattern is to return an int error code on success.

So instead pass a variable "blocks" that the function can
fill in with the number of successfully transferred blocks
and return an integer as error code.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
[Ulf: Changed a return code to -EIO, reported by Dan Carpenter and fixed
by Linus Walleij]

Commit 577fb131 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb131 ("mmc: rework selection of bus speed mode")
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Instead of masking and setting two bits in the "flags" field
for the mmc_queue, just use two bools named "suspended" and
"new_request".

The masking and setting would likely have race conditions
anyways, it is better to use a simple member like this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The mmc_active member of struct mmc_queue_req has a very
confusing name: this is certainly not always "active", it is
the asynchronous request associated by the mmc_queue_req
but it is not guaranteed to be "active" in any sense, such
as being running on the host.

Simply rename this member to "areq".
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The mmc_blk_rw_start_new() was named after the label inside
mmc_blk_issue_rw_rq() but is really a confusing name for this
function: what it does is to try to restart the latest issued
command on the host and card of the current MMC queue.

So rename it mmc_blk_rw_try_restart() that reflects what it
is doing and at this point also refactore the function to
treat the removed card as an exception and just exit if this
happens and run on in the function if that is not happening.
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>

In the function mmc_blk_issue_rw_rq() the new request coming in
from the block layer is called "rqc" and the old request that
was potentially just returned back from the asynchronous
mechanism is called "req".

This is really confusing when trying to analyze and understand
the code, it becomes a perceptual nightmare to me. Maybe others
have better parserheads but it is not working for me.

Rename "rqc" to "new_req" and "req" to "old_req" to reflect what
is semantically going on into the syntax.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The goto statements sprinkled over the mmc_blk_issue_rw_rq()
function has grown over the years and makes the code pretty hard
to read.

Inline the calls such that:

goto cmd_abort; ->
mmc_blk_rw_cmd_abort(card, req);
mmc_blk_rw_start_new(mq, card, rqc);
return;

goto start_new_req; ->
mmc_blk_rw_start_new(mq, card, rqc);
return;

After this it is more clear how we exit the do {} while
loop in this function, and it gets possible to split the
code apart.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

ida code in block.c can be significantly simplified by switching to
the ida_simple_ functions.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Fixes: a45c6cb8 ("[ARM] 5369/1: omap mmc: Add new omap
hsmmc controller for 2430 and 34xx, v3")

when using really large timeout (up to 4*60*1000 ms for bkops)
there is a possibility of data overflow using
unsigned int so use 64 bit unsigned long long.
Signed-off-by: NRavikumar Kattekola <rk@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

commit e2bf08d6 ("omap_hsmmc: set a large data timeout for
commands with busy signal") sets an arbitrary timeout value (100ms) for
commands like CMD6 (MMC SWITCH). However extended CSD register defined
in the eMMC standard has a field for GENERIC_CMD6_TIME which indicates
the default maximum timeout for a SWITCH command.
Use busy_timeout of cmd structure (populated with GENERIC_CMD6_TIME
in the case of SWITCH command) to program the data timeout value in
omap_hsmmc driver.
SWITCH command to turn the cache on took more than 100ms to complete
with MICRON eMMC card present in AM572x IDK REV 1.3A resulting in
timeout and failed enumeration. It is fixed here by programming the
timeout with the value advertised in GENERIC_CMD6_TIME.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NRavikumar Kattekola <rk@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When CEB (command end bit error) occurs
reset CMD line to avoid system ending up in
erroneous state.
While command line is reset for CTO and CCRC errors,
it's not done for CEB error. Fix it here.
Reviewed-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NRavikumar Kattekola <rk@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When deploying runtime PM, it's quite verbose to print the
log of ios setting. Also it's useless to print it from system
PM as it should be the same with booting time. We also have
sysfs to get all these information from ios attribute, so let's
skip this print from PM context.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
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>

Add a bit more debug messages that can be helpful when debugging the clock
setup.

Also fill the actual_clock field in struct mmc_host to report properly the
current frequency in debugfs.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The MMC2 controller on the A64 is kind of a special beast.

While the general controller design is the same than the other MMC
controllers in the SoC, it also has a bunch of features and changes that
prevent it to be driven in the same way.

It has for example a different bus width limit, a different maximum
frequency, and, for some reason, the maximum buffer size of a DMA
descriptor.

Add a new compatible specifically for this controller.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The A64 MMC controllers need DATA0 to be masked while updating the clock,
otherwise any subsequent command will result in a timeout.

It's not really clear at this point what DATA0 is exactly, but this
behaviour is present in Allwinner's tree, and has been suggested by
Allwinner engineers as fixes for the timeout.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The A64 MMC controllers need to set a "new timings" bit when a new rate is
set.

The actual meaning of that bit is not clear yet, but not setting it leads
to some corner-case issues, like the CMD53 failing, which is used to
implement SDIO packet aggregation.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Experience have shown that the using the  autocalibration could severely
degrade the performances of the MMC bus.

Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
Remove the calibration code for now, and add comments to document our
findings.
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The MMC core assumes that the code will gate the clock when the bus
frequency is set to 0, which we've been ignoring so far.

Handle that.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The SD specification documents that the clock frequency should only be
changed once gated (Section 3.2.3 - SD Clock Frequency Change Sequence).

The current code first modifies the parent clock, gates it and then
modifies the internal divider. This means that since the parent clock rate
might be changed, the bus clock might be changed as well before it is
gated, which breaks the specification.

Move the gating before the parent rate modification.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NFlorian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Properly reverse everything if mmc_gpio_alloc(host) fails.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

ida handling can be simplified by switching to the ida_simple_
functions.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This removes CDC init sequence comments which are
not useful anyway.
Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

platform_execute_tuning should not really exist as it does not
do anything useful.

So remove this ops and directly plug sdhci_msm_execute_tuning
with mmc_host_ops.

Also in case of HS400 tuning clear SDHCI_HS400_TUNING flag once
HS400 related mode selection is done.
Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When mmc_of_parse() finds the binding, it sets the mmc cap,
MMC_CAP_3_3V_DDR, which informs the core whether eMMC DDR at 3.3V I/O is
supported by the mmc host.
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>