The Device will accept the requested number of data blocks, terminate
the transaction and return to transfer state. Stop command is not
required at the end of this type of multiple blocks write unless
terminated with an error. This change will send the
STOP_TRANIMISSION command if the command failed.
Change-Id: I9bd419ab8931d80a4a2eeba9f5bd42222257a824
Signed-off-by: Vinoth Gnanasekaran <vgnana@codeaurora.org>
eMMC part SDIN8DE1-8G is taking long time for the secure trim.
This leads to erase timeout. Manufacturer ID based quirk is added
for the specific part to use trim instead of secure trim for block erase.
Change-Id: I13d5a9f19edf5daf9c1f4d5c2ec16b4f3b680159
Signed-off-by: Pradeep Das <pkdas@codeaurora.org>
This patch makes mmc driver dcache aware to keep
the mmc functionality intact, with or without dcache
is enabled.
flush_cache used here does both clean and invalidate
cache thus preventing data loss during unaligned access,
if any.
Change-Id: I0910bd17678d3855bba27e9f8f7c08606774b28d
Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org>
This patch fixes the erase timeout issue in emmc.
Change-Id: I35031d834fda4ee7560e84787e18e8bc0a3f28fe
Signed-off-by: Antony Arun T <antothom@codeaurora.org>
The erase timeout has been calculated using the
EXT_CSD_TRIM_MULT so that the erase operation with
larger block counts are not affected.
Change-Id: Ia6dd9318c44b4da315c2b2a82cfabe9eff0aeb41
Signed-off-by: Rajkumar Ayyasamy <arajkuma@codeaurora.org>
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>
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>
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>
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>
