[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Pieter Voorthuijsen]

Hi Dirk,

My thoughs on /cpu/arm926ejs/davinci/timer.c:

/*
 * Timer runs with CFG_HZ_CLOCK, currently 27MHz. To avoid wrap
 * around of timestamp already after min ~159s, divide it, e.g. by 16.
 * timestamp will then wrap around all min ~42min
 */

That's true, if the period of the timer is set to 0xffffffff, but:

#define TIMER_LOAD_VAL  (CFG_HZ_CLOCK / CFG_HZ)
timer->prd34 = TIMER_LOAD_VAL;

The period of the timer is set to 1 ms, it counts to TIMER_LOAD_VAL and
resets to 0. So I thinks something else goes wrong.

In my idea these functions should do the following (with CFG_HZ=1000):

get_timer(ulong base) - Return time in ms  minus base
get_timer_masked(void) - Return time in ms

When we have our 64-bit timer, we don't need to do any wrapping or
overflow handling, get_timer_masked can just return "Hardware timer /
(CFG_HZ_CLOCK / CFG_HZ)" and be happy for 21664,5 years.

For info about the timer itself:
http://focus.ti.com/lit/ug/sprue26/sprue26.pdf

Best Regards,
Pieter








-----Original Message-----
From: Dirk Behme [mailto:dirk.behme at googlemail.com] 
Sent: vrijdag 21 maart 2008 12:34
Cc: Pieter Voorthuijsen
Subject: Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

Dirk Behme wrote:
> Pieter Voorthuijsen wrote:
> 
>> Hello,
>>
>> Some months ago, a patch was submitted ([ARM] fix timer overflow in 
>> DaVinci). The result was that in /cpu/arm926ejs/davinci/timer.c 
>> read_timer was divided by 16.
>> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=ea686f5
>> 2e4
>> 5b3df2938866d3f5a98bb2556dfe2b
>>
>> Right now, when I have my bootdelay variable (on a DVEVM) set to 2, 
>> and countdown takes 32 seconds... Also iprobe got very very  very
slow.
>> Maybe more items are affected by this timer division.

Haven't looked into the code, but just an idea: Why does the system
think it had to wait 32 seconds instead of 2 if timer is devided by 16?
Most probably cause anything tells him "x count values of counter are 1
second" or similiar? Maybe we simply have to adjust this "reference" by
16 as well? E.g. if now this reference is e.g. "32000 timer count values
are one second", then we have now to configure
(32000/16) = 2000 counter values are 1 second. I.e. for 2 seconds wait
4000 count values and not 64000?

What do you think?

Dirk