Message ID | CAAGaQKATED=5WCq=SPaZGs95y_NcV7PqKPny=emjN64Ezqwg8g@mail.gmail.com |
---|---|
State | Superseded |
Delegated to: | Pantelis Antoniou |
Headers | show |
Steve, On 24.06.2016 00:06, Steve Rae wrote: > I am asking you about this code, because of this: > commit 29905a4 - mmc: sdhci: Use timer based timeout detection in > sdhci_send_command() > > Occasionally, I am seeing failures when writing to flash on my device: > > Flashing sparse image at offset 2078720 > Flashing Sparse Image > sdhci_send_command: Timeout for status update! > mmc fail to send stop cmd > write_sparse_image: Write failed, block #2181088 [0] > > I can eliminate this error if I kludge the following code: > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > index 5c71ab8..854f7ce 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -243,9 +243,9 @@ static int sdhci_send_command(struct mmc *mmc, > struct mmc_cmd *cmd, > if (stat & SDHCI_INT_ERROR) > break; > } while (((stat & mask) != mask) && > - (get_timer(start) < CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT)); > + (get_timer(start) < 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/)); > > - if (get_timer(start) >= CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT) { > + if (get_timer(start) >= 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/) { > if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) > return 0; > else { > > I don't know much about this - I arrived at 600 by trial and error > (500 fails...) > Any ideas? Perhaps your platform needs a bigger timeout value. Did you check what the Linux driver does here? You could move CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT to Kconfig with a default of 100 and select a higher value for your platform. Thanks, Stefan
2016-06-24 7:06 GMT+09:00 Steve Rae <steve.rae@raedomain.com>: > Stefan, > > I am asking you about this code, because of this: > commit 29905a4 - mmc: sdhci: Use timer based timeout detection in > sdhci_send_command() > > Occasionally, I am seeing failures when writing to flash on my device: > > Flashing sparse image at offset 2078720 > Flashing Sparse Image > sdhci_send_command: Timeout for status update! > mmc fail to send stop cmd > write_sparse_image: Write failed, block #2181088 [0] > > I can eliminate this error if I kludge the following code: > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > index 5c71ab8..854f7ce 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -243,9 +243,9 @@ static int sdhci_send_command(struct mmc *mmc, > struct mmc_cmd *cmd, > if (stat & SDHCI_INT_ERROR) > break; > } while (((stat & mask) != mask) && > - (get_timer(start) < CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT)); > + (get_timer(start) < 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/)); > > - if (get_timer(start) >= CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT) { > + if (get_timer(start) >= 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/) { > if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) > return 0; > else { > > I don't know much about this - I arrived at 600 by trial and error > (500 fails...) > Any ideas? > > Hi Steve, You are not alone. I am also suffering this too short timeout value. I sent this patch about two months ago. http://patchwork.ozlabs.org/patch/615994/ But, nothing happened.
Hi Stefan, Masahiro On Thu, Jun 23, 2016 at 9:56 PM, Stefan Roese <sr@denx.de> wrote: > Steve, > > > On 24.06.2016 00:06, Steve Rae wrote: >> >> I am asking you about this code, because of this: >> commit 29905a4 - mmc: sdhci: Use timer based timeout detection in >> sdhci_send_command() >> >> Occasionally, I am seeing failures when writing to flash on my device: >> >> Flashing sparse image at offset 2078720 >> Flashing Sparse Image >> sdhci_send_command: Timeout for status update! >> mmc fail to send stop cmd >> write_sparse_image: Write failed, block #2181088 [0] >> >> I can eliminate this error if I kludge the following code: >> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> index 5c71ab8..854f7ce 100644 >> --- a/drivers/mmc/sdhci.c >> +++ b/drivers/mmc/sdhci.c >> @@ -243,9 +243,9 @@ static int sdhci_send_command(struct mmc *mmc, >> struct mmc_cmd *cmd, >> if (stat & SDHCI_INT_ERROR) >> break; >> } while (((stat & mask) != mask) && >> - (get_timer(start) < CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT)); >> + (get_timer(start) < 600 >> /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/)); >> >> - if (get_timer(start) >= CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT) { >> + if (get_timer(start) >= 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/) >> { >> if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) >> return 0; >> else { >> >> I don't know much about this - I arrived at 600 by trial and error >> (500 fails...) >> Any ideas? > > > Perhaps your platform needs a bigger timeout value. Did you check > what the Linux driver does here? It looks like (v.4.6) the code loops for max_loops=16, and it looks like the loop delay is created by a write (which does not exist in the U-Boot code): sdhci_writel(host, mask, SDHCI_INT_STATUS); > You could move > CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT to Kconfig with a default of 100 > and select a higher value for your platform. > Would it be wise to create a new CONFIG for the reading of the status, rather than overloading the CONFIG used for sending the command? maybe: CONFIG_SDHCI_STATUS_DEFAULT_TIMEOUT ? Thanks, Steve > Thanks, > Stefan
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 5c71ab8..854f7ce 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -243,9 +243,9 @@ static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, if (stat & SDHCI_INT_ERROR) break; } while (((stat & mask) != mask) && - (get_timer(start) < CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT)); + (get_timer(start) < 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/)); - if (get_timer(start) >= CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT) { + if (get_timer(start) >= 600 /*CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT*/) { if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) return 0;