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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
