[U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command()
Lukasz Majewski
l.majewski at samsung.com
Fri Jan 11 16:10:00 CET 2013
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;
>
Ive tested this code and data abort appears when used with ext4.
I think, that we need to look around for another solution.
> /* 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
More information about the U-Boot
mailing list