Update the existing drivers to set up this new pointer. This will be required
by the MMC uclass.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add request gpio for CD and WP gpios, so that the gpio can be
used for the respective purposes.
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

omap_hsmmc driver directly typecasts fdt_addr_t to a pointer.
This is not strictly correct, as it gives a build warning when
fdt_addr_t is u64. So, use map_physmem for a proper typecasts.

This is inspired by commit 167efe01 ("dm: ns16550: Use an address
instead of a pointer for the uart base")

drivers/mmc/omap_hsmmc.c: In function ‘omap_hsmmc_ofdata_to_platdata’:
drivers/mmc/omap_hsmmc.c:776:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  priv->base_addr = (struct hsmmc *)dev_get_addr(dev);
                      ^
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Boards using the TWL6030 regulator may not all use the LDOs the same way.
Some might also not use MMC1 at all, so VMMC would't have to be enabled.

This delegates TWL6030 MMC power initializations to board-specific functions,
that may still call twl6030_power_mmc_init for the default behavior.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

Not every device has multiple MMC slots available, so it makes sense to enable
only the required LDOs for the available slots. Generic code in omap_hsmmc will
enable both VMMC and VAUX1, in doubt.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

This is a device number, and we want to use 'dev' to mean a driver model
device. Rename the member.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NStephen Warren <swarren@nvidia.com>

adopt omap_hsmmc driver to device driver model
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>

Add MMC support for k2g
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NMugunthan V N <mugunthanvnm@ti.com>

Enable 8bit interface on HSMMC2 for am43xx to support 8bit eMMC chips.

Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>

The CMD(DAT) lines reset procedure described in the OMAP4(AM335x,
OMAP5, DRA7xx) TRMs is also necessary for AM43XX. Enable it in the
driver.

Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>

High capacity support is not a host capability, but a device capability
that is queried via the OCR. The flag in the operating conditions
request argument can just be set unconditionally. This matches the Linux
implementation.

[panto] Hand merged and renumbering MMC_MODE_DDR_52MHz.
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>

Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>

Boards using the TWL4030 regulator may not all use the LDOs the same way
(e.g. MMC2 power can be controlled by another LDO than VMMC2).
This delegates TWL4030 MMC power initializations to board-specific functions,
that may still call twl4030_power_mmc_init for the default behavior.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Reviewed-by: NTom Rini <trini@ti.com>
[trini: Fix omap3_evm warning, add twl4030.h]
Signed-off-by: NTom Rini <trini@ti.com>

Not every device has multiple MMC slots available, so it makes sense to enable
only the required LDOs for the available slots. Generic code in omap_hsmmc will
enable both VMMC1 and VMMC2, in doubt.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Reviewed-by: NTom Rini <trini@ti.com>

just add a few ifdefs around because this
device is very similar to dra7xxx.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NTom Rini <trini@ti.com>

Switch the default CD GPIO polarity to active low.

The current hsmmc driver assumption that the CD GPIO is active high, but
in the real hardware, usually the opposite holds.
The usual SD card socket has a mechanical switch which is grounded as
soon as a card is inserted.
Of course there might be some board logic which inverts the signal, but
as far as current users are concerned, there is no such logic.

Current U-Boot users either not using the CD functionality, or have a
different way (e.g. external to SoC GPIO controller) for checking the
card presence.

This patch also brings the polarity assumption in line with the Linux
kernel and adds appropriate comments.

This patch also might spare issues once the TWL GPIO driver will be
converted to the DM.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Reviewed-by: NTom Rini <trini@ti.com>

Add driver model support to this driver, while retaining support for the
legacy system. Driver model GPIO support is enabled with CONFIG_DM_GPIO
as usual.

Since gpio_is_valid() no longer exists, we can use the -EINVAL error
returned from gpio_request().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@ti.com>

Add missing prototypes for global functions and
make local functions static.

cc: panto@antoniou-consulting.com
Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>

The way that struct mmc was implemented was a bit of a mess;
configuration and internal state all jumbled up in a single structure.

On top of that the way initialization is done with mmc_register leads
to a lot of duplicated code in drivers.

Typically the initialization got something like this in every driver.

	struct mmc *mmc = malloc(sizeof(struct mmc));
	memset(mmc, 0, sizeof(struct mmc);
	/* fill in fields of mmc struct */
	/* store private data pointer */
	mmc_register(mmc);

By using the new mmc_create call one just passes an mmc config struct
and an optional private data pointer like this:

	struct mmc = mmc_create(&cfg, priv);

All in tree drivers have been updated to the new form, and expect
mmc_register to go away before long.

Changes since v1:

* Use calloc instead of manually calling memset.
* Mark mmc_register as deprecated.
Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com>

Using an array is pointless; even more pointless (and scary) is using
sprintf to fill it without a format string.
Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com>

Remove the in-structure ops and put them in mmc_ops with
a constant pointer to it.

This makes the mmc structure smaller as well as conserving
code space (in theory).

All in-tree drivers are converted as well; this is done in a
single patch in order to not break git bisect.

Changes since V1:
Fix compilation b0rked issue on omap platforms where OMAP_GPIO was
not set.
Signed-off-by: NPantelis Antoniou <panto@antoniou-consulting.com>

Enable 8-bit host capability for HSMMC2 and/or HSMMC3. CONFIG_HSMMC2_8BIT
(for OMAP4/5/DRA7xx) and/or CONFIG_HSMMC3_8BIT (for DRA7xx only) must be
defined in the board header if an 8-bit eMMC device is connected to the
corresponding port.

Fix the "No status update" error that appeared for eMMC devices by
inserting a 20 us delay between writing arguments and command. This
solution has been proposed by Michael Cashwell <mboards@prograde.net>.

A minor cosmetic fix in a comment as well.
Signed-off-by: NLubomir Popov <lpopov@mm-sol.com>

"mmc_send_cmd: timeout: No status update" error sometimes happens in
omap_hsmmc driver func mmc_send_cmd() when the MMC controller card
identification and selection sequence is executed for eMMC on OMAP4
boards.

It happens due to incorrect execution of CMD line reset procedure
for OMAP4. Because CMD(DAT) lines reset procedures are slightly
different for OMAP3 and OMAP4(AM335x,OMAP5,DRA7xx).

According to OMAP3 TRM:
Set SRC(SRD) bit in MMCHS_SYSCTL register to 0x1 and wait until
it returns to 0x0.

According to OMAP4(AM335x,OMAP5,DRA7xx) TRMs, CMD(DATA) lines reset
procedure steps must be as follows:
1. Initiate CMD(DAT) line reset by writing 0x1 to SRC(SRD) bit in
   MMCHS_SYSCTL register (SD_SYSCTL for AM335x).
2. Poll the SRC(SRD) bit until it is set to 0x1.
3. Wait until the SRC(SRD) bit returns to 0x0
  (reset procedure is completed).

Unfortunately, at present omap_hsmmc driver has support only for
OMAP3. And as result step #2 is missing for OMAP4(AM335x,OMAP5,DRA7xx).
This sometimes leads to the fact that the waiting loop which is
required in step #3 does not executed, because SRC bit does not set
yet (at the moment of checking a condition of a loop execution).
And as a result this can cause to timeout error when sending a
next command.

In the particular case (working with eMMC witch do not respond to
some SD specific command) due to incorrect reset sequence after
command SD_CMD_SEND_IF_COND which finished with CTO flag within
64 clock cycles, the next command MMC_CMD_APP_CMD leads to a
timeout error within 1s.

So, extend CMD(DATA) lines reset procedure in func
mmc_reset_controller_fsm() by adding the missing step #2 for
OMAP4+/AM335x boards.
Signed-off-by: NOleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>

Update pbias programming sequence for OMAP5 ES2.0/DRA7
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Since TPS659038/TWL6035/TWL6037 all belong to palmas family of TI PMICs,
rename twl6035_mmc1_poweron_ldo by a more generic palmas_mmc1_poweron_ldo
function.
Signed-off-by: NNishanth Menon <nm@ti.com>

TPS659038/TWL6035/TWL6037 all belong to palmas family of TI PMICs
Rename twl6035 to palmas to allow reuse across multiple current and
future platforms

As part of this change, change the CONFIG_TWL6035_POWER to
CONFIG_PALMAS_POWER and update usage of header file accordingly.
Signed-off-by: NNishanth Menon <nm@ti.com>

Gets rid of warnings from omap_gpio:
ERROR : check_gpio: invalid GPIO -1

(and undefined behaviour as the -1 error code is interpreted as gpio value)
Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>

A seperate omap_sys_ctrl_regs structure is defined for
omap4 & 5. If there is any change in control module for
any of the ES versions, a new structure needs to be created.
In order to remove this dependency, making the register
structure generic for all the omap4+ boards.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@ti.com>

Add check for write protection in omap mmc driver.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Reviewed-by: NTom Rini <trini@ti.com>

Add generic mmc write protection functionality.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>

Implement driver check for card detection.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>

Currently there's no appropriate place to store driver specific data
because the pointer that is meant for that (priv) is being used to
store the base address of mmc registers.

Introduce a new struct for storing driver specific data.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>

There are 3 MMC/SD/SDIO controllers in OMAP SoCs, but only 2 structs
are defined for devices. This leads to data being written outside of
array bounds on systems that use all 3 controllers.

Update hsmmc_dev array to the correct size.
Signed-off-by: NNikita Kiryanov <nikita@compulab.co.il>

Add omap5 pbias configuration for mmc1/sd lines
and set voltage for sd data i/o lines
Signed-off-by: NBalaji T K <balajitk@ti.com>

Make the sysctrl structure common, so that it can
be used in generic functions across socs.
Also change the base address of the system control module, to
include all the registers and not simply the io regs.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>

Add parameters to the OMAP MMC initialization function so the board can
mask host capabilities and set the maximum clock frequency.  While the
OMAP supports a certain set of MMC host capabilities, individual boards
may be more restricted and the OMAP may need to be configured to match
the board.  The PRG_SDMMC1_SPEEDCTRL bit in the OMAP3 is an example.
Signed-off-by: NJonathan Solnit <jsolnit@gmail.com>

According to OMAP3 TRM, when the controller reports certain errors,
driver must perform a software reset. This is done by setting a bit
in SYSCTL and waiting it to clear:
- SRC on command timeout (CTO)
- SRD on data errors (DTO, DCRC and DEB)

This fixes a problem seen on OMAP3 pandora board with some cards
that won't work with a message printed multiple times:
  timedout waiting on cmd inhibit to clear

Code loosely based on Linux omap_hsmmc driver.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Tested-by: NTom Rini <trini@ti.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>

The message didn't state that it's waiting for STAT to _clear_,
and printing the STAT value itself can help to identify problems.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Acked-by: NTom Rini <trini@ti.com>

According to OMAP3 TRM, PBIASLITEPWRDNZ bits must be cleared while MMC
power supply is being enabled and is ramping up (those bits might be
left set by the previous bootloader). It doesn't say what happens if
this procedure is violated, but better not to risk here and do things
as required.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Acked-by: NTom Rini <trini@ti.com>

Before we can send a command we need both the DATI (command inhibit on
mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear.
The previous behavior of only checking on DATI was insufficient on some
cards and incorrect behavior in any case.  This makes the code check
for both bits being clear and makes the error print more clear as
to what happened.  DATI_CMDDIS is removed as it was unused elsewhere
in the code and stood for 'DATI is set, cmds are disabled still'.

Fix originally spotted by Peter Bigot.
Tested-by: NPeter A. Bigot <bigotp@acm.org>
Tested-by: NRobert Nelson <robertcnelson@gmail.com>
Signed-off-by: NTom Rini <trini@ti.com>
Tested-by: NAndreas Müller <schnitzeltony@googlemail.com>