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

[Albert ARIBAUD]

Le 24/01/2011 02:42, J. William Campbell a écrit :

> Hi All,
>             In order to avoid doing 64 bit math, we can define a "jiffie"
> or a "bogo_ms" that is the 64 bit timebase shifted right such that the
> lsb of the bottom 32 bits has a resolution of between 0.5 ms and 1 ms.
> It is then possible to convert the difference between two jiffie/bogo_ms
> values to a number of ms using a 32 bit multiply and a right shift of 16
> bits, with essentially negligible error.  get_bogo_ms() would return a
> 32 bit number in bogo_ms, thus the timing loop would be written.
>
> u32 start_time = get_bogo_ms();
> do {
>       if ("data_ready")
>           /* transfer a byte */
>       if (bogo_ms_to_ms(get_timer() - start_time)>   TIMEOUT_IN_MS)
>           /* fail and exit loop */
> } while (--"bytestodo">   0);
>
> u32 get_bogo_ms()
> {
>           u64 tick;
>           read(tick);
>
>            return (tick>>   gd->timer_shift);
> }
> u32 bogo_ms_to_ms(u32 x)
> {
>      /* this code assumes the resulting ms will be between 0 and 65535,
> or 65 seconds */
>          return ((x * gd->cvt_bogo_ms_to_ms)>>   16); /* cvt_bogo_ms_to_ms
> is a 16 bit binary fraction */
> }
>
> All the above code assumes timeouts are 65 seconds or less, which I
> think is probably fair. Conversion of ms values up to 65 seconds to
> bogo_ms is also easy, and a 32 bit multiplied result is all that is
> required.
> What is not so easy is converting a 32 bit timer value to ms.  It can be
> done if the CPU can do a 32 by 32 multiply to produce a 64 bit result,
> use the msb, and possibly correct the result by an add if  bit 32,of the
> timer is set.  You need a 33 bit counter in bogo_ms to get a monotonic,
> accurate 32 bit counter in ms. The powerpc can use a mulhw operation to
> do this, and any CPU that will produce a 64 bit product can do this.
> However, many CPUs do not produce 64 bit products easily. Using division
> to do these operations are even less appealing, as many CPUs do not
> provide hardware division at all. Since it is not necessary to do this
> conversion to easily use timeouts with 1 ms resolution and accuracy,  I
> think the idea of not using a timer in ms but rather bogo_ms/jiffies is
> possibly better?
>
> Best Regards,
> Bill Campbell

That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't 
have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would 
not go through the full 32-bit range, which would cause issues with the 
timing loops on rollover -- and while a timeout of more than 65 sec may 
not be too likely, a timeout starting near the wraparound value of 
bogo_ms still could happen.

Besides, the 'tick' unit of time makes physical sense but the bogo_ms 
would not, while still not being a common timing value -- reminds me of 
my ms_to_ticks conversion macro that Wolfgang did not like.

In a more general perspective, I'd like to see where where exactly we 
need 64-bit multiply/divide operations in Wolfgang's proposal before we 
try to get rid of it. In my understanding:

- get_timer() works in pure ticks, not ms, and thus does not need 
multiply/divide; it may at most need to implement a carry over from 32 
bit to 64 bits *if* the HW counter is 32 bits *and if* we want a 64-bit 
virtual counter.

- get_time() works in ms, and thus needs scale conversion, so possibly a 
multiply/divide but possibly some other method, to convert a tick value 
to an ms value.

That's where I come back to one point of my proposal: if we can get a 
general framework for get_timer() to return a 64-bit free-running tick 
value, then we might not need a ms-based get_time() at all, because we 
could use get_timer() as well for ms timings, provided we can convert 
our timeout from ms to ticks, i.e.

	/* let's wait 200 milliseconds */
	/* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
	timeout = ms_to_ticks(200);
	u32 start = get_timer(); /* start time, in ticks */
	do {
		...
	} while ( (get_timer() -start) < timeout);

This way, a timing loop would not involve anything more complex than a 
64-bit subtraction and comparison; the only division/multiplication 
involved would be in the timeout computation, out of the loop.

Amicalement,
-- 
Albert.