[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[J. William Campbell <jwilliamcampbell@comcast.net>]

On 5/27/2011 10:53 PM, Graeme Russ wrote:
> Hi Bill,
>
> On 28/05/11 00:23, J. William Campbell wrote:
>> On 5/27/2011 12:35 AM, Graeme Russ wrote:
>>> Hi Wolfgang,
>>>
>>> On 27/05/11 17:13, Wolfgang Denk wrote:
>>>> Dear Graeme Russ,
>>>>
>>>> In message<BANLkTinWvY9b4QzeLNawF7MKT9z1zeMXyg@mail.gmail.com>   you wrote:
>>>>> I think we will need to define get_timer() weak - Nios will have to
>>>>> override the default implementation to cater for it's (Nios') limitations
>>>> Please don't  - isn't the purpose of this whole discussion to use
>>>> common code for this ?
>>>>
>>> Yes, but Nios is particularly bad - It has a 10ms tick counter :(
>> Hi All,
>>       And a hardware timer that you can't read to subdivide the 10 ms. Note
>> that this is not necessarily a problem with all NIOS implementations. The
>> timer characteristics can be controlled when you generate the bitstream for
>> the FPGA. You can make the counter both faster and readable if you want. It
>> just uses a bit more silicon. Sad to say, it probably will require  per
>> board get_ticks routine. For the "old" nios2 timers however, overriding
>> get_timer with a /board routine is probably the only way to go.
>>
> Actually, using the logic you presented in the "Remove calls to
> [get,reset]_timer outside arch/" thread, we could have a common get_timer()
> implementation which deals with all timer resolution issues:
>
> #if !defined(CONFIG_MIN_TIMER_RESOLUTION)
> #define CONFIG_MIN_TIMER_RESOLUTION 1
> #endif
>
> u32 get_timer(u32 base)
> {
> 	if (base != 0) {
> 		if (timer - base<  (CONFIG_MIN_TIMER_RESOLUTION * 2))
> 			return 0;
> 		else
> 			return timer - base - CONFIG_MIN_TIMER_RESOLUTION;
> 	} else {
> 		return timer;
> 	}
> }
>
> This would also guarantee that timeout loops run for _at least_ the timeout
> period
>
Hi Graeme,
       You are almost correct. The problem is that if you are calling 
get_timer early on in start-up, the timer can actually be 0. The loop 
initializing get_timer(0) will then return 0. If you can initialize the 
timer to a number !=0, then the above code works. If the timer is 
totally hardware derived, such an initialization may not be easy. For 
nios2, it is easy since the counter is software interrupt driven.  It 
can just be initialized to 1. The 10 ms updates will then run like 
normal. It also won't work if the user is doing his own timer arithmetic 
by subtracting get_timer(0) values, but there is nothing we can do about 
that case anyway so that case is moot. Good job of spotting this approach.

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
>
>