Menon, Nishanth had written, on 10/25/2010 06:33 PM, the following:
Having a loop with a counter is no timing guarentee for timing accuracy or compiler optimizations. For e.g. the same loop counter which runs when the MPU is running at 600MHz will timeout in around half the time when running at 1GHz. or the example where GCC 4.5 compiles with different optimization compared to GCC 4.4. use a udelay(10) to ensure we have a predictable delay. use an emperical number - 100000 uSec ~= 1sec for a worst case timeout. This should never happen, and is adequate imaginary condition for us to fail with timeout.
Signed-off-by: Nishanth Menon nm@ti.com
drivers/mmc/omap_hsmmc.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index 9271470..9b03ce1 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -137,7 +137,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, { hsmmc_t *mmc_base = (hsmmc_t *)mmc->priv; unsigned int flags, mmc_stat;
- unsigned int retry = 0x100000;
unsigned int retry = 100000;
while ((readl(&mmc_base->pstate) & DATI_MASK) == DATI_CMDDIS)
@@ -202,6 +202,9 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
do { mmc_stat = readl(&mmc_base->stat);
if (!mmc_stat) {udelay(10);}
I am dropping this patch instead will post a major timeout cleanup for omap_hsmmc.c -> caught a few other kickers as well :(.. darn the polling logic is so broken in the code :(