[U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command()
Jaehoon Chung
jh80.chung at samsung.com
Thu Jan 10 05:55:21 CET 2013
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 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
>
More information about the U-Boot
mailing list