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

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear Graeme Russ,
> On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
> <u-boot@emk-elektronik.de>  wrote:
>> Dear Simon Glass,
>>
>>> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ<graeme.russ@gmail.com>
>>>   wrote:
>>>>
>>>> Hi Reinhard,
>>>>
>>>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>>>
>>> ...
>>>>>
>>>>> make_timeout() can be arch/soc/platform specific and take into account
>>>>> to return at least
>>>>> such a value that the timeout is never cut short. (In case of a 10 ms
>>>>> NIOS timer,
>>>>> make_timeout(5) would have to return the value 20, resulting in a real
>>>>> timeout of at least
>>>>> 10 ms but upto 20 ms )
>>>>
>>>> What about this:
>>>>
>>>>         u32 start = get_timer();
>>>>
>>>>         while (!timer_expired(start, timeout))
>>>>                 ...
>>>>
>>>
>>> Hi Graham,
>>>
>>> I like this, although I have a small preference for:
>>>
>>> u32 stop = time_get_future_ms(1234);
>>>
>>> while (!time_reached(stop))
>>>     ..
>>
>> I would perfectly like such a solution, it is equivalent to what I have been
>> proposing
>> almost a year ago!
>
> Don't forget the API will have a get_current_ms() so we can do duration
> measurements. So you could still accidentally do:
>
> 	u32 stop = get_current_ms() + 1234;
>
> bypassing the resolution correction. If time_reached() did the resolution
> correction, would this solve the problem of API misuse (yes, I know it puts
> a complicated calculation back in the loop)
>
>>> since it possibly means the processing happens up front. However any
>>> such function is good and I hope you can add it to your API.
>>
>> Exactly! And (saying it silently) this would not mandate that the now hidden
>> internal
>> timer needs to be in ms units, it could be the bare "natural" tick of the
>> hardware...
>> Making time_get_future() to return the "tick" (in whatever granularity) that
>> has to
>> be passed would reduce time_reached() to a very simple function.
>
> Half the point of refreshing the timer API was to solidify the fact that
> timers operate on a fixed time base (milliseconds or microseconds) so they
> can be used trivially for a variety of things (delays, timeouts, durations
> measurement etc). Ticks can be very short, so doing durations would require
> 64-bit 'start tick', and a conversion at the end:
>
> 	u64 start = get_current_tick();
> 	... do something ...
> 	u32 duration = ticks_to_ms(get_current_tick() - start);
>
> Yetch! - We will not be exposing ticks!

Moot argument again. Any fast 64 bit tick can be very simply brought into
a 32 bit, just sub-ms granularity by a simple right shift. But I would also
be happy with 64 bits as well, since all calculations in the loop would be just
add/subtracts and no mul/divs.

>
>> But I get the feeling that exactly this simplicity of above concept is the
>> problem
>> for people that have the urge to invent elaborate and complicated solutions
>> ;)
>
> I like simple as much as the next guy - I also like hard to misuse ;)

typedefs would prevent accidental misuses, there is no cure against deliberate
misuses except peer review...

Reinhard