Commit graph

16 commits

Author SHA1 Message Date
Jean-Jacques Hiblot
863d10044a mmc: add mmc_poll_for_busy() and change the purpose of mmc_send_status()
mmc_send_status() is currently used to poll the card until it is ready, not
actually returning the status of the card.
Make it return the status and add another function to poll the card.

Also remove the 'extern' declaration in the mmc-private.h header to comply
with the coding standard.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2019-07-15 10:16:49 +08:00
Ezequiel Garcia
2a4bb3d271 mmc: Use proper IS_ENABLED macro to check block support
Use CONFIG_IS_ENABLED(BLK) instead of CONFIG_BLK,
in order to fix the following build issues when
CONFIG_SPL_MMC_WRITE is selected:

drivers/mmc/mmc_write.c:69:7: error: conflicting types for 'mmc_berase'
 ulong mmc_berase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt)
       ^~~~~~~~~~
In file included from drivers/mmc/mmc_write.c:15:0:
drivers/mmc/mmc_private.h:39:7: note: previous declaration of 'mmc_berase' was here
 ulong mmc_berase(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt);
       ^~~~~~~~~~
drivers/mmc/mmc_write.c:187:7: error: conflicting types for 'mmc_bwrite'
 ulong mmc_bwrite(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
       ^~~~~~~~~~
In file included from drivers/mmc/mmc_write.c:15:0:
drivers/mmc/mmc_private.h:37:7: note: previous declaration of 'mmc_bwrite' was here
 ulong mmc_bwrite(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt,
       ^~~~~~~~~~

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
2019-01-16 13:56:43 +01:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Simon Glass
561e624c35 dm: mmc: Support erase
At present erase is not suported with CONFIG_DM_OPS. Add it so that MMC
devices can be erased.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-10-09 21:36:27 -06:00
Peng Fan
e492dbb41e mmc: sd: optimize erase
To SD, there is no erase group, then the value erase_grp_size
will be default 1. When erasing SD blocks, the blocks will be
erased one by one, which is time consuming.

We use AU_SIZE as a group to speed up the erasing.

Erasing 4MB with a SD2.0 Card with AU_SIZE 4MB.
`time mmc erase 0x100000 0x2000`
time: 44.856 seconds (before optimization)
time: 0.335 seconds  (after optimization)

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Eric Nelson <eric@nelint.com>
Cc: Stephen Warren <swarren@nvidia.com>
2016-09-20 06:46:01 +09:00
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