[U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command()

Wolfgang Denk wd at denx.de
Wed Jan 9 21:12:01 CET 2013


Dear Lukasz Majewski,

In message <1357665792-8141-1-git-send-email-l.majewski at samsung.com> you wrote:
> I'd like to ask for your opinion about the following problem:

I cannot comment on the problem - only a bit about the proposed patch
;-)

> 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.

Is there no way to ask the device and/or controller when it is done,
so we can poll for ready state instead of adding delays, which will
always have to be tailored for the so far known worst case, i. e. they
will be always too long on all almost all systems.

> --- 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;

We have cases where we struggle for sub-second boot times.  Adding
100 ms delay here is clearly prohbitive.  [Even the 10 ms are way too
long IMHO.]  There must be a better way to handle this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.


More information about the U-Boot mailing list