In order to support commands during data transfer, it will be possible
that host->data is not NULL when preparing a new request. Move a warning
that assumes otherwise.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In order to support commands during data transfer, there will have to be up
to two active requests (mrqs) at a time, instead of just one. That means
host->mrq will not be able to be used.

In several places, host->mrq is used when instead the mrq can be determined
from the cmd or data pointers. Reduce the use of host->mrq by doing that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Now that there is host->data_cmd to record the command for which a data
interrupt is expected, it is possible to determine whether a command with
busy signaling has completed without an extra flag. So host->busy_handle
is not needed. Remove it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In order to support commands during data transfer, there must be a
distinction between the command that is using the command line (and
for which a command interrupt is expected) and the command that is
using the data lines (for which a data interrupt is expected).

There is host->cmd for the command line, but there is only host->data
for the data lines, which is a different structure, does not represent
the command in use, and is anyway NULL in the case of commands that use
the data lines for busy signalling instead of data transfer.

Introduce host->data_cmd to record what command is using the data lines,
and use that instead of host->cmd when referring to the data command.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_finish_command() is going to set host->cmd to NULL. Simplify the
code by using a local variable to hold host->cmd and set host->cmd to
NULL at the start.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

BUG is never the right thing for SDHCI to do. Get rid of BUG_ON in cases it
will oops anyway if the pointer is NULL, or if the condition is logically
impossible.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In order to support commands during data transfer, command and data
handling needs to be untangled.

That means sdhci_finish_cmd() must not be called from the data IRQ
handler. It is being called because of busy signal handling, which
is treating the command as not finished until the busy signal is
released.

Instead, move busy signal handling from sdhci_cmd_irq() into
sdhci_finish_cmd(). Then the data IRQ handler does not need to call
sdhci_finish_cmd() and can instead finish the request.

What this means in practice for a command with busy signaling, is that
the command response is read from the host controller when the command
complete interrupt is received, thus freeing up the command circuit for
other commands.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add sdhci_read_caps() and __sdhci_read_caps() to make it easier for drivers
to fix the version and capabilities registers.

Pedantically, the SDHCI specification states that the capabilities
registers are valid when the host controller resets the Software Reset For
All bit. That requirement has always been satisfied by performing a reset
at the start of initialization, and consequently that is now part of the
new functions.

Although the SDHCI_QUIRK_MISSING_CAPS quirk has not yet been removed,
drivers that want to provide their own caps can now use these functions
instead of that quirk.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for adding a function to read the capability registers.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signal voltage support is not a quirk, it is a capability. According to the
SDHCI specification, support for 1.8V signaling is determined by the
presence of one of the capability bits SDHCI_SUPPORT_SDR50,
SDHCI_SUPPORT_SDR104, or SDHCI_SUPPORT_DDR50. This is complicated by also
supporting eMMC which has 1.8V modes and 1.2V modes. It would be possible
to use the transfer mode to determine signal voltage support, except for
eMMC DDR52 mode which uses the same capability (MMC_CAP_1_8V_DDR) for 1.8V
signaling and 3V signaling.

In addition, the mmc core will fail over from one signaling voltage to the
next (refer mmc_power_up()) which means SDHCI really needs to validate
which voltages are actually supported.

Introduce SDHCI flags for signal voltage support and set them based on the
supported transfer modes. In general, drivers should prefer to set the
supported transfer modes correctly rather than change the signal voltage
capability, except in the case where 3V DDR52 is supported but 1.8V is
not.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Split sdhci-add_host() in order to further our objective to make
sdhci into a library.

The split divides code that sets up mmc and sdhci parameters, from
code that actually activates things - such as tasklet initialization,
requesting the irq, and adding (and starting) the host.

This gives drivers an opportunity to change various settings before
committing to start the host.

Drivers can continue to call sdhci_add_host() but drivers that want
to take advantage of the split instead call sdhci_setup_host() followed
by __sdhci_add_host().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Drivers must be able to provide their own implementations for mmc host
operations. Consequently, SDHCI should call those not the default
implementations. Do that by calling indirectly through the mmc host ops
function pointers.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_dumpregs is used to dump registers when error happens. Thus it should
use pr_err instead of pr_debug to show more information about the hardware.
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
[Fix whitespace and checkpatch warnings]
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In linux/mmc/host.h, mmc_card_is_removable() is already defined.
It should be maintainted more easier than now.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

host->card_busy() was introduced for SD voltage switching which checks all
4 data lines.

Increasingly, host->card_busy is being used to poll the the busy signal
which is only data line 0 (DAT[0]).

The current logic in sdhci_card_busy() does not work in that case because
it returns false if any of the data lines is high.  It also ignores
possibilities:
	- data lines 1-3 are not connected and could show at any level
	- data lines 1-2 can be used by SDIO for other purposes

According to the SD specification, it is OK to check any of the data lines
for voltage switching, so change to use DAT[0] only.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Activating wakeup event is not enough to get a wakeup signal. The
corresponding events have to be enabled in the Interrupt Status Enable
Register too. It follows the specification and is needed at least by
sdhci-of-at91.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since commit 7ce45e95 ("mmc: sdhci: SD tuning is broken for some
controllers") sdhci_execute_tuning() no longer includes a timeout in its
loop counter(s) so remove portion of the comment regarding this.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After commit d6463f170cf0 ("mmc: sdhci: Remove redundant runtime PM calls"),
some of original sdhci_do_xx() function wrappers becomes meaningless,
so remove them.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \
    defined(CONFIG_MMC_SDHCI_MODULE))

is equivalent to:

defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \
    defined(MODULE))

and it can also be written shortly as:

IS_REACHABLE(CONFIG_LEDS_CLASS)
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>

SDHCI_SDR104_NEEDS_TUNING was originally named SDHCI_HS200_NEEDS_TUNING
and was added in commit 069c9f14 ("mmc: host: Adds support for eMMC
4.5 HS200 mode").

That commit conflated SDHCI_SDR50_NEEDS_TUNING and SDHCI_HS200_NEEDS_TUNING
due to what appears to be misplaced parentheses.

Commit 156e14b1 ("mmc: sdhci: fix caps2 for HS200") made HS200
configuration equivalent to SDR104 configuration, renaming
SDHCI_HS200_NEEDS_TUNING to SDHCI_SDR104_NEEDS_TUNING despite tuning for
HS200 now being non-optional.

The mix-up with SDHCI_SDR50_NEEDS_TUNING remained and became more obvious
after commit 4b6f37d3 ("mmc: sdhci: clean up sdhci_execute_tuning()
decision") where the author noted the patch was "reflecting what the
original code was doing, it shows that it may not be what the author
actually intended."

The way the code is currently written, SDHCI_SDR104_NEEDS_TUNING
causes tuning to be done always for SDR50 mode if SDR104 mode is
also supported by the host controller.  That makes no sense because
we already have capabilities bit SDHCI_USE_SDR50_TUNING and
corresponding flag SDHCI_SDR50_NEEDS_TUNING for that purpose.

Given the dubious origins of SDHCI_SDR104_NEEDS_TUNING, it seems
reasonable to remove it.  The benefit being SDR50 mode will now not
un-nessessarily do tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

ifdef's make the code more complicated and harder to read.
Move all the LED code together to reduce the ifdef's to
one place.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some error paths in sdhci_add_host() simply returned without
cleaning up.  Also the return value from mmc_add_host()
was not being checked.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The logic '!mmc.f_max || (mmc.f_max && mmc.f_max > max_clk)'
is equivalent to '!mmc.f_max || mmc.f_max > max_clk'.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk is not used anymore so
remove it.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In order to remove the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST and to
reduce code duplication, put the code relative to the SD clock
configuration in a function which can be used by hosts for the
implementation of the ->set_clock() callback.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There are no need to have two versions of sdhci_runtime_pm_bus_off|on(),
depending on whether CONFIG_PM is set or unset. Thus it's easy to move the
implementation of these functions a bit earlier to avoid the unnecessary
pre-definition of them, so let's do that.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

Commit 9250aea7 ("mmc: core: Enable runtime PM management of host
devices"), made some calls to the runtime PM API from the driver
redundant. Especially those which deals with runtime PM reference
counting, so let's remove them.

Moreover as SDHCI have its own wrapper functions for runtime PM these
becomes superfluous, so let's remove them as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.

Krzysztof Kozlowski reported that after commit 918f4cbd ("mmc:
sdhci: restore behavior when setting VDD via external regulator")
on Trats2 board there are warnings for invalid VDD  value (2.8V):

[    3.119656] ------------[ cut here ]------------
[    3.119666] WARNING: CPU: 3 PID: 90 at
../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
[    3.119669] mmc0: Invalid vdd 0x10
[    3.119673] Modules linked in:
[    3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G        W
   4.5.0-next-20160324 #23
[    3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    3.119690] Workqueue: events_freezable mmc_rescan
[    3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
(show_stack+0x10/0x14)
[    3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
(dump_stack+0x88/0x9c)
[    3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
[    3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
(warn_slowpath_fmt+0x38/0x48)
[    3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
(sdhci_do_set_ios+0x4cc/0x5e0)
[    3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
(sdhci_runtime_resume_host+0x60/0x114)
[    3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
[<c0402570>] (__rpm_callback+0x2c/0x60)
[    3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
(rpm_callback+0x20/0x80)
[    3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
(rpm_resume+0x36c/0x558)
[    3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
(__pm_runtime_resume+0x4c/0x64)
[    3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
(__mmc_claim_host+0x170/0x1b0)
[    3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
(mmc_rescan+0x54/0x348)
[    3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
(process_one_work+0x120/0x3f4)
[    3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
(worker_thread+0x38/0x554)
[    3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
(kthread+0xdc/0xf4)
[    3.119831] [<c01365a4>] (kthread) from [<c0107878>]
(ret_from_fork+0x14/0x3c)
[    3.119834] ---[ end trace a22d652aa3276886 ]---

Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd ("mmc: sdhci: restore
behavior when setting VDD via external regulator").  The desired
behaviour of that commit is gotten by having sdhci-pxav3 provide
its own set_power callback.
Reported-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
Fixes: 918f4cbd ("mmc: sdhci: restore behavior when setting VDD...)
Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NAnand Moon <linux.amoon@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Set the DMA mask in sdhci_add_host() after we determined the
capabilities of the device. 64-bit devices in particular are given the
proper mask that ensures bounce buffers are not used.

Also disable DMA if no proper DMA mask can be set, as the DMA-API
documentation specifies.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Normally the timeout clock frequency is read from the capabilities
register.  It is also possible to set the value prior to calling
sdhci_add_host() in which case that value will override the
capabilities register value.  However that was being done after
calculating max_busy_timeout so that max_busy_timeout was being
calculated using the wrong value of timeout_clk.

Fix that by moving the override before max_busy_timeout is
calculated.

The result is that the max_busy_timeout and max_discard
increase for BSW devices so that, for example, the time for
mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
to about 20 seconds.

Note, in the future, the capabilities setting will be tidied up
and this override won't be used anymore.  However this fix is
needed for stable.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Further simplify the code in sdhci_prepare_data() - we don't set
SDHCI_REQ_USE_DMA anywhere else in the driver, so there is no
need to set it, and then immediately test it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Rather than scanning the scatterlist multiple times for each quirk,
scan it once, checking for each possible quirk.  This should be
cheaper due to the length and offset members commonly sharing the
same cache line than scanning the scatterlist multiple times.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Prepare to consolidate the DMA address/size quirk handling into one
single loop.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The patch "mmc: sdhci: plug DMA mapping leak on error" added
un-mapping logic to sdhci_tasklet_finish() where it is always
called, thereby preventing the mapping leaking.

Consequently the un-mapping code in sdhci_finish_data() is no
longer needed.  Remove it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
[ Split from original "mmc: sdhci: plug DMA mapping leak on error" patch ]
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Commit d31911b9 ("mmc: sdhci: fix dma memory leak in sdhci_pre_req()")
added a complicated method to manage the DMA map state for the data
transfer, but this complexity is not required.

There are three states:
* Unmapped
* Mapped by sdhci_pre_req()
* Mapped by sdhci_prepare_data()

sdhci_prepare_data() needs to know when the data buffers have been
successfully mapped by sdhci_pre_req(), and if so, there is no need to
map them a second time.

When we come to tear down the mapping, we want to know whether
sdhci_post_req() will be called (which is determined by sdhci_pre_req()
having been previously called) so that we can postpone the unmap
operation.

Hence, it makes sense to simply record when the successful DMA map
happened (via COOKIE_PRE_MAPPED vs COOKIE_MAPPED) rather than having
the complex mechanics involving COOKIE_MAPPED vs COOKIE_GIVEN.

If a mapping is created by sdhci_prepare_data(), we must tear it down
ourselves, without waiting for sdhci_post_req() (hence, the new
COOKIE_MAPPED case).  If the mapping is created by sdhci_pre_req()
then sdhci_post_req() is responsible for tearing the mapping down.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If the host cookie indicates that the data buffers of a request are
mapped at sdhci_post_req() time, always unmap the data buffers.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Pass the desired cookie for a successful map.  This is in preparation to
clean up the MAPPED/GIVEN states.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In sdhci_prepare_data(), when SDHCI_REQ_USE_DMA is set, there are two
paths that prepare the data buffers for transfer.  One is when
SDHCI_USE_ADMA is set, and is located inside sdhci_adma_table_pre().
The other is when SDHCI_USE_ADMA is clear, in the else clause of the
above.

Factor out the call to sdhci_pre_dma_transfer() along with its error
checking.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Move sdhci_pre_dma_transfer() to avoid needing to declare this function
before use.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>