summaryrefslogtreecommitdiff
path: root/drivers/mmc/mmc_write.c
Commit message (Collapse)AuthorAgeLines
* dm: mmc: Support eraseSimon Glass2016-10-09-2/+8
| | | | | | | 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>
* mmc: sd: optimize erasePeng Fan2016-09-20-2/+7
| | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: mmc: Add support for driver-model block devicesSimon Glass2016-05-17-0/+9
| | | | | | | 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>
* dm: mmc: Move the device list into a separate fileSimon Glass2016-05-17-2/+2
| | | | | | | | | 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>
* dm: mmc: Use the new select_hwpart() APISimon Glass2016-05-17-2/+3
| | | | | | Avoid calling directly into the MMC code - use the new API call instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: block: Rename device number member dev to devnumSimon Glass2016-03-14-2/+2
| | | | | | | | | 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>
* dm: Drop the block_dev_desc_t typedefSimon Glass2016-03-14-2/+2
| | | | | | | | | 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>
* mmc: store hwpart in the block deviceStephen Warren2016-01-13-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* block: pass block dev not num to read/write/erase()Stephen Warren2016-01-13-2/+6
| | | | | | | | | | | 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>
* mmc: update MMC_ERASE argument to match Linux kernel.Eric Nelson2016-01-04-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* mmc_write.c: Make mmc_berase do 32bit safe 64bit mathTom Rini2015-06-18-1/+11
| | | | | | | | | | | | | | 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>
* mmc: Split mmc struct, rework mmc initialization (v2)Pantelis Antoniou2014-03-24-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: don't support write & erase for SPL buildsPaul Burton2013-09-20-0/+179
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>