| Message ID | 0ec2cee0c99b308c9eec11e0b63d2814d26df95f.1412379690.git.marcel@ziswiler.com |
|---|---|
| State | Accepted |
| Delegated to: | Pantelis Antoniou |
| Headers | show |
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c index ca9c4aa..2642fe2 100644 --- a/drivers/mmc/tegra_mmc.c +++ b/drivers/mmc/tegra_mmc.c @@ -292,7 +292,7 @@ static int mmc_send_cmd_bounced(struct mmc *mmc, struct mmc_cmd *cmd, /* Transfer Complete */ debug("r/w is done\n"); break; - } else if (get_timer(start) > 2000UL) { + } else if (get_timer(start) > 8000UL) { writel(mask, &host->reg->norintsts); printf("%s: MMC Timeout\n" " Interrupt status 0x%08x\n"
During rigorous testing of our latest update infrastructure I came across quite consistent timeouts on certain eMMC parts (e.g. Hynix H26M21001ECR) when writing big (e.g. in excess of 400 MB) file system images: MMC write: dev # 0, block # 40960, count 944128 ... mmc_send_cmd_bounced: MMC Timeout Interrupt status 0x00000001 Interrupt status enable 0xdfff003b Interrupt signal enable 0xdfff0002 Present status 0x01870106 mmc write failed Comparing the various data sheets I came across the following timeout specification: Secure Erase/TRIM Timeout=300ms*2*10=6000ms Unfortunately empirical testing still failed albeit much more rarely. Increasing the timeout to 8000ms made it finally disappear entirely. This patch allows us writing various eMMC parts without seeing any further issues. Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> --- drivers/mmc/tegra_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)