The hard-coded 10ms delay in mmc_power_up came from
commit 79bccc5a ("mmc: increase power up delay"), which said "The TI
controller on Toshiba Tecra M5 needs more time to power up or the cards
will init incorrectly or not at all." But it's too engineering solution
for a special board but force all platforms to wait for that long time,
especially painful for mmc_power_up for eMMC when booting.

However, it's added since 2009, and we can't tell if other platforms
benefit from it. But in practise, the modern hardware are most likely to
have a stable power supply with 1ms after setting it for no matter PMIC
or discrete power. And more importnatly, most regulators implement the
callback of ->set_voltage_time_sel() for regulator core to wait for
specific period of time for the power supply to be stable, which means
once regulator_set_voltage_* return, the power should reach the the
minimum voltage that works for initialization. Of course, if there
are some other ways for host to power the card, we should allow them
to argue a suitable delay as well.

With this patch, we could assign the delay from firmware, or we could
assigne it via ->set_ios() callback from host drivers.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

post-power-on-delay-ms woule be reused to substitute the hard-coded 10ms
delay waiting for power supply to be stable, specificed by individual
platform/board. Default to 10ms as before, if no available.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch adds r8a77965 support in SDHI.
Signed-off-by: NMasaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Tested-by: NSimon Horman <horms+renesas@verge.net.au>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

A redundant return statement is removed from
tegra_sdhci_set_uhs_signaling(). The function returns void and the
return does not affect the control flow of the function.
Signed-off-by: NAapo Vienamo <aapo.vienamo@iki.fi>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_CORE_TIMEOUT_MS isn't being used no more, let's drop it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMichał Pecio <michal.pecio@gmail.com>

Instead of using a fixed 3s timeout for commands with R1B responses,
convert to use the per request calculated busy timeout from the mmc core.

This is needed to cope with requests that requires longer timeout, for
example erase/discard commands.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMichał Pecio <michal.pecio@gmail.com>

Instead of having to return -EINVAL when requested to send SDIO specific
commands, let's set MMC_CAP2_NO_SDIO as it completely prevents them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMichał Pecio <michal.pecio@gmail.com>

Let's implement the ->sw_reset() bus ops to allow SDIO func drivers, in
particular, to make a SW reset without doing a full power cycle of the SDIO
card.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

Move the corresponding code for setting the initial signal voltage, from
mmc_power_up() into a new function, mmc_set_initial_signal_voltage().

Make the function internally available to the mmc core, as to allow the
following changes to make use of it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

It's rather common that a firmware is loaded into an SDIO func device
memory, by the corresponding SDIO func driver during ->probe() time.

However, to actually start running the new firmware, sometimes a soft reset
(no power cycle) and a re-initialization of the card is needed. This is for
example the case with the Espressif ESP8089 WiFi chips, when connected to
an SDIO interface.

To cope with this scenario, let's add a new exported function,
mmc_sw_reset(), which may be called when a soft reset and re-initialization
of the card are needed.

The mmc_sw_reset() is implemented on top of a new bus ops callback, similar
to how the mmc_hw_reset() has been implemented.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The bus ops ->reset() executes a full HW reset of the card, as the calling
function mmc_hw_reset() also indicates by its name. Let's convert to follow
the similar names, for both the bus ops callback and for the corresponding
bus ops functions, as to clarify the purpose of code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

The mmc_sdio_init_card() function has a couple of callers. In the
re-initialization cases, some additional reset commands are issued before
mmc_sdio_init_card() is called. As these additional reset commands are the
same, let's move these into a new static function, mmc_sdio_reinit_card()
and call mmc_sdio_init_card() from there. In this way we avoid the open
coding.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NQuentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>

Merge immutable branch for sdhci-omap to add UHS/HS200 mode support.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Allow to use tunable delay before detecting card after card is inserted,
which either comes from firmware node, or comes from debounce value
passed on to mmc_gpiod_request_cd(). If the platform doesn't support
debounce, then we fall back to use the debounce period as the delay,
otherwise, it behaves the same as before that a HW debounce(if set) plus
a 200ms hardcode delay before detecting the card.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

cd-gpios uses a fixed delay, 200ms, before detecting card after the card
is inserted. 200ms doesn't work for some platforms, so some host drivers
added their own properties for parsing that from DT, for instance,
dw_mmc and pxamci. That being said, it should also be tunable when using
cd-gpios.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

commit 8d20b2ea ("mmc: sdhci_omap: Add support to set
IODELAY values") stored IODelay values for all MM/SD modes
in pinctrl_state structure member of sdhci_omap_host. However for
DDR mode it gets IODelay values only for 1.8v DDR mode. Since some of
the platforms which uses sdhci-omap has IO lines connected to 3.3v,
get IODelay values for 3.3v DDR mode.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add pinctrl binding rquired to get the mux mode and IODelay
values from devicetree.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add sdhci_omap_enable_sdio_irq to set CTPL and CLKEXTFREE bits in
MMCHS_CON register required to detect asynchronous card interrupt
on DAT[1].
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add support for the new compatible added specifically to support
k2g's MMC/SD controller.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add binding for the TI's sdhci-omap controller present in K2G.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions the maximum
obtainable timeout through MMC host controller is 700ms. And for
commands taking longer than 700ms, hardware timeout should be
disabled and software timeout should be used.

The workaround for Errata i834 can be achieved by adding
SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk in sdhci-omap.

[1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdfSigned-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>

sdhci has a 10 second timeout to catch devices that stop responding.
In the case of quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, instead of
programming 10 second arbitrary value, calculate the total time it would
take for the entire transfer to happen and program the timeout value
accordingly.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Factor out the target_timeout calculation so it can be re-used.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add quirk to disable HW timeout if the requested timeout is more than the
maximum obtainable timeout.

Also, if the quirk is set and ->get_max_timeout_count() is not implemented,
max_busy_timeout is set to zero.
Based-on-patch-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The SDHCI controller in a SoC might support HS200/HS400 (indicated
using mmc-hs200-1_8v/mmc-hs400-1_8v dt property), but if the board is
modeled such that the IO lines are not connected to 1.8v then
HS200/HS400 cannot be supported. Disable HS200/HS400 if the board
does not have 1.8v connected to the IO lines. Also Disable DDR/UHS in 1.8v
if the IO lines are not connected to 1.8v.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Invoke sdhci_get_of_property defined in sdhci-pltfm.c to read
sdhci specific properties from dt node.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Errata i843 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions
PG 1.0/1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
can operate.

Use soc_device_match() to identify rev 1.0/1.1 silicon and
override mmc->f_max according to the errata workaround.
"max-frequency" dt property cannot be used since the device
tree is added for rev 2.0 silicon.

soc_device_match() is also used in order to get the IODelay values
for rev 1.0/1.1 silicon.

[1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdfSigned-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci can directly get ADMA capability from MMCHS_CAPA register.
Remove explicitly setting ADMA here as some instances might not have
ADMA enabled. (sdhci_read_caps() is also removed from here since
sdhci_setup_host() invokes it).
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_omap_config_iodelay_pinctrl_state() requires caps and caps2 to be
initialized (speed mode capabilities like UHS/HS200) before it is
invoked. While mmc_of_parse() initializes caps/caps2 if capabilities is
populated in device tree, it will remain uninitialized for capabilities
obtained from SDHCI_CAPABILITIES register.
Fix sdhci_omap_config_iodelay_pinctrl_state() to be used even while
getting the capabilities from SDHCI_CAPABILITIES register by invoking
sdhci_setup_host() before sdhci_omap_config_iodelay_pinctrl_state().
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>

MT2712 MSDC supports 64G DRAM DMA access, it needs update
gpd/bd structure.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

On !RT interrupt runs with interrupts disabled. On RT it's in a
thread, so no need to disable interrupts at all.
Remove the local_irq_save() invocation.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

While performing R/W access in PIO mode, the common SDHCI driver checks
the buffer ready status once per whole block processing. That is, after
getting an appropriate interrupt, or checking an appropriate status bit,
the driver makes buffer accesses for the whole block size (e.g. 128 reads
for 512 bytes block). This is done in accordance with SD Host Controller
Specification.

At the same time, the Ultra Secured Digital Host Controller (uSDHC), used
in i.MX6 (and, probably, earlier i.MX series too), uses a separate
Watermark Levels register, controlling the amount of data or space
available when raising status bit or interrupt. For default watermark
setting of 16 words, the controller expects (and guarantees) no more
than 16 buffer accesses after raising buffer ready status bit and
generating an appropriate interrupt. If the driver tries to access the
whole block size, it will get incorrect data at the end, and a new
interrupt will appear later, when the driver already doesn't expect it.
This happens sometimes, more likely on low frequencies, e.g. when
reading EXT_CSD at MMC card initialization phase
(which makes that initialization fail).

Such behavior of i.MX uSDHC seems to be non-compliant
to SDHCI Specification, but this is the way it works now.

In order not to rewrite the SDHCI driver PIO mode access logic,
the IMX specific driver can just set the watermark level to default
block size (128 words or 512 bytes), so that the controller behavior
will be consistent to generic specification. This patch does this
for PIO mode accesses only, restoring default values for DMA accesses
to avoid any possible side effects from performance point of view.
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NHarish Jenny K N <harish_kandiga@mentor.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
have a control signal  (io_pad_pwr_switch/mode18 ) that indicates
whether the PAD works in 3v or 1.8v.

SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
based on actual voltage used for IO lines. So when power irq is
triggered for io high or io low, the driver should check the voltages
supported and set the pad accordingly.
Signed-off-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NVenkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: NVijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

During probe check whether the vdd-io regulator of sdhc platform device
can support 1.8V and 3V and store this information as a capability of
platform device.
Signed-off-by: NVijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
SDHI core anyway, so can't be a subject of the known RX DMA errata...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently, the code block inside the for loop will never execute more than
once, because the function returns immediately after the first iteration,
hence the execution of the code at the second iteration is structurally
dead and, code at line 281: return 0; is never reached.

Fix this by checking _ret_ before return.

Addresses-Coverity-ID: 1468009 ("Logically dead code")
Addresses-Coverity-ID: 1468002 ("Structurally dead code")
Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The usage of of_device_get_match_data() reduce the code size a bit.

Also, the only way to call msdc_drv_probe() is to match an entry in
msdc_of_ids[], so of_id cannot be NULL.
Signed-off-by: NRyder Lee <ryder.lee@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Fix 3.3V voltage switch for some BYT-based Intel controllers by making use
of the ACPI DSM.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>