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

[Graeme Russ]

Hi Reinhard,

On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
<u-boot at emk-elektronik.de> wrote:
> Dear Graeme Russ,
>>
>> Hi Reinhard,
>>
>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>> <u-boot at emk-elektronik.de>  wrote:
>>>
>>> Dear ALL,
>>>
>>> it still escapes me why everyone tries to make things so complicated
>>> INSIDE the loop.
>>>
>>> Why not just define an API like this:
>>>
>>> u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */
>>> u32 start = get_timer();
>>>
>>> while ((get_timer() - start)<  timeout)
>>>    ...
>>
>> The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of
>> not calling make_timeout() and assuming get_timer() always has a 1ms
>> resolution
>
> If you think people cannot follow API conventions, then typedef it...
>
>>
>>> make_timeout() can be arch/soc/platform specific and take into account to
>>> return at least

Actually, make_timeout() would not need to be platform specific - All it
needs is a get_min_ms_resolution() which wuld be a simple inline usually
returning a const so the compiler would optimise it away

>>> 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))
>>                ...
>
> Again.. why put the complicated calculations INSIDE the loop?

Well, the calculations are hidden from the user, and we aren't running a
high performance system. Also, the most complex calculations will be
performed each time you call get_timer() anyway. The additional overhead
of performing a precision rounding will be insignificant

Best to make the API as defensive as possible rather than try to trim off
a few CPU instructions per loop.

Regards,

Graeme