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

[Graeme Russ]

On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
<u-boot at emk-elektronik.de> wrote:
> Dear Simon Glass,
>
>> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ<graeme.russ at 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!

> 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 ;)

Regards,

Graeme