On Fri, Jun 27, 2014 at 4:37 AM, Pantelis Antoniou < pantelis.antoniou@gmail.com> wrote:
Hi Eli,
On Jun 12, 2014, at 12:41 PM, Eli Billauer 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); if (retry == 0) {-- 1.7.2.3
Looking at the linux sources is no good, cause linux is interrupt driven. This delay is used because the driver is not interrupt driven, so you have to wait until the interrupt indication is delivered.
The only reference to interrupt latency I found is related to tuning and is set to 50ms which I supposed is very pessimistic. I think a timeout of 100ms would be fine.
I suspect the timeout of 100ms is fine (though it's always nice when we tie such numbers to something more concrete than: "it works if I make it wait longer"). My main point was that this actually *adds* 100ms to the preexisting timeout, instead of making the timeout ~100ms. If we reduced the number of checks and increased the delay, the delay would completely dominate the timeout loop, and total time would become closer to ~100ms.
Andy