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

[Graeme Russ]

Hi Reinhard,

On Tue, May 31, 2011 at 2:36 PM, Reinhard Meyer
<u-boot at emk-elektronik.de> wrote:
> Dear 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.
>
> Excuse me, but THIS API does not prevent the user to do a
> "(get_timer() - start) < timeout" inside the loop, making your argument
> moot.

Ah true - Oops ;)

> But as I said before, it escapes me why by all means the loop must be more
> complicated
> and obscure (on the user side) then essentially necessary...
>

What about Simon's solution (next post):

u32 stop = time_get_future_ms(1234);

while (!time_reached(stop))
  ..

I really like the idea of a simple while(!something(whatever))

Regards,

Graeme