No subject

consecutive MMC operations (i.e. many reads), and the 10ms timeout
might be too short when eMMC firmware is forced to do some internal
time consuming operations (e.g. flash blocks management, wear
leveling).
In this situation, the SDHCI_CMD_INHIBIT bit is set, which means that
SDHCI controller didn't received response from eMMC.

One proposition would be to define the per device/per memory chip
specific timeouts, to replace those defined at ./drivers/mmc/sdhci.c
file.

I also assume, that timeouts cannot be removed, since we must detect
if user pulls out a SD card or transmission has been broken.

I'm also wondering if we can tune the sdhci code to improve cooperation
 with eMMC devices (despite of the fact that this is NOT really needed at
u-boot :-) ).

Signed-off-by: Lukasz Majewski <l.majewski at samsung.com>
Cc: Jaehoon Chung <jh80.chung at samsung.com>
Cc: Andy Fleming <afleming at gmail.com>
---
 drivers/mmc/sdhci.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index b9cbe34..0fd1337 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -137,8 +137,8 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
 	unsigned int timeout, start_addr = 0;
 	unsigned int retry = 10000;
 
-	/* Wait max 10 ms */
-	timeout = 10;
+	/* Wait max 100 ms */
+	timeout = 100;
 
 	sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
 	mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
-- 
1.7.2.3