[U-Boot] [RFC] Review of U-Boot timer API

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

On 5/25/2011 12:46 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message<BANLkTikM3LPynzckNP64KjEQ5v+tE7yUhQ@mail.gmail.com>  you wrote:
>> I hope to get an implementation agreed upon that does not require
>> interrupts at all, provided a tick counter with sufficiently long roll
>> over time is available (longer than the maximum expected period
>> between 'related' get_timer() calls, for example calls to get_timer()
>> in a timeout testing while loop). This 'bare minimum' implementation
>> can be optionally augmented with an ISR which kicks the timer
>> calculation in the background (typically by just calling get_timer())
>>
>> It really is quite simple in the end.
> The length of this thread shows that it is not as simple as you want
> to make us believe.
>
>
>
> If all you have in mind are timeouts, then we don't need get_timer()
> at all.  We can implement all types of timeout where we wait for some
> eent to happen using udelay() alone.
>
> Need a 10 second timeout? Here we go:
>
> 	int cnt = 0;
> 	int limit = 10 * 1000;
> 	while (!condition) {
> 		usleep(1000); /* wait 1 millisec */
> 		if (++cnt>  limit)
> 			break;
> 	}
> 	if (cnt>  limit)
> 		error("timeout");
>
> get_timer() comes into play only if we want to calculate a time
> difference, for example if we want to run some code where we don't
> know how long it runs, and later come back and check if a certain
> amount of time has passed.
>
> When we don't know how long this code runs, we also cannot know (and
> espeically not in advance) wether or not this time will be longer or
> not than the rollover time of the tick counter.
>
>
> Your plan to require that get_timer() gets called "often enough" to
> prevent or detect tick counter overflows is putting things on their
> head.  It should be the opposite:  The implementation of get_timer()
> should be such that it becomes independent from such low level
> details.
>
HI all,
       We also cannot know if this code disables interrupts. If it does, 
the existing PPC design is broken. If interrupts are disabled during the 
entire code being executed, the elapsed run time will be 0. You can say 
that disabling interrupts in the code is not allowed. Fine, then that 
becomes a constraint on the code. Calling get_timer explicitly often 
enough is also a constraint on the code. One constraint is acceptable to 
you, the other is not. Ok, that's fine too. If the interrupt routine 
calls get_timer, then get_timer is called "often enough" and everything 
works the same as it presently does on PPC, It is not different than 
requiring the interrupt routine to be executed "often enough". The two 
methods are functionally identical. The only problems arise on systems 
that don't support interrupts and don't have any timers with enough bits 
available to meet the 4294967 seconds maximum interval requirement. 
Those systems will be "broken" no matter what we do, as we have all agreed.

     Right now, almost all ARM cases are broken, because they have short 
timers and don't use interrupts. In some cases, there are actual bugs 
involved. We can make these cases less broken than they now are with a 
common get_timer approach as outlined previously. However, we cannot fix 
them to the standard Wolfgang is stating here, to be not "broken". So, 
back to what I was asking before, is the improvement worth the effort if 
the result is still broken?

Best Regards,
Bill Campbell
> I have stated this before:  I consider any design that requires
> get_timer() to be called "often enough" broken.
>
> Best regards,
>
> Wolfgang Denk
>