On 1/23/2011 2:57 PM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4d3c9bfc.1010...@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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
