The capabilities have default values which doesn't reflect the reality
when it concerns the base clock and the mul value. Use a fixe rate
for the gck. 240 MHz is an arbitrary choice, it is a multiple of the
maximum SD clock frequency handle by the controller and it allows to
get a 400 kHz clock for the card initialisation.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Convert this driver to driver model.
This driver is also used by VEXPRESS platforms which doesn't
use driver model.
Tested on STM32F746 and STM32F769 platforms.
Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Update arm_pl180_mmci_init() prototype by adding struct mmc**
param. This is needed before converting this driver to driver model
in order to use arm_pl180_mmci_init() in driver model and in none
driver model implementation
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
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: Benoî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: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Jagan Teki <jagan@openedev.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: 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>
