The following error has been observed on i.MX25 with a high-speed SDSC
card:
    Data Write Failed in PIO Mode.

It was caused by the timeout set on PRSSTAT.BWEN, which was triggered
because this bit takes 15 ms to be set after writing the first block to
DATPORT with this card. Without this timeout, all the blocks are
properly written.

This timeout was implemented by decrementing a variable, so it was
depending on the CPU frequency. Fix this issue by setting this timeout
to a long enough absolute duration (500 ms).
Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

Uniformize STMicroelectronics copyrights headers for STM32
related code.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

Uniformize all STMicroelectronics copyrights headers for STi
related code.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

MMC commands like MMC_CMD_ALL_SEND_CID or MMC_CMD_SEND_CSD can reach
500 us. This patch increases the polling status register delay to avoid
a timeout on a command.
Signed-off-by: NChristophe Kerello <christophe.kerello@st.com>
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

Since e7881d85 "dm: mmc: Drop CONFIG_DM_MMC_OPS" DM_MMC_OPS
is no more used, remove it from STM32_SDMMC2 dependencies
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

U-Boot widely uses error() as a bit noisier variant of printf().

This macro causes name conflict with the following line in
include/linux/compiler-gcc.h:

  # define __compiletime_error(message) __attribute__((error(message)))

This prevents us from using __compiletime_error(), and makes it
difficult to fully sync BUILD_BUG macros with Linux.  (Notice
Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

Let's convert error() into now treewide-available pr_err().

Done with the help of Coccinelle, excluing tools/ directory.

The semantic patch I used is as follows:

// <smpl>
@@@@
-error
+pr_err
 (...)
// </smpl>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: NTom Rini <trini@konsulko.com>

The MMC framework in U-Boot does not support a systematic API for
timing switch like mmc_set_timing() in Linux.

U-Boot just provides a hook to change the clock frequency via
mmc_set_clock().  It is up to drivers if additional register
settings are needed.

This driver needs to set a correct timing mode into a register when
it migrates to a different speed mode.  Only increasing clock frequency
could result in setup/hold timing violation.

The timing mode should be decided by checking MMC_TIMING_* like
drivers/mmc/host/sdhci-cadence.c in Linux, but "timing" is not
supported by U-Boot for now.  Just use mmc->clock to decide the
timing mode.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add initial support for setting the vqmmc regulator. Since we do not
support 1V8 modes, set the regulator to 3V3 and enable it.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Old version of the uniphier-sd 64bit IO support patchset V1 was
applied by the maintainer, update the uniphier-sd.c with the
changes from the V3 of the patchset.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This patch adds SD/MMC support for STM32H7 SoCs.

Here is an extraction of SDMMC main features, embedded in
STM32H7 SoCs.
The SD/MMC block include the following:
 _ Full compliance with MultiMediaCard System Specification
   Version 4.51. Card support for three different databus modes:
   1-bit (default), 4-bit and 8-bit.
 _ Full compatibility with previous versions of MultiMediaCards
   (backward compatibility).
 _ Full compliance with SD memory card specifications version 4.1.
   (SDR104 SDMMC_CK speed limited to maximum allowed IO speed,
    SPI mode and UHS-II mode not supported).
 _ Full compliance with SDIO card specification version 4.0.
   Card support for two different databus modes: 1-bit (default)
   and 4-bit. (SDR104 SDMMC_CK speed limited to maximum allowed IO
   speed, SPI mode and UHS-II mode not supported).
 _ Data transfer up to 208 Mbyte/s for the 8 bit mode.
   (depending maximum allowed IO speed).
 _ Data and command output enable signals to control external
   bidirectional drivers.

The current version of the SDMMC supports only one SD/SDIO/MMC card
at any one time and a stack of MMC Version 4.51 or previous.
Signed-off-by: NChristophe Kerello <christophe.kerello@st.com>
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1
IO cells. Without this bias voltage these I/O cells can not function
properly. The PBIAS cell is controlled by software.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add OF match entries and quirks for Renesas RCar Gen3 controllers
into the driver. The IP this driver handles is in fact Matsushita
one and in used both in Socionext and Renesas chips.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>

Check if the OF match has any associated data and if so, use those
data as the controller quirks, otherwise fallback to the old method
of reading the controller version register to figure out the quirks.
This allows us to supply controller quirks on controllers which ie.
do not have version register.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>

The Renesas RCar Gen3 contains the same controller, originally
Matsushita. This patch adds support for handling of the 64bit
FIFO on this controller.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>

The Renesas RCar Gen3 contains the same controller, originally
Matsushita, yet the register addresses are shifted by 1 to the
left. The whole controller is also 64bit, including the data
FIFOs and RSP registers. This patch adds support for handling
the register IO by shifting the register offset by 1 in the IO
accessor functions.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>

This patch prepares the driver to support controller(s) with registers
at locations shifted by constant. Pull out the readl()/writel() from
the driver into separate functions, where the adjustment of the register
offset can be easily contained.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>

Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Use struct udevice* as input parameter. Previous
parameters are retrieved through plat and priv data.

This to prepare to use the reset framework.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

After Simon's patch, the dtoc can work with 64bit address,
so we need to fix reg number for it.
Depend on Simon's patch set:
https://patchwork.ozlabs.org/cover/807266/Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Update the Rockchip SDHCI wrapper to support a live device tree.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Version-changes: 2
- use the dev_read_addr_ptr function in	rockchip_sdhci.c

Update the Rockchip-specific wrapper for the Designware driver to
support a live device tree.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Version-changes: 2
- use the dev_read_addr_ptr function in rockchip_dw_mmc.c

Import include/linux/dma-direction.h from Linux 4.13-rc7 and delete
duplicated definitions of enum dma_data_direction.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When enabling the new mmc timing mode, we inadvertently clear all the
remaining bits in the new timing mode register. The bits cleared
include a default phase delay on the output clock. The BSP kernel
states that the default values are supposed to be used. Clearing them
results in decreased performance or transfer errors on some boards.

Fixes: de9b1771 ("mmc: sunxi: Support new mode")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The driver-model rework changed, among other things, the way the private
data were moved around. It now uses the private field in the struct mmc.

However, the mmc_create argument was changed in the process to always pass
the array we used to have to store our private structures.

The basically means that all the MMC driver instances will now have the
private data of the first instance, which obviously doesn't work very well.

Pass the proper pointer to mmc_create.

Fixes: 034e226b ("dm: mmc: sunxi: Pass private data around explicitly")
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: NChen-Yu Tsai <wens@csie.org>
Tested-by: NJagan Teki <jagan@openedev.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

Almost all of the newer Allwinner SoCs have a new operating mode for the
eMMC clocks that needs to be enabled in both the clock and the MMC
controller.

Details about that mode are sparse, and the name itself (new mode vs old
mode) doesn't give much details, but it seems that the it changes the
sampling of the MMC clock. One side effect is also that it divides the
parent clock rate by 2.

Add support for it through a Kconfig option.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

This changes pci_mmc driver to use PCI_CLASS_SYSTEM_SDHCI instead of
individual vendor id & device id pair to support generic PCI SD host
controller.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

This patch allows to show the EXT_CSD[179] partition_config
register info, just by specifying the dev param:

  U-Boot> mmc partconf 0
  EXT_CSD[179], PARTITION_CONFIG:
  BOOT_ACK: 0x0
  BOOT_PARTITION_ENABLE: 0x0
  PARTITION_ACCESS: 0x0
Signed-off-by: NAngelo Dureghello <angelo@sysam.it>
Signed-off-by: NAnatolij Gustschin <agust@denx.de>

All boards which use DM_MMC have now been converted to use DM_MMC_OPS.
Drop the option and good riddance.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This should depend on SPL_DM_MMC, not SPL_DM. For it and update the only
affected board's defconfig.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Enable driver model for MMC (including BLK), SATA and USB. Note that USB
does not yet work correctly since the nodes are disabled. Hopefully this
can be resolved by the maintainer.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This driver does not currently support CONFIG_DM_MMC_OPS. Update it to
fully convert it to driver model.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Update this driver to support a live device tree.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We want to use fsl_esdhc_init() with driver model. Move the mmc_init() out
of this function so that we can use it for our common init.
Signed-off-by: NSimon Glass <sjg@chromium.org>

With driver model we want to store the mmc and configuration structure in
platform data. Set up structure up and use it for non-DM as well.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Since esdhc_init_common() can fail it should return an error code. Update
this and also adjust the timeout mechanism to use get_timer(), which is a
more common approach.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Since esdhc_reset() can fail it should return an error code. Update this
and also adjust the timeout mechanism to use get_timer(), which is a more
common approach.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Driver model wants to use the core functions in this file but accesses the
driver-private data in a different way. Move the code into new 'common'
functions and set up stubs to call these. Also sort the operations into
alphabetical order for consistency.
Signed-off-by: NSimon Glass <sjg@chromium.org>

With driver model we will not use mmc->priv to access driver-private data.
To accomodate this, update internal functions so that we can pass the
private data directly. This will allow the caller to obtain it as it
prefers.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The bind() method is called before the device is probed and so the
device has no private data, should use the platform data, and set up
a new struct to hold the mmc and cfg members.
Signed-off-by: NWenyou Yang <wenyou.yang@microchip.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Since we now have clock driver for the RCar Gen3 , add support for
enabling the clock into the SH SDHI driver to prevent hacks in the
board files.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NNobuhiro Iwamatsu <iwamatsu@nigauri.org>