Fix the compile error.
(Removed the card_tasklet at "mmc: sdhci: push card_tasklet into treaded irq handler")

drivers/mmc/host/sdhci-s3c.c: In function ‘sdhci_s3c_notify_change’:
drivers/mmc/host/sdhci-s3c.c:402:25: error: ‘struct sdhci_host’ has no member named ‘card_tasklet’

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller
in both PIO and DMA modes.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Signed-off-by: Chris Ball <chris@printf.net>

The commit below introduced compile errors, let's fix them.
mmc: sdhci-of-esdhc: remove platform_suspend/platform_resume callbacks

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Tegra SDHCI controllers, by default, report a base clock frequency of
208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the actual
base clock frequency.  This is because the clock rate is configured by
the clock controller, which is external to the SD/MMC controller.  Since
the SD/MMC controller has no knowledge of how this clock is configured,
it will simply report the maximum frequency.  While the reported value
can be overridden by setting BASE_CLK_FREQ in VENDOR_CLOCK_CTRL on
Tegra30 and later SoCs, just set CAP_CLOCK_BASE_BROKEN and supply
sdhci_pltfm_clk_get_max_clock(), which simply does a clk_get_rate(),
as the get_max_clock() callback.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Program TEGRA_SDHCI_VENDOR_MISC_CTRL so that UHS modes aren't advertised
in SDHCI_CAPABILITIES_1.  While the Tegra SDHCI controller does support
these modes, they require Tegra-specific tuning and calibration routines
which the driver does not support yet.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

f8ec589b ("mmc: sdhci-dove: allow GPIOs to be used for card detection
on Dove" added a gpio based card detect interrupt handler that was hooked
up into card_tasket.

3560db8e

 ("mmc: sdhci: push card_tasklet into threaded irq handler")
now removed that very card_tasklet causing sdhci-dove to fail on build
with:
drivers/mmc/host/sdhci-dove.c: In function 'sdhci_dove_carddetect_irq':
drivers/mmc/host/sdhci-dove.c:42:24: error: 'struct sdhci_host' has no member named 'card_tasklet'

To fix both the build error and get a working gpio card detection without
card_tasklet, replace sdhci_get_of_property() with more recent
mmc_of_parse(). It takes care of gpio-based card detect passed through DT
already and allows to remove the offending code sections dealing with
removed card_tasklet.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

This tree has already been added to Stephen Rothwell's list for
linux-next. Make it visible in the MAINTAINERS file as well.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in
mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is
a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

The SD Host Controller spec states that the SD Host Controller can
request that the driver send up to 40 CMD19's while doing tuning
and that the total time the card spends responding must be < 150ms.
The sdhci_execute_tuning() function in sdhci.c that loops through
sending the CMD19's has multiple bugs. First it sets a "timeout"
variable to 150 and a loop counter variable to 40. It then decrements
both variables by 1 at the end of each loop. It tries to handle
violations of the count and time by doing a break when BOTH variables
are equal to zero, which can never happen because they we set to
different values and decremented by 1 at the same time. The timeout
variable is not based on time at all and is totally useless.
The routine also considers a loop counter of zero to be an error
which means that any controller that requests the max of 40 CMD19s
will cause tuning to fail and be disabled.

I've fixed these issues by allowing up to 40 CMD19's and I've removed
any attempt to handle the 150ms time limit. Removing timeout checking
seems safe here because each CMD19 is timeout protected and the max
loop counters insures we don't loop forever. Adding timeout checking
would not be as simple as snapping the time at the loop start and
checking for 150ms to pass because the loop queues the CMD19's and
uses events to wait for completion so the time would include
all the normal scheduler latencies.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

It's caused by the platform driver was still using MMC_TIMING_UHS_DDR50
for MMC DDR mode which needs update too.

Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
Reported-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Add O2Micro/BayHubTech chip 8520 subversion B1 SD3.0 support.
Add O2Micro/BayHubTech chip 8620 and 8621 SD3.0 support
Enable Led function of 8520 chip.

Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

moving dmaengine consumer specific function to omap-dmaengine.h
to Resolve build failure seen with sh-allmodconfig:
    include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
    make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1

Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Check for set block count command fails always since host->cmd is set
to NULL in the same function incorrectly. Correct host->cmd usage properly.

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

With devm_ioremap_resource conversion release_mem_region, iounmap can be
removed in clean up path

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

With devm_request_threaded_irq conversion free_irq can be removed
in clean up path

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

With devm_request_irq conversion free_irq can be removed in clean up path

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

With devm_clk_get conversion clk_put can be removed in clean up path

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in
designware idmac controller, which is identical to the one found in the
mmc-dw hosts. However the rest of the host is not identical to mmc-dw, it
deals with sending stop commands in hardware which makes it significantly
different from the mmc-dw devices.

Signed-off-by: David Lanzendörfer <david.lanzendoerfer@o2s.ch>
[hdegoede@redhat.com: various cleanups and fixes]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Also uses NSEC_PER_SEC and USEC_PER_SEC instead of hard-coded value.
This makes the intention more clear.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Data errors are completely expected during tuning.  Printing them out
is confusing people looking at the kernel logs.  They see things like:

 [    3.613296] dwmmc_exynos 12200000.dwmmc0: data error, status 0x00000088

...and they think something is wrong with their hardware.

Remove the printouts.  We'll leave it up to a higher level to report
about errors.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Track whether preset mode is currently enabled in hardware, and use that
when making decisions elsewhere in the code rather than reading the
register and checking the bit.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Move the remaining parts of the power handling in sdhci_do_set_ios()
into sdhci_set_power().

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Move the regulator handling into sdhci_set_power() rather than being in
sdhci_do_set_ios().  This wraps all power control up into this function.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

sdhci-tegra provides a get_ro method, which overrides the checking
of the write protect bit in the PRESENT_STATE register in sdhci.c:

        if (host->flags & SDHCI_DEVICE_DEAD)
                is_readonly = 0;
        else if (host->ops->get_ro)
                is_readonly = host->ops->get_ro(host);
        else
                is_readonly = !(sdhci_readl(host, SDHCI_PRESENT_STATE)
                                & SDHCI_WRITE_PROTECT);

This means it's pointless detecting accesses to this register and
manually setting the SDHCI_WRITE_PROTECT as it has no effect.

This means that the whole of tegra_sdhci_readl() can be removed and
we can use the builtin sdhci readl functionality here.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets
remove them to discourage any further use.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

We don't need these hooks in order to insert code in these paths, we
can just provide our own handlers and call the main sdhci handlers as
appropriate.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

We no longer need to emulate the uhs_mode field of the host control2
register - the main sdhci driver never reads this back to evaluate
the current mode as it caches the current mode instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Clean up the code in sdhci_execute_tuning() so the decision whether
to execute tuning is clearer - and despite this reflecting what the
original code was doing, it shows that it may not be what the author
actually intended.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Rather than reading back the timing information from the registers,
cache it locally.  This allows implementations to translate the UHS
timing by overriding the set_uhs_signaling() method as required
without also having to emulate the SDHCI_HOST_CONTROL2 register.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling
method.  This avoids quirks being added into sdhci_set_uhs_signaling().

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

The set_uhs_signaling() method gives the impression that it can fail,
but anything returned from the method is entirely ignored by the sdhci
driver.  So returning failure has no effect.

So, kill the idea that it's possible for this to return an error by
removing the returned value.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

=================================
[ INFO: inconsistent lock state ]
3.14.0-rc1+ #490 Not tainted
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
kworker/u8:0/6 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&host->lock)->rlock#2){?.-...}, at: [<c04b57a4>] esdhc_send_tuning_cmd+0x104/0x14c
{IN-HARDIRQ-W} state was registered at:
  [<c00652fc>] mark_lock+0x15c/0x6f8
  [<c0066354>] __lock_acquire+0xabc/0x1ca0
  [<c0067ad8>] lock_acquire+0xa0/0x130
  [<c0697a44>] _raw_spin_lock+0x34/0x44
  [<c04b0dbc>] sdhci_irq+0x20/0xa40
  [<c0071b1c>] handle_irq_event_percpu+0x74/0x284
  [<c0071d70>] handle_irq_event+0x44/0x64
  [<c0074db8>] handle_fasteoi_irq+0xac/0x140
  [<c007147c>] generic_handle_irq+0x28/0x38
  [<c000efd4>] handle_IRQ+0x40/0x98
  [<c0008584>] gic_handle_irq+0x30/0x64
  [<c0013144>] __irq_svc+0x44/0x58
  [<c0028fc8>] irq_exit+0xc0/0x120
  [<c000efd8>] handle_IRQ+0x44/0x98
  [<c0008584>] gic_handle_irq+0x30/0x64
  [<c0013144>] __irq_svc+0x44/0x58
  [<c068f398>] printk+0x3c/0x44
  [<c03191d0>] _regulator_get+0x1b4/0x1e0
  [<c031924c>] regulator_get+0x18/0x1c
  [<c049fbc4>] mmc_add_host+0x30/0x1c0
  [<c04b2e10>] sdhci_add_host+0x804/0xbbc
  [<c04b5318>] sdhci_esdhc_imx_probe+0x380/0x674
  [<c036d530>] platform_drv_probe+0x20/0x50
  [<c036b948>] driver_probe_device+0x120/0x234
  [<c036baf8>] __driver_attach+0x9c/0xa0
  [<c036a04c>] bus_for_each_dev+0x5c/0x90
  [<c036b418>] driver_attach+0x24/0x28
  [<c036b018>] bus_add_driver+0xe4/0x1d8
  [<c036c1b0>] driver_register+0x80/0xfc
  [<c036ce28>] __platform_driver_register+0x50/0x64
  [<c093706c>] sdhci_esdhc_imx_driver_init+0x18/0x20
  [<c0008834>] do_one_initcall+0x3c/0x164
  [<c0901c94>] kernel_init_freeable+0x104/0x1d0
  [<c068c45c>] kernel_init+0x10/0x118
  [<c000e768>] ret_from_fork+0x14/0x2c
irq event stamp: 5933
hardirqs last  enabled at (5933): [<c069813c>] _raw_spin_unlock_irqrestore+0x38/0x4c
hardirqs last disabled at (5932): [<c0697b04>] _raw_spin_lock_irqsave+0x24/0x60
softirqs last  enabled at (5914): [<c0028ba0>] __do_softirq+0x260/0x360
softirqs last disabled at (5909): [<c0028fc8>] irq_exit+0xc0/0x120

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&host->lock)->rlock#2);
  <Interrupt>
    lock(&(&host->lock)->rlock#2);

 *** DEADLOCK ***

2 locks held by kworker/u8:0/6:
 #0:  (kmmcd){.+.+.+}, at: [<c003d890>] process_one_work+0x134/0x4e8
 #1:  ((&(&host->detect)->work)){+.+.+.}, at: [<c003d890>] process_one_work+0x134/0x4e8

stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc1+ #490
Workqueue: kmmcd mmc_rescan
Backtrace:
[<c00124a0>] (dump_backtrace) from [<c0012640>] (show_stack+0x18/0x1c)
[<c0012628>] (show_stack) from [<c069164c>] (dump_stack+0x70/0x8c)
[<c06915dc>] (dump_stack) from [<c068f080>] (print_usage_bug+0x274/0x2e4)
[<c068ee0c>] (print_usage_bug) from [<c0065774>] (mark_lock+0x5d4/0x6f8)
[<c00651a0>] (mark_lock) from [<c0065e6c>] (__lock_acquire+0x5d4/0x1ca0)
[<c0065898>] (__lock_acquire) from [<c0067ad8>] (lock_acquire+0xa0/0x130)
[<c0067a38>] (lock_acquire) from [<c0697a44>] (_raw_spin_lock+0x34/0x44)
[<c0697a10>] (_raw_spin_lock) from [<c04b57a4>] (esdhc_send_tuning_cmd+0x104/0x14c)
[<c04b56a0>] (esdhc_send_tuning_cmd) from [<c04b582c>] (esdhc_executing_tuning+0x40/0x100)
[<c04b57ec>] (esdhc_executing_tuning) from [<c04afa54>] (sdhci_execute_tuning+0xcc/0x754)
[<c04af988>] (sdhci_execute_tuning) from [<c04a4684>] (mmc_sd_init_card+0x65c/0x694)
[<c04a4028>] (mmc_sd_init_card) from [<c04a48f0>] (mmc_attach_sd+0xb0/0x184)
[<c04a4840>] (mmc_attach_sd) from [<c049eb28>] (mmc_rescan+0x26c/0x2e8)
[<c049e8bc>] (mmc_rescan) from [<c003d914>] (process_one_work+0x1b8/0x4e8)
[<c003d75c>] (process_one_work) from [<c003e090>] (worker_thread+0x13c/0x3f8)
[<c003df54>] (worker_thread) from [<c00449bc>] (kthread+0xcc/0xe8)
[<c00448f0>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

It is far from obvious what this is doing, and it looks like it's an
unbalanced runtime_pm_get() call.  However, the put is inside
sdhci_tasklet_finish(), so it's not unbalanced at all.  This should
be documented so people know what's going on here.  Do so.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

sdhci-esdhc-imx tries to DMA to the kernel stack when tuning the
interface, which causes dma-debug to complain.  Fix this by kmallocing
a buffer to hold the received tuning pattern.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Move the setting of mmc->actual_clock to zero into the set_clock
handlers themselves.  This will allow us to clean up the calling
logic for the set_clock() method, and turn sdhci_set_clock() into
a library function.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

We don't need implementations to do this, since the only time it's
necessary is when we change the clock, and the only place that happens
is in sdhci_do_set_ios().  So, move it there, and remove it from the
iMX platform backend.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Only one caller to sdhci_set_clock() needs to check whether the
requested clock frequency was the same as the currently set frequency,
yet we work around this in several other sites via sdhci_update_clock().
Rather than doing this, move those checks out into sdhci_do_set_ios(),
which then allows sdhci_update_clock() to be eliminated.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

Rather than using the streaming API, use the coherent allocator to
provide this memory, thereby eliminating cache flushing of it each
time we map and unmap it.  This results in a 7.5% increase in
transfer speed with a UHS-1 card operating in 3.3v mode at a clock
of 49.5MHz.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>