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.majew...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
