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

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 23/01/2011 20:35, Wolfgang Denk a ?crit :

> At the moment I would suggest to change the existing interface like
> that:
>
> * Drop the set_timer() function.
>
> * Change get_timer() to take no argument, i. e.:
>
> 	unsigned long get_timer(void);
>
>    get_timer() returns a monotonous upward counting time stamp with a
>    resolution of milliseconds. After reaching ULONG_MAX the timer wraps
>    around to 0.
>
>    The get_timer() implementation may be interrupt based and is only
>    available after relocation.
>
> * Provide a fast, low-level, system dependent timer function
>
> 	unsigned long long get_ticks(void);
>
>    get_ticks() returns a monotonous upward counting time stamp with a
>    system-specific resolution. No assumptions should be made about the
>    resolution. After reaching ULLONG_MAX the timer wraps around to 0.
>
>    It is mandatory that get_ticks() is available before relocation.
>
> * Provide a set of utility functions:
>
>    ->	void wait_ticks(unsigned long ticks);
>
>    Delay execution for "ticks" ticks.
>
>    ->	unsigned long usec2ticks(unsigned long usec);
>
>    Convert microseconds into ticks; intended for SHORT delays only
>    (maximum depending on system clock, usually below 1 second).
>
>    ->	void __udelay(unsigned long usec);
>
>    Delay execution for "usec" microseconds; intended for SHORT delays
>    only (maximum depending on system clock, usually below 1 second).
>    If all architectures followed the above suggestion, we could move
>    the PPC implementation to common code:
>
>    	void __udelay(unsigned long usec)
> 	{
> 		ulong ticks = usec2ticks(usec);
> 		wait_ticks(ticks);
> 	}
>
>    __udelay() can reliably be used before relocation.
>
>    ->	void udelay(unsigned long usec)
>
>    Similar to __udelay() with the additional functionality to trigger
>    the watchdog timer for long delays.
>
>
>
>> that will not be possible on most hardware without complicated code.
>> We have discussed that long ago...
>
> I am aware of this.
>
>> 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?),
>
> See above.  For short, high resolution timeouts you can use
> get_ticks() and friends.  For long delays you can use get_timer().
>
> Note that "reasonable timeouts (up to a minute?)" are only very
> infrequently needed, and don't need the high resolution of
> get_ticks(), so these would naturally be implemented on the base of
> get_timer().
>
>
> We have been using this implementation for more than a decade on
> PowerPC.  The only thing you need is a monotonous upward counting
> 64 bit "time base" counter where you can read the system ticks from.
>
> Best regards,
>
> Wolfgang Denk

This proposal covers what I was thinking of (oubviously I had not looked 
into PPC implementations) and the few differences with my proposal are 
not worth fighting over, so overall I am fine with the above.

Let us hear from others now, and if we reach an agreement, then we'll 
start discussing implementation.

Amicalement,
-- 
Albert.