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: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice 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: Patrice 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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: Tom 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: Masahiro 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: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Masahiro 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: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Masahiro 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: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon 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: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon 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: Marek 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: Marek 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: Marek 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: Marek 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: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
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: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Simon 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: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Update the Rockchip SDHCI wrapper to support a live device tree.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp 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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Andy 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: de9b1771c3 ("mmc: sunxi: Support new mode")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan 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: 034e226bc7 ("dm: mmc: sunxi: Pass private data around explicitly")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Jagan 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: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan 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: Bin 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: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Anatolij 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: Simon 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: Simon 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: Simon 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: Simon 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: Simon 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: Simon 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: Simon 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: Simon 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: Wenyou Yang <wenyou.yang@microchip.com>
Reviewed-by: Simon 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: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The command handling in this driver is awful, esp. because the driver
depends on command numbers to determine whether this is APPCMD or not.
Also, handling of command RSP response types is totally wrong.
This patch at least plucks out some of the custom command encoding and
fixes the APPCMD handling. The RSP handling still needs work, yet that
might not be needed as it turns out the uniphier-sd.c driver is in much
better shape and supports the same IP, so we might be able to just drop
this driver in favor of the uniphier one.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add MMC DM and DT probing support into the SH SDHI driver.
This patch abstracts out the common bits of the send command
and set ios functions, so they can be used both by DM and non
DM setups and adds the DM probe support.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The long response entry 0..3 LSByte comes from the next response
register MSByte, not from the next response register LSByte. Fix
this to make the driver report correct values in response 136 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We shouldn't always change the status to okay. There could be
situations that the esdhc is intentionally disabled in the device
tree.
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Commit 4483b7eb added variable vqmmc_dev but only uses it under
CONFIG_DM_REGULATOR. Add the same macro to variable declaration to
get rid of compiling warning.
Signed-off-by: York Sun <york.sun@nxp.com>
Convert the pci_mmc driver over to driver model and migrate all x86 boards
that use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: remove DM_MMC from edison_defconfig]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver-model version of this driver which mostly uses the existing
code. The old code can be removed once all boards are switched over.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function has #ifdefs in it which we want to avoid for driver model.
Instead we should use different compatible strings and the .data field.
It also uses the MMC device number which is not available in driver
model except through aliases.
Move the function's into its caller so that the driver-model version can
do things its own way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
At present the driver-private data is obtained in various functions by
various means. With driver model this is provided automatically. Without
driver model it comes from a C array declared at the top of the file.
Adjust internal functions so that they are passed the private data as
a parameter, allowing the caller to obtain it using either means.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Use the driver-model naming convention for this structure. It is data
private to the driver so the local variable should be called 'priv'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Use the driver-model naming convention for this structure. It is data
private to the driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
