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

[J. William Campbell]

On 1/23/2011 2:57 PM, Wolfgang Denk wrote:
> 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?

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

> Best regards,
>
> Wolfgang Denk
>