powerpc mvme5500 clock off by factor of 150

[Till Straumann]

Peter Dufault wrote:

>
> On Mar 6, 2005, at 3:20 PM, Peter Dufault wrote:
>
>> The clock on the MVME5500 seems to be off by a factor of 150...
>
>
> Here's what I've figured out this AM.
>
> The clock code that's used is the code in libcpu/powerpc/mpc6xx/clock.
>
>
> The clockIsr is going off every 57.9 seconds.
>
> In Clock_initialize the values are:
> BSP_bus_frequency 133333333 (correct)
> BSP_time_base_divisor 4000 

^^ the time base divisor is BSP dependent. Kate - how is the timebase
clocked on the MVME5500?

>
> rtems_configuration_get_microseconds_per_tick() 10000
> Clock_Decrementer_value 333330
>
>
> What is that loop in clockIsr doing where it loops until decr < 0? 

It doesn't loop until decr<0 but while decr < 0 to handle pathological
cases where interrupts are disabled for more than 1 clock tick (decrementer
underflow) in order for the software to catch up with the decr underflow.

This is important because on each IRQ we want to add the
period rather than simply resetting the decrementer (so the IRQ latency
doesn't keep adding up). Still the clock slips a little bit since the
'read-add-update' operation is not atomic.


Here's my quick [static, i.e., by looking at the code] analysis which
may be wrong - I didn't verify by testing!
 
---> initialization works like this:

- Clock_initialize() needs to be called
-> calculates decrementer value [clock period in decr/timebase tics]
-> initializes decrementer to -1; decrementer starts counting from 
0xffffffff
    towards 0.
-> connects ISR (BSP_connect_clock_handler())

BSP_connect_clock_handler() uses the wonderful ppc/shared IRQ API
and the 'irq_enable' method in turn calls 'clockOn()' which sets the
decrementer to its initial value.
  

T.

>
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>