From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Date: Mon, 25 Oct 2010 19:43:45 -0500 Subject: [U-Boot] [PATCH] mmc: omap: timeout counter fix In-Reply-To: <1288049615-15346-1-git-send-email-nm@ti.com> References: <1288049615-15346-1-git-send-email-nm@ti.com> Message-ID: <4CC62441.9040303@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > --- > 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