On Thu, Jun 12, 2014 at 4:41 AM, Eli Billauer eli.billauer@gmail.com wrote:
The current wait loop just reads the status 10000 times, which makes the actual timeout period platform-dependent. The udelay() call within the loop makes the new timeout ~100 ms.
Signed-off-by: Eli Billauer eli.billauer@gmail.com
drivers/mmc/sdhci.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 3125d13..80f3a91 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -226,6 +226,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, break; if (--retry == 0) break;
udelay(10); } while ((stat & mask) != mask);
Hmmm...
Is 100ms part of the spec? I like the idea of making the timeout more time-based, but it seems to me that this changes the timeout quite significantly. If it took N ms before, it now takes N + 100 ms.
I think, if we want the timeout to be ~100ms, we should use a udelay of 100 or 1000, and then reduce "retry" accordingly.
Andy