On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: > Niklaus Giger wrote: > > static void rthal_set_local_cpu_timer(void) > > { > > +#ifndef CONFIG_40x > > long ticks; > > +#endif > > rthal_declare_cpuid; > > > > rthal_load_cpuid(); > > @@ -110,7 +112,7 @@ > > if (ns == 0) > > ticks = tb_ticks_per_jiffy; > > else { > > - ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ); > > + ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ); > > > > if (ticks > tb_ticks_per_jiffy) { > > DBG("rthal_set_cpu_timers_unsafe: -EINVAL (%lu)\n", ticks); > > My suggested fix was just to locate the source of the problem. As > Philippe suggested, we should use mulhwu (or mulhwu_scale_factor). Have > a look to arch/ppc/kernel/time.c for further information.
Ok, we can go for the lazy fix here, since this code is poised to disappear anyway. I've merged a variant of the above we already use for the ARM port, which scales down the period to microseconds instead of losing precision on the count of timebase ticks per jiffy. - ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ); + ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ); -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core