From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nishanth Menon <nm@ti.com>
Date: Mon, 25 Oct 2010 20:18:57 -0500
Subject: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
In-Reply-To: <4CC62B6C.30601@emk-elektronik.de>
References: <1288054924-24989-1-git-send-email-nm@ti.com>
	<4CC62B6C.30601@emk-elektronik.de>
Message-ID: <4CC62C81.8000202@ti.com>
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

Reinhard Meyer had written, on 10/25/2010 08:14 PM, the following:
> 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...
hmmm.. almost like the jiffies in kernel ;).. timing wise, I see that 
the only benefit is that the approach gives a little more accuracy to 
the timeout delay - the other benefit is option to loop continuously 
instead of delaying with udelays - overall, at least the segments I saw 
had no reason to hit the registers so hard (alright we dont have much 
else to do.. but still).. I am very open to options from 
Sukumar(original author) as well..

-- 
Regards,
Nishanth Menon