[U-Boot] [PATCH] mmc: omap: timeout counter fix

[U-Boot] [PATCH] mmc: omap: timeout counter fix

[Nishanth Menon]

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);
+		}
 		retry--;
 	} while ((mmc_stat == 0) && (retry > 0));
 
-- 
1.6.3.3

[U-Boot] [PATCH] mmc: omap: timeout counter fix

[Nishanth Menon]

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);
> +		}
>  		retry--;
>  	} while ((mmc_stat == 0) && (retry > 0));
>  
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 :(

-- 
Regards,
Nishanth Menon