[U-Boot] [RFC] ARM timing code refactoring

[Reinhard Meyer]

Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4D3C0271.4070306 at emk-elektronik.de>  you wrote:
>>
>> There were several suggestions about that in the past (including from me)
>> that involve rework everywhere HZ related timeouts are used. I still
>> prefer a method as follows (because it does not need repeated mul/div calculations
>> nor necessarily 64 bit arithmetic):
>>
>> u32 timeout = timeout_init(100); /* 100ms timeout */
>>
>> do {...} while (!timed_out(timeout));
>
> I dislike this approach. I immediately fear the same problem I just
> saw (incorrectly) in Albert's proposal - timeout_init() seems to
> store the timeouut information in some internal varoable, which is
> then checked by timed_out() - this is bound to fail as soon as
> somebody atttempts to nest timeouts.

Excuse me: the timeout info is stored in the user's variable "timeout",
that should be quite obvious!

Nested timeouts pose no problem as long as the user uses different (local)
vars to store the return value of timeout_init().

>
> Your implementation may be different, but you can bet sooner or later
> comes up with such a bugy implementation.

There is nothing buggy.

>
> And it is not needed.
>
> PLease see my proposal: we do not needs several timer or timeout
> related functions, all we need is a plain "get timer" function,
> without any arguments.  And the resulting code makes it obvious to the
> reader that such loops can be nested as you like.
>

If you demand that this get_timer returns in HZ units,
that will not be possible on most hardware without complicated code.
We have discussed that long ago...

>> time_out(x):
>>     return ((i32)(x - fast_tick))<  0;
>>
>> If the tick were really high speed (and then 64 bits),
>> fast_tick could be derived by shifting the tick some bits to the right.
>
> I have no idea what "fast_tick" versus "tick" means here, nor why we
> would need more than one tick.

Well, you could try to understand:
tick=the "at hardware speed running" timer, if that's incrementing too fast for
32 bit "timeout" vars for reasonable timeouts (up to a minute?),
it could be divided by a power of two before use,
or we plainly use u64 for the "timeout" variables; probably simpler than shifting...

Reinhard