On Sun, Sep 09, 2007 at 07:55:35PM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > The solution now used by i386/x86-64/sparc64 is
> > CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> > to use something similar, but the generic code has some
>
> Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs
> to be a config option that can be turned on and off in the kernel
> config, or should it just be always on as on x86[-64]?
I believe that it can be turned on systematically. But
I only have 32 bit, non HV machines (basically 603e, 750,
and 74xx processors).
>
> > problems (it assumes that you have to set the clock
> > on a half-second, which is not the case of the RTC on
> > my boards to start with).
>
> Let's get the generic code fixed to do what we need then. Care to
> send a patch?
I'm unsure on how to implement it in a way acceptable
upstream, the problem is that the following lines:
if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
fail = update_persistent_clock(now);
next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec;
are hardwired to half a second. Can it be transformed into
a per arch static inline function defined in asm-${arch}?
There is also a possible problem in notify_cmos_timer, I believe
that the logic is wrong and the condition is reversed and should
be "if (!no_sync_cmos_clock)".
Otherwise the clock update timer will never be started! This boolean
really should be called disable_persistent_clock_updates or something
similar.
I'm really wondering how much testing all this code has had. The
more I look at the timekeeping code changes in the last months,
the less I understand them.
Gabriel
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
