From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.aribaud@free.fr>
Date: Mon, 24 Jan 2011 12:58:18 +0100
Subject: [U-Boot] [RFC] ARM timing code refactoring
In-Reply-To: <5A727AB5-C1C6-46D3-8C0B-A868EC6B1E7A@googlemail.com>
References: <4D3AAF63.1030600@free.fr>	<20110122191928.49E141365DB@gemini.denx.de>	<4D3B3B5C.2060205@free.fr>	<20110122212601.9C8A2B187@gemini.denx.de>	<4D3B5171.7090700@emk-elektronik.de>	<20110123101217.E31DFB335@gemini.denx.de>	<4D3C0271.4070306@emk-elektronik.de>	<20110123162312.CDEDE1365DB@gemini.denx.de>	<4D3C77BC.50006@emk-elektronik.de>	<20110123193502.3F2484B6@gemini.denx.de>	<4D3C96A9.7030402@free.fr>	<4D3C9BFC.1010907@emk-elektronik.de>	<20110123225758.222691365DB@gemini.denx.de>
	<4D3CD8FE.4040006@comcast.net> <4D3D2942.4060600@free.fr>
	<5A727AB5-C1C6-46D3-8C0B-A868EC6B1E7A@googlemail.com>
Message-ID: <4D3D695A.6060006@free.fr>
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

Hi Andreas,

Le 24/01/2011 09:25, Andreas Bie?mann a ?crit :

>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get_timer() as well for ms timings, provided we can convert
>> our timeout from ms to ticks, i.e.
>>
>> 	/* let's wait 200 milliseconds */
>> 	/* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
>> 	timeout = ms_to_ticks(200);
>> 	u32 start = get_timer(); /* start time, in ticks */
>> 	do {
>> 		...
>> 	} while ( (get_timer() -start)<  timeout);
>
> You may think about the following change to this proposal:
>
> /* lets wait 200 ms */
> /* get the end point of our timeout in ticks */
> u64 timeout_end = get_timer() + ms_to_ticks(200);
> do {
>   ...
> } while ( get_timer()<  timeout_end);

The problem here is that in the loop exit condition you replace a 
difference between two unsigned times (which always yields the correct 
duration) with a comparison of two dates (which does not).

For instance, if at loop entry get_timer() was, say, 10 ticks to 
rollover and the loop timing was 12 ticks, you end up with an end date 
of 2. If your loop body runs long enough, get_timer() may already have 
gone past this and will this stay greater than timeout_end for a very 
long time.

OTOH, using get_timer() on entry of loop and subtracting it from 
get_timer()@each loop iteration always yields the time elapsed, 
unaffected by rollover. You can then safely compare this elapsed time 
with the time-out value.

Amicalement,
-- 
Albert.