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

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4D3C9BFC.1010907 at emk-elektronik.de> you wrote:
>
> >> get_timer() returns a monotonous upward counting time stamp with a
> >> resolution of milliseconds. After reaching ULONG_MAX the timer wraps
> >> around to 0.
> 
> Exactly that wrap makes the situation so complicated, since the simple code
> u32 get_timer(void)
> {
>   return (ticks * 1000ULL) / tickspersec;
> }
> won't do that wrap.

Do you have a better suggestion?

> >> The get_timer() implementation may be interrupt based and is only
> >> available after relocation.
> 
> Currently it is used before relocation in some places, I think I have
> seen it in NAND drivers... That would have to be changed then.

Indeed.  It is unreliable or even broken now.

> This is already implemented functionally very closely (apart from factoring and the
> get_timer(void) change) to this in AT91, the only (academic) hitch is that it will
> burp a few billion years after each reset :)

> What bothers me is the need for 64 bit mul/div in each loop iteration, for CPUs without
> hardware for that this might slow down data transfer loops of the style
> 
> u32 start_time = get_timer();
> do {
> 	if ("data_ready")
> 		/* transfer a byte */
> 	if (get_timer() - start_time > timeout)
> 		/* fail and exit loop */
> } while (--"bytestodo" > 0);
> 
> since get_timer() will be somewhat like:
> 
> 	return (tick * 1000ULL) / tickspersec;
> 
> As I stated before, tickspersec is a variable in, for example, AT91. So the
> expression cannot be optimized by the compiler.

I don't think this is the only way to implement this. How does Linux
derive time info from jiffies?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You get a wonderful view from the point of no return.
                                    - Terry Pratchett, _Making_Money_