dm: mmc: Set up the device pointer when using the MMC uclass

Update the existing drivers to set up this new pointer. This will be required
by the MMC uclass.

Signed-off-by: Simon Glass <sjg@chromiu

dm: mmc: Set up the device pointer when using the MMC uclass

Update the existing drivers to set up this new pointer. This will be required
by the MMC uclass.

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

show more ...

dm: mmc: Use the new select_hwpart() API

Avoid calling directly into the MMC code - use the new API call instead.

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

dm: mmc: Add a function to obtain the block device

The MMC block device is contained within struct mmc. But with driver model
this will not be the case. Add a function to obtain the block device. We

dm: mmc: Add a function to obtain the block device

The MMC block device is contained within struct mmc. But with driver model
this will not be the case. Add a function to obtain the block device. We
can later implement this for CONFIG_BLK.

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

show more ...

Merge git://git.denx.de/u-boot-dm

dm: Drop the block_dev_desc_t typedef

Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.

Signed-off-by: Simo

dm: Drop the block_dev_desc_t typedef

Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.

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

show more ...

mmc: add missing prototype for mmc_get_env_dev

This is a follow-up patch to e92029c0f4 and adds a prototype for
the weak mmc_get_env_dev function.

Cc: Tom Rini <trini@konsulko.com>
Cc: Stephen Warr

mmc: add missing prototype for mmc_get_env_dev

This is a follow-up patch to e92029c0f4 and adds a prototype for
the weak mmc_get_env_dev function.

Cc: Tom Rini <trini@konsulko.com>
Cc: Stephen Warren <swarren@nvidia.com>

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

show more ...

mmc: store hwpart in the block device

This will allow us to have multiple block device structs each referring
to the same eMMC device, yet different HW partitions.

For now, there is still a single

mmc: store hwpart in the block device

This will allow us to have multiple block device structs each referring
to the same eMMC device, yet different HW partitions.

For now, there is still a single block device per eMMC device. As before,
this block device always accesses whichever HW partition was most recently
selected. Clients wishing to make use of multiple block devices referring
to different HW partitions can simply take a copy of this block device
once it points at the correct HW partition, and use each one as they wish.
This feature will be used by the next patch.

In the future, perhaps get_device() could be enhanced to return a
dynamically allocated block device struct, to avoid the client needing to
copy it in order to maintain multiple block devices. However, this would
require all users to be updated to free those block device structs at some
point, which is rather a large change.

Most callers of mmc_switch_part() wish to permanently switch the default
MMC block device's HW partition. Enhance mmc_switch_part() so that it does
this. This removes the need for callers to do this. However,
common/env_mmc.c needs to save and restore the current HW partition. Make
it do this more explicitly.

Replace use of mmc_switch_part() with mmc_select_hwpart() in order to
remove duplicate code that skips the call if that HW partition is already
selected.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

Merge git://git.denx.de/u-boot-dm

dm: Convert PCI MMC over to use DM PCI API

At present pci_mmc_init() does not correctly use the PCI function since the
list it passes is not terminated. The array size passed to pci_mmc_init() is
ac

dm: Convert PCI MMC over to use DM PCI API

At present pci_mmc_init() does not correctly use the PCI function since the
list it passes is not terminated. The array size passed to pci_mmc_init() is
actually not used correctly. Fix this and adjust the pci_mmc_init() to scan
all available MMC devices.

Adjust this code to use the new driver model PCI API.

This should move over to the new MMC uclass at some point.

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

show more ...

mmc: update MMC_ERASE argument to match Linux kernel.

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

mmc: update MMC_ERASE argument to match Linux kernel.

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>

show more ...

dm: mmc: Add an MMC uclass

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@chrom

dm: mmc: Add an MMC uclass

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-mmc

mmc: remove the MMC_MODE_HC flag

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 b

mmc: remove the MMC_MODE_HC flag

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>

show more ...

mmc: Fix splitting device initialization

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

mmc: Fix splitting device initialization

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>

show more ...

mmc: Avoid extra duplicate entry in mmc device structure

The 'op_cond_response' field in mmc structure contains the response
from the last SEND_OP_COND MMC command while making iterational
polling o

mmc: Avoid extra duplicate entry in mmc device structure

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>

show more ...

mmc: Fix typo in MMC type checking macro

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

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

Merge branch 'master' of git://www.denx.de/git/u-boot-imx

Merge branch 'master' of git://git.denx.de/u-boot

Merge remote-tracking branch 'u-boot/master' into 'u-boot-arm/master'

Merge branch 'master' of git://git.denx.de/u-boot-mmc

mmc: Implement SD/MMC versioning properly

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

mmc: Implement SD/MMC versioning properly

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>

show more ...

mmc: fsl_esdhc: Add CMD11 support to switch to 1.8V

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 <ma

mmc: fsl_esdhc: Add CMD11 support to switch to 1.8V

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge branch 'master' of git://git.denx.de/u-boot-x86

x86: mmc: Move common FSP functions into a common file

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

x86: mmc: Move common FSP functions into a common file

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>

show more ...