From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Mon, 30 May 2011 22:46:38 +1000
Subject: [U-Boot] [RFC][Timer API] Revised Specification -
 Implementation details
In-Reply-To: <20110530123144.8C85514EBCB@gemini.denx.de>
References: <4DDE5548.3020906@gmail.com> <4DDE8639.3090909@comcast.net>
	<BANLkTinWvY9b4QzeLNawF7MKT9z1zeMXyg@mail.gmail.com>
	<20110527071355.5DA8014EF7F@gemini.denx.de>
	<4DDF543D.6020506@gmail.com>
	<20110527074832.5B98E1354FC@gemini.denx.de>
	<BANLkTimB4YKkpk10gZkoRmLUYqbPxTHUKQ@mail.gmail.com>
	<BANLkTik2SUm4Sm8aLjCrCmz+kcMGWgEzKw@mail.gmail.com>
	<20110527112721.9023C101D7A@gemini.denx.de>
	<BANLkTik2zUcKc2P6Vq7jStyQ06NBzqq-Pg@mail.gmail.com>
	<4DDFA206.5050101@psyent.com>
	<20110529155530.09A5F14EF7F@gemini.denx.de>
	<BANLkTim-JZyMmzw_tWHhHQQYoVmK9mZyVw@mail.gmail.com>
	<20110530105704.0C83F14EBCB@gemini.denx.de>
	<4DE383D3.7020008@gmail.com>
	<20110530123144.8C85514EBCB@gemini.denx.de>
Message-ID: <4DE391AE.2080203@gmail.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

Hi Wolfgang,

On 30/05/11 22:31, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4DE383D3.7020008@gmail.com> you wrote:
>>
>> Some platforms are _way_ worse than this - I am sure I have seen a udelay()
>> done with the millisecond time - So udelay(100) could be closer to
>> udelay(1000) - So your above 5 second delay could take as long as 50 seconds!!!
> 
> That should show up quickly as soon as you run a "sleep 5" command on
> the console (which is implemented like that).
> 
>>> 	while (test_for_event() == 0) {
>>> 		now = get_timer(0);
>>> 		if ((now - start) > timeout)
>>> 			handle_timeout();
>>>
>>> 		udelay(100);
>>> 	}
>>>
>>>    Here the loop overhead caused by short delay which may result in a
>>>    high number of calls to test_for_event() gets eliminated because
>>>    the time reference is independet of the delay.
>>
>> I personally think _any_ timeout greater than 1s (maybe even >500ms) should
>> be done this way
> 
> Agreed. As soon as the timeout is >> the interval size of the
> underlying timer service this is the best we can do.
> 
>>> 	start = get_timer(0);
>>>
>>> 	do_something_complicated();
>>>
>>> 	now = get_timer(0);
>>>
>>> 	printf("execution time: %ld millisec\n", now - start);
>>
>> Currently fails spectacularly if do_something_complicated() involves a
>> delay loop which calls reset_timer()
> 
> Note that I (intentionally) always used argument 0 in the calls to
> get_timer().  I think we really should get rid of this argument.
> 

Agreed - I am more than willing to update all existing timer usages to a
completely new set of timer API functions. I think suffering the pain of
moving to a more well defined API would be better than trying to clunk
around the existing one.

I think we all fairly well agree on how U-Boot will maintain a millisecond
(and possibly microsecond) timer in a platform independent manner using a
platform defined tick counter. Defining a timer API around that is simply a
matter of taste - particularly when it comes to dealing with precision
issues. I think your delta function is a good start - However maybe
something more like ms_delta(u32 from, u32 to) would be a more appropriate
name as it clears the way for us_delta()

Regards,

Graeme