RTEMS4.7 PPC clock(was Re: IRQ latency, mvme5500 v1.3 )

[Kate Feng]

I  agree with what Till Straumann suggested for the IRQ handling
and prioritization of the RTEMS-MVME5500 BSP.  Thanks again.

However, for the PPC shared file
c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c
in RTEMS4.7CVS,  can one  please replace the following:

-----------------------------------------------------------
void clockIsr(void *unused)
{
int decr;
 /*
   *  The driver has seen another tick.
   */
  do {
 asm volatile ("mfdec %0; add %0, %0, %1; mtdec
%0":"=&r"(decr):"r"(Clock_Decrementer_value));

 Clock_driver_ticks += 1;

 /*
  *  Real Time Clock counter/timer is set to automatically reload.
  */
 rtems_clock_tick();
  } while ( decr < 0 );
}
-------------------------------------------------------------

with the same implementation as RTEMS4.6.0 shown below
until a better algorithm proposed ?
-------------------------------------------------------------
void clockIsr(void *unused)
{
  /*
   *  The driver has seen another tick.
   */

  PPC_Set_decrementer( Clock_Decrementer_value );

  Clock_driver_ticks += 1;

  /*
   *  Real Time Clock counter/timer is set to automatically reload.
   */

  rtems_clock_tick();
}

--------------------------------------------------------------------
The reason ?

First, I do not think it's a good idea to disable interrupts
around the "asm volatile" code either.

Second,  does the new code fix a bug I am not aware of in 4.6.0 ?
Perhaps, I did'nt understand the code right or miss some point.
However, I stole the broken code to my version of RTEMS4.6.x
and ran the IRQ latency test. It actually did'nt improve the worst
and the average case.  I doubt the 4.7 compiler will make a
difference.    Besides, the  rtems_clock_get() reported that it
took 500.2 second to run the test, which is supposed to
be 500 seconds.  EPICS uses rtems_clock_get(), I think.  Anyway,
the  processor is so fast that I think the original code I got
from the RTEMS4.6 sufficient to be accurate.

Thanks,
Kate