Commit graph

11 commits

Author SHA1 Message Date
Simon Glass
33fb211dd2 dm: mmc: Add support for driver-model block devices
Add support for enabling CONFIG_BLK with MMC. This involves changing a
few functions to use struct udevice and adding a MMC block device driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-17 09:54:43 -06:00
Simon Glass
c40fdca6b7 dm: mmc: Move the device list into a separate file
At present the MMC subsystem maintains its own list of MMC devices. This
cannot work with driver model, which needs to maintain this itself. Move the
list code into a separate 'legacy' file. The core MMC code remains, and will
be shared with the driver-model implementation.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-17 09:54:43 -06:00
Simon Glass
69f45cd53b 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>
2016-05-17 09:54:43 -06:00
Simon Glass
bcce53d048 dm: block: Rename device number member dev to devnum
This is a device number, and we want to use 'dev' to mean a driver model
device. Rename the member.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
2016-03-14 15:34:50 -06:00
Simon Glass
4101f68792 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>
2016-03-14 15:34:50 -06:00
Stephen Warren
873cc1d777 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>
2016-01-13 21:05:19 -05:00
Stephen Warren
7c4213f6a5 block: pass block dev not num to read/write/erase()
This will allow the implementation to make use of data in the block_dev
structure beyond the base device number. This will be useful so that eMMC
block devices can encompass the HW partition ID rather than treating this
out-of-band. Equally, the existence of the priv field is crying out for
this patch to exist.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-13 21:05:18 -05:00
Eric Nelson
1aa2d074a7 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>
2016-01-04 11:17:43 -05:00
Tom Rini
180f87fcc5 mmc_write.c: Make mmc_berase do 32bit safe 64bit math
We want to see if the requested start or total block count are
unaligned.  We discard the whole numbers and only care about the
remainder.  Update the code to use div_u64_rem here and add a comment.

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Bernhard Nortmann <bernhard.nortmann@web.de>
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2015-06-18 16:11:41 -04:00
Pantelis Antoniou
93bfd61677 mmc: Split mmc struct, rework mmc initialization (v2)
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: Pantelis Antoniou <panto@antoniou-consulting.com>
2014-03-24 12:58:56 +02:00
Paul Burton
da61fa5f42 mmc: don't support write & erase for SPL builds
For SPL builds this is just dead code since we'll only need to read.
Eliminating it results in a significant size reduction for the SPL
binary, which may be critical for certain platforms where the binary
size is highly constrained.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
2013-09-20 18:58:55 +03:00