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
