Adding new clocksource to powerpc kernel not working properly

[Matthias Dunda <lkml@ca.rtgf.de>]

Hi John, Paul and others,

I've been trying to implement a clocksource driver for my custom
hardware design, based on a MPC8568 PowerPC e500; kernel version
is 2.6.29.6-rt24.

It's an embedded device that has a dedicated hardware register which is
incremented on every tick from an oven-controlled quarz oscillator
running at 33 1/3 MHz, giving me a tick rate of exactly 30 ns.

The speciality about it is, that ticks can be inserted or removed in
hardware, to make it more accurate over time.

I've implemented the appropriate clocksource, and it works - generally.
/sys/devices..../current_clocksource shows me, that my driver is used.

For testing, I tried the following two things:

1.) make it run slower in hardware: every fourth tick, the register
isn't counted up, which means it runs approx. 20% slower

2.) change .mult in the driver to half of its valule, which should also
result in a approx. 50% slower timing.

On the command line, I then issue the following simple command:

while `true`; do date; time sleep 1; done

The result is something like

 Wed May 23 09:15:19 CEST 2012
 real    0m1.020s
 Wed May 23 09:15:21 CEST 2012
 real    0m1.020s
 Wed May 23 09:15:23 CEST 2012
 real    0m1.020s

Measured externally the one second sleep actually takes two seconds. The
system measured a real execution time of the once second sleep as one
second - what I expected it to do. BUT: the date command still keeps
track of the "outside" wall time - what I didn't expect.

I talked to John about this off-list already, and he was also confused
about this behaviour. He gave me hints to check deeper into the code -
thanks for this John - and indeed it looks like the e500 timebase is
hardcoded into the gettimeofday code.

I.e. in arch/powerpc/kernel/vdso32/vdso32.lds.S the routine
__do_get_xsec goes hardcoded onto the timebase registers by using mftbu
and mftbl instructions.

Also, the strace of the date command shows no calls to time,
gettimeofday,
or clock_gettime. (The same strace on my i386 desktop machine does.)

Thus, I follow John's recommendation to post the details here on the
list - as it is pratically not possible in this situation to provide the
kernel with a one-and-only clocksource, that is not "timebase".

A quick look at the latest git master revealed, that this code hasn't
changed since the rather old version I use.

Cheers

Matthias