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

[Lukasz Majewski]

Hi Jaehoon,

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

I will test this and let you know.

>  	/* 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
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group