Table 41 of the JEDEC standard for eMMC says that bit 31 of
the command argument is obsolete when issuing the ERASE
command (CMD38) on page 115 of this document:
	http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf

The SD Card Association Physical Layer Simplified Specification also
makes no mention of the use of bit 31.
	https://www.sdcard.org/downloads/pls/part1_410.pdf

The Linux kernel distinguishes between secure (bit 31 set) and
non-secure erase, and this patch copies the macro names from
include/linux/mmc/core.h.

Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Eric Nelson <eric@nelint.com>
Tested-by: Hector Palacios <hector.palacios@digi.com>

Add basic support for MMC, providing a uclass which can set up an MMC
device. This allows MMC drivers to move to using driver model.

Signed-off-by: Simon Glass <sjg@chromium.org>

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: Rob Herring <robh@kernel.org>
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>

Starting part of device initialization sets the init_in_progress flag
only if the MMC card did not yet come to ready state and needs to continue
polling. If the card is SD or if the MMC card became ready quickly,
the flag is not set and (if using pre-initialization) the starting
phase will be re-executed from mmc_init function.

Set the init_in_progress flag in all non-error cases. Also, move flags
setting statements around so that the flags are not set in error paths.
Also, IN_PROGRESS return status becomes unnecessary, so get rid of it.

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>

The 'op_cond_response' field in mmc structure contains the response
from the last SEND_OP_COND MMC command while making iterational
polling of the card. Later it is copied to 'ocr' field, designed
to contain the OCR register value, which is actually the same
response from the same command. So, these fields have actually
the same data, just in different time periods. It's easier to use
the same 'ocr' field in both cases at once, without temporary using
of the 'op_cond_response' field.

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>

The version flag constant name used in IS_MMC macro is incorrect/undefined.

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>

The SD/MMC version scheme was buggy when dealing with standard
major.minor.change cases. Fix it by using something similar to
the linux's kernel versioning method.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Reported-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>

This adds support to switch to 1.8V in case CMD11 succeeds.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Marek Vasut <marex@denx.de>

Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.

This creates a generic PCI MMC device.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>