From mboxrd@z Thu Jan  1 00:00:00 1970
From: Reinhard Meyer <u-boot@emk-elektronik.de>
Date: Tue, 26 Oct 2010 03:14:20 +0200
Subject: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
In-Reply-To: <1288054924-24989-1-git-send-email-nm@ti.com>
References: <1288054924-24989-1-git-send-email-nm@ti.com>
Message-ID: <4CC62B6C.30601@emk-elektronik.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear 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.

In such cases I prefer to use:

	uint64_t etime;
...
	etime = get_ticks() + get_tbclk(); /* 1 second */
	do {
		whatever;
		udelay (xx);
	} while (condition && get_ticks() <= etime);

That is far more accurate than calling udelay() 100000 times.
(depending on implementation and granularity udelay of a few usecs
might be rounded significantly)
You can still call udelay inside the loop if you don't want
to poll the condition too tightly...

Best Regards,
Reinhard