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

Reinhard Meyer
2011-05-31T04:36:22Z

Dear Graeme Russ,

> Hi Reinhard,
>
> On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
> <u-boot@emk-elektronik.de> wrote:
>> Dear Graeme Russ,
>>>
>>> Hi Reinhard,
>>>
>>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>>> <u-boot@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.
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...

Regards,

Reinhard