This function is used by the block layer queue to bail out of
requests if the current request is towards an RPMB
"block device".

This was done to avoid boot time scanning of this "block
device" which was never really a block device, thus duct-taping
over the fact that it was badly engineered.

This problem is now gone as we removed the offending RPMB block
device in another patch and replaced it with a character
device.

Cc: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The RPMB partition on the eMMC devices is a special area used
for storing cryptographically safe information signed by a
special secret key. To write and read records from this special
area, authentication is needed.

The RPMB area is *only* and *exclusively* accessed using
ioctl():s from userspace. It is not really a block device,
as blocks cannot be read or written from the device, also
the signed chunks that can be stored on the RPMB are actually
256 bytes, not 512 making a block device a real bad fit.

Currently the RPMB partition spawns a separate block device
named /dev/mmcblkNrpmb for each device with an RPMB partition,
including the creation of a block queue with its own kernel
thread and all overhead associated with this. On the Ux500
HREFv60 platform, for example, the two eMMCs means that two
block queues with separate threads are created for no use
whatsoever.

I have concluded that this block device design for RPMB is
actually pretty wrong. The RPMB area should have been designed
to be accessed from /dev/mmcblkN directly, using ioctl()s on
the main block device. It is however way too late to change
that, since userspace expects to open an RPMB device in
/dev/mmcblkNrpmb and we cannot break userspace.

This patch tries to amend the situation using the following
strategy:

- Stop creating a block device for the RPMB partition/area

- Instead create a custom, dynamic character device with
  the same name.

- Make this new character device support exactly the same
  set of ioctl()s as the old block device.

- Wrap the requests back to the same ioctl() handlers, but
  issue them on the block queue of the main partition/area,
  i.e. /dev/mmcblkN

We need to create a special "rpmb" bus type in order to get
udev and/or busybox hot/coldplug to instantiate the device
node properly.

Before the patch, this appears in 'ps aux':

101 root       0:00 [mmcqd/2rpmb]
123 root       0:00 [mmcqd/3rpmb]

After applying the patch these surplus block queue threads
are gone, but RPMB is as usable as ever using the userspace
MMC tools, such as 'mmc rpmb read-counter'.

We get instead those dynamice devices in /dev:

brw-rw----    1 root     root      179,   0 Jan  1  2000 mmcblk0
brw-rw----    1 root     root      179,   1 Jan  1  2000 mmcblk0p1
brw-rw----    1 root     root      179,   2 Jan  1  2000 mmcblk0p2
brw-rw----    1 root     root      179,   5 Jan  1  2000 mmcblk0p5
brw-rw----    1 root     root      179,   8 Jan  1  2000 mmcblk2
brw-rw----    1 root     root      179,  16 Jan  1  2000 mmcblk2boot0
brw-rw----    1 root     root      179,  24 Jan  1  2000 mmcblk2boot1
crw-rw----    1 root     root      248,   0 Jan  1  2000 mmcblk2rpmb
brw-rw----    1 root     root      179,  32 Jan  1  2000 mmcblk3
brw-rw----    1 root     root      179,  40 Jan  1  2000 mmcblk3boot0
brw-rw----    1 root     root      179,  48 Jan  1  2000 mmcblk3boot1
brw-rw----    1 root     root      179,  33 Jan  1  2000 mmcblk3p1
crw-rw----    1 root     root      248,   1 Jan  1  2000 mmcblk3rpmb

Notice the (248,0) and (248,1) character devices for RPMB.

Cc: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SD clock should be disabled for clock value 0. It's not
right to just return. This may cause failure of signal
voltage switching.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add PCI Id for Intel CDF.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The delay circuit used to support HS400 is calibrated based on two
additional clocks. When these clocks are not available and
FF_CLK_SW_RST_DIS is not set in CORE_HC_MODE, reset might fail. But on
some platforms this doesn't work properly and below dump can be seen in
the kernel log.

  mmc0: Reset 0x1 never completed.
  mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
  mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001102
  mmc0: sdhci: Blk size:  0x00004000 | Blk cnt:  0x00000000
  mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
  mmc0: sdhci: Present:   0x01f80000 | Host ctl: 0x00000000
  mmc0: sdhci: Power:     0x00000000 | Blk gap:  0x00000000
  mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000002
  mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
  mmc0: sdhci: Int enab:  0x00000000 | Sig enab: 0x00000000
  mmc0: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000000
  mmc0: sdhci: Caps:      0x742dc8b2 | Caps_1:   0x00008007
  mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
  mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
  mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
  mmc0: sdhci: Host ctl2: 0x00000000
  mmc0: sdhci: ============================================

Add support for the additional calibration clocks to allow these
platforms to be configured appropriately.

Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Cc: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NRob Herring <robh@kernel.org>
Tested-by: NJeremy McNicoll <jeremymc@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

By stuffing the runtime controlled clocks into a clk_bulk_data array we
can utilize the newly introduced bulk clock operations and clean up the
error paths. This allow us to handle additional clocks in subsequent
patch, without the added complexity.

Cc: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: NJeremy McNicoll <jeremymc@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SDHCI controllers on Tegra186 support 40 bit addressing.
IOVA addresses are 48-bit wide on Tegra186.
SDHCI host common code sets dma mask as either 32-bit or 64-bit.
To avoid access issues when SMMU is enabled, disable 64-bit dma.
Signed-off-by: NKrishna Reddy <vdumpa@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since this driver checks if the return value of dma_map_sg() is minus
or not and keeps to enable the DMAC, it may cause kernel panic when
the dma_map_sg() returns 0. So, this patch fixes the issue.
Reported-by: NDirk Behme <dirk.behme@de.bosch.com>
Fixes: 2a68ea78 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since the commit de3ee99b ("mmc: Delete bounce buffer handling")
deletes the bounce buffer handling, a request data size will be referred
to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes).

In other hand, renesas_sdhi_internal_dmac.c will set very big value of
max_{req,seg}_size because the max_blk_count is set to 0xffffffff.
And then, "swiotlb buffer is full" happens because swiotlb can handle
a memory size up to 256k bytes only (IO_TLB_SEGSIZE = 128 and
IO_TLB_SHIFT = 11).

So, as a workaround, this patch avoids the issue by setting
the max_{req,seg}_size up to 256k bytes if swiotlb is running.
Reported-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The default for d3_retune is true, but that was not being set in all cases,
which results in eMMC errors because re-tuning has not been done.
Fix by initializing d3_retune to true.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: c959a6b0 ("mmc: sdhci-pci: Don't re-tune with runtime pm for some Intel devices")
Cc: stable@vger.kernel.org # v4.12+
Reported-and-tested-by: Nojab <ojab@ojab.ru>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.

The binding documentation is updating accordingly.

Without this patch the kernel hand during boot if the mvpp2.2 network
driver was not present in the kernel. Indeed the clock needed by the
xenon controller was set by the network driver.

Fixes: 3a3748db ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core
functionality)"
CC: Stable <stable@vger.kernel.org>
Tested-by: NZhoujie Wu <zjwu@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It has been reported that some platforms (odroid-c2) may require
a different tx phase setting to operate at high speed (hs200 and hs400)

To improve the situation, this patch includes tx phase in the tuning
process.

Fixes: d341ca88 ("mmc: meson-gx: rework tuning function")
Reported-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Resetting the phase when POWER_ON is set the set_ios() call means that the
phase is reset almost every time the set_ios() is called, while the
expected behavior was to reset the phase on a power cycle.

This had gone unnoticed until now because in all mode (except hs400) the
tuning is done after the last to set_ios(). In such case, the tuning
result is used anyway.  In HS400, there are a few calls to set_ios() after
the tuning is done, overwriting the tuning result.

Resetting the phase on POWER_UP instead of POWER_ON solve the problem.

Fixes: d341ca88 ("mmc: meson-gx: rework tuning function")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Using CLK_DIVIDER_ROUND_CLOSEST is unsafe as the mmc clock could be
rounded to a rate higher the specified rate. Removing this flag ensure
that, if the rate needs to be rounded, it will be rounded down.

Fixes: 51c5d844 ("MMC: meson: initial support for GX platforms")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In may, Steven sent a patch deleting the bounce buffer handling
and the CONFIG_MMC_BLOCK_BOUNCE option.

I chose the less invasive path of making it a runtime config
option, and we merged that successfully for kernel v4.12.

The code is however just standing in the way and taking up
space for seemingly no gain on any systems in wide use today.

Pierre says the code was there to improve speed on TI SDHCI
controllers on certain HP laptops and possibly some Ricoh
controllers as well. Early SDHCI controllers lacked the
scatter-gather feature, which made software bounce buffers
a significant speed boost.

We are clearly talking about the list of SDHCI PCI-based
MMC/SD card readers found in the pci_ids[] list in
drivers/mmc/host/sdhci-pci-core.c.

The TI SDHCI derivative is not supported by the upstream
kernel. This leaves the Ricoh.

What we can however notice is that the x86 defconfigs in the
kernel did not enable CONFIG_MMC_BLOCK_BOUNCE option, which
means that any such laptop would have to have a custom
configured kernel to actually take advantage of this
bounce buffer speed-up. It simply seems like there was
a speed optimization for the Ricoh controllers that noone
was using. (I have not checked the distro defconfigs but
I am pretty sure the situation is the same there.)

Bounce buffers increased performance on the OMAP HSMMC
at one point, and was part of the original submission in
commit a45c6cb8 ("[ARM] 5369/1: omap mmc: Add new
   omap hsmmc controller for 2430 and 34xx, v3")

This optimization was removed in
commit 0ccd76d4 ("omap_hsmmc: Implement scatter-gather
   emulation")
which found that scatter-gather emulation provided even
better performance.

The same was introduced for SDHCI in
commit 2134a922 ("sdhci: scatter-gather (ADMA) support")

I am pretty positively convinced that software
scatter-gather emulation will do for any host controller what
the bounce buffers were doing. Essentially, the bounce buffer
was a reimplementation of software scatter-gather-emulation in
the MMC subsystem, and it should be done away with.

Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Juha Yrjola <juha.yrjola@solidboot.com>
Cc: Steven J. Hill <Steven.Hill@cavium.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Suggested-by: NSteven J. Hill <Steven.Hill@cavium.com>
Suggested-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The driver strength selection is missed and required when selecting
hs400es. So, It is added here.

Fixes: 81ac2af6 ("mmc: core: implement enhanced strobe support")
Cc: stable@vger.kernel.org
Signed-off-by: NHankyung Yu <hankyung.yu@lge.com>
Signed-off-by: NChanho Min <chanho.min@lge.com>
Reviewed-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The functions sdhci_omap_set_ios, sdhci_omap_set_power and
sdhci_omap_get_min_clock are local to the source and do not need
to be in global scope, so make them static.

Cleans up sparse warnings:
symbol 'sdhci_omap_set_ios' was not declared. Should it be static?
symbol 'sdhci_omap_set_power' was not declared. Should it be static?
symbol 'sdhci_omap_get_min_clock' was not declared. Should it be static?
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some Intel host controllers (e.g. CNP) use an ACPI device-specific method
to ensure correct voltage switching. Fix voltage switch for those, by
adding a call to the DSM.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some change for v4.14 broke the debug output for TMIO. But since it was
not helpful to me and too noisy for my taste anyhow, let's just remove
it instead of fixing it. We'll find something better if we'd need it...
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Create a new sdhci-omap driver to configure the eMMC/SD/SDIO controller
in TI's OMAP SoCs making use of the SDHCI core library. For OMAP specific
configurations, populate sdhci_ops with OMAP specific callbacks and use
SDHCI quirks.
Enable only high speed mode for both SD and eMMC here and add other
UHS mode support later.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

PBIAS voltage should be set along with setting vqmmc voltage and
these voltages should be set as part of start_signal_voltage_switch
callback. However since omap_hsmmc is about to be deprecated,
remove setting of PBIAS voltage leaving the PBIAS voltage to be
at the reset value of 3.3V (we'll never have to change this to 1.8V
since UHS mode support will not be added to omap_hsmmc). This will
let pbias regulator driver to be fixed to support a maximum voltage of
3.3V.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

KASAN reported the following:

[   19.338655] ==================================================================
[   19.345946] BUG: KASAN: use-after-free in of_platform_device_destroy+0x88/0x100
[   19.345966] Read of size 8 at addr fffffe01aa6f1468 by task systemd-udevd/264

[   19.345983] CPU: 1 PID: 264 Comm: systemd-udevd Not tainted 4.13.0-jang+ #737
[   19.345989] Hardware name: Cavium ThunderX CN81XX board (DT)
[   19.345995] Call trace:
[   19.346013] [<fffffc800808b1b0>] dump_backtrace+0x0/0x368
[   19.346026] [<fffffc800808b6bc>] show_stack+0x24/0x30
[   19.346040] [<fffffc8008cbb944>] dump_stack+0xa4/0xc8
[   19.346057] [<fffffc80082c2870>] print_address_description+0x68/0x258
[   19.346070] [<fffffc80082c2d70>] kasan_report+0x238/0x2f8
[   19.346082] [<fffffc80082c14a8>] __asan_load8+0x88/0xb8
[   19.346098] [<fffffc8008aacee0>] of_platform_device_destroy+0x88/0x100
[   19.346131] [<fffffc8000e02fa4>] thunder_mmc_probe+0x314/0x550 [thunderx_mmc]
[   19.346147] [<fffffc800879d560>] pci_device_probe+0x158/0x1f8
[   19.346162] [<fffffc800886e53c>] driver_probe_device+0x394/0x5f8
[   19.346174] [<fffffc800886e8f4>] __driver_attach+0x154/0x158
[   19.346185] [<fffffc800886b12c>] bus_for_each_dev+0xdc/0x140
[   19.346196] [<fffffc800886d9f8>] driver_attach+0x38/0x48
[   19.346207] [<fffffc800886d148>] bus_add_driver+0x290/0x3c8
[   19.346219] [<fffffc800886fc5c>] driver_register+0xbc/0x1a0
[   19.346232] [<fffffc800879b78c>] __pci_register_driver+0xc4/0xd8
[   19.346260] [<fffffc8000e80024>] thunder_mmc_driver_init+0x24/0x10000 [thunderx_mmc]
[   19.346273] [<fffffc8008083a80>] do_one_initcall+0x98/0x1c0
[   19.346289] [<fffffc8008177b54>] do_init_module+0xe0/0x2cc
[   19.346303] [<fffffc8008175cf0>] load_module+0x3238/0x35c0
[   19.346318] [<fffffc8008176438>] SyS_finit_module+0x190/0x1a0
[   19.346329] [<fffffc80080834a0>] __sys_trace_return+0x0/0x4

This is caused by:

  platform_device_register()
   -> platform_device_unregister(to_platform_device(dev))
	freeing struct device
   -> of_node_clear_flag(dev->of_node, ...)
	writing to the freed device

The issue is solved by increasing the reference count before calling
of_platform_device_destroy() so freeing the device is postponed after
the call.

Fixes: 8fb83b14 ("mmc: cavium: Fix probing race with regulator")
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_DEBUG was moved and one letter got strangely capitalized.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_init_request() depends on card->bouncesz so it must be calculated
before blk_init_allocated_queue() starts allocating requests.
Reported-by: NSeraphime Kirkovski <kirkseraph@gmail.com>
Fixes: 304419d8 ("mmc: core: Allocate per-request data using the..")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NSeraphime Kirkovski <kirkseraph@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NPavel Machek <pavel@ucw.cz>

Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Using __bf_shf does not compile on arm 32 architecture.
This has gone unnoticed till now cause the driver is only used on arm64.

In addition, __bf_shf was already used in the driver without any issue.
It was used on a constant value, so the call was probably optimized
away.

Replace __bf_shf by __ffs fixes the problem
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Enable runtime pm support for xenon controller, which uses 50ms
auto runtime suspend by default.
Reimplement system standby based on runtime pm API.
Introduce restore_needed to restore the Xenon specific registers
when resume.
Signed-off-by: NZhoujie Wu <zjwu@marvell.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_start_areq() is an internal mmc core API. Move the declaration
accordingly.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It does not make sense for qcom dml code to be a seperate module, as
this has just 2 helper functions specific to qcom, and used directly by
mmci driver, so just compile this along with main mmci driver.

This would also fix issues arrising due to Kconfig combinations between
mmci and qcom dml.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We might be into some troubles if the bootloader misconfigured the MMC
controller.

We currently only de-assert the reset line at probe time, which means that
if the device was already out of reset, we're going to keep whatever state
was set already.

Switch to a reset instead of the deassert to have a device in a pristine
state when we start operating.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Rework tuning function of the rx phase. Now that the phase can be
more precisely set using CCF, test more phase setting and find the
largest working window. Then the tuning selected is the one at the
center of the window.

This rework allows to use new modes, such as UHS SDR50
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Initial default tx phase was set to 0 while the datasheet recommends 270.
Some cards fails to initialize with this setting and eMMC mode DDR52 does
not work.

Changing this setting to 270 fixes these issues, without any regression
so far
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Implement voltage switch callback (shamelessly copied from sunxi mmc
driver). This allow, with the appropriate tuning function, to use
SD ultra high speed modes.
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Several phases can be controlled on the meson-gx controller, the core, tx
and rx clock phase. The tx and rx uses delays to allow  more fine grained
setting of the phase. To properly compute the phase using delays,
accessing the clock rate is necessary.

Instead of ad-hoc functions, use the common clock framework to set the
clock phases (and access the clock rate while doing it).
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Implement the card_busy callback to be able to verify that the
card is done dealing with voltage switch, when the support is
added later on.
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

No functional change, just improve interrupt handler readability
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It seems that the mmc clock is also used and required, somehow, by
the controller itself.

It is shown during init, when writing to CFG while the divider is set
to 0 will crash the SoC. During a voltage switch, the controller may
crash and the card may then fail to exit busy state if the clock is
stopped.

To avoid this, it is best to keep the clock running for the controller,
except during rate change. However, we still need to be able to gate
the clock out of the SoC. Let's use the pinmux for this, and fallback
to gpio mode (pulled-down) when we need to gate the clock
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In DDR modes, meson mmc controller requires an input rate twice as fast
as the output rate

Fixes: 51c5d844 ("MMC: meson: initial support for GX platforms")
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Thanks to devm, carrying the clock structure around after init is not
necessary. Rework the function to remove these from the controller host
data.

Finally, set initial mmc clock rate before enabling it, simplifying the
exit condition.
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Clean-up clk_set function to prepare the next changes (DDR and clk-stop)
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>