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

[Jaehoon Chung <jh80.chung@samsung.com>]

Hi All,

I think this problem is produced when card is running write/erase operation.
We used the mmc_send_status() into driver/mmc/mmc.c.
When That command is sending, i found the inhibit released log.

I think problem that SDHCI_DATA_INHIBIT is set at every command.
if didn't have data and response type is not busy-wait type,
SDHCI_DATA_INHIBIT didn't need to set.

How about this? It is more reasonable than increasing timeout value.

@@ -141,7 +143,10 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
 	timeout = 10;
 
 	sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
-	mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
+	mask = SDHCI_CMD_INHIBIT;
+
+	if ((data != NULL) || (cmd->resp_type & MMC_RSP_BUSY))
+		mask |= SDHCI_DATA_INHIBIT;
 
 	/* We shouldn't wait for data inihibit for stop commands, even
 	   though they might use busy signaling */

Best Regards,
Jaehoon Chung

On 01/10/2013 05:12 AM, Wolfgang Denk wrote:
> Dear Lukasz Majewski,
> 
> In message <1357665792-8141-1-git-send-email-l.majewski@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
>