I'd like to ask for your opinion about the following problem:

TRATS # saveenv
Saving Environment to MMC...
Writing to MMC(0)... Controller never released inhibit bit(s).
Controller never released inhibit bit(s).
Controller never released inhibit bit(s).
...
failed

The same is for e.g. ext4.

The provided patch seems to solve the problem, but I DO NOT think that
increasing delay is an acceptable solution to any problem.

>From a brief checking I can say that it happens when we are doing
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.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Andy Fleming <aflem...@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

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to