[Xenomai] error / bugfix in ipipe-core-3-10.28-powerpc-1.patch (from eldk 5.5, company denx)

[Ralf <ralf.moder@mail.de>]

Hello,

i have found an error in the ipipe-patch above.
Here ist the error description:

Our system:
Linux 3.10.28 with xenomai 2.6 patch on a PowerPC MPC5200

Error description:
We use the xenomai-(posix-skin-)function clock_gettime(
CLOCK_HOST_REALTIME, ..) to read out our system time. Thus, we set up a
NTP clock that runs on an FPGA. Later, we compare the system time and
NTP time deviations. Unfortunately we recognize in any comparison with
the nanoseconds a deviation of at least 100 million nsecs. We then
started the xenomai test suite and get the following prints on our console:

root@hbm-000a0f(NFS):/$clocktest -D -C
42                                      
hostrt data area is
live                                                       
Sequence counter :
92323948                                                    
wall_time_sec    :
1395909476                                                  
wall_time_nsec   :
49                                                          
wall_to_monotonic                                                              

tv_sec : -1395754171                                                 
tv_nsec : 750313156                                                   
cycle_last       :
5127088924084                                               
mask             :
0xffffffffffffffff                                          
mult             :
508284933                                                   
shift            :
24                                                          
                                                                               

== Tested clock: 42
(CLOCK_HOST_REALTIME)                                      
CPU      ToD offset [us] ToD drift [us/s]      warps max delta
[us]            
--- -------------------- ---------------- ----------
--------------            
  0            -990145.8       -11538.531       2740         6253.3

As you can see, only 8 bits of the nanosecond value (wall_time_nsec)
will be displayed. Instrumentation (printks) has shown that these are
the most significant 8 bits of the value.

Reason:
The function tk_xtime(struct timekeeper *tk) (in file
include/linux/timekeeper_internal.h)

static inline struct timespec tk_xtime(struct timekeeper *tk)
{
    struct timespec ts;

    ts.tv_sec = tk->xtime_sec;
    ts.tv_nsec = (long)(tk->xtime_nsec >> tk->shift);
    return ts;
}

is applied twice to the system time. First in this function (in file
include/linux/timekeeper_internal.h):

static inline void update_vsyscall(struct timekeeper *tk)
{
    struct timespec xt;

    xt = tk_xtime(tk);
    update_vsyscall_old(&xt, &tk->wall_to_monotonic, tk->clock, tk->mult);
}

and then in this function (in file /kernel/ipipe/timer.c):

void ipipe_update_hostrt(struct timekeeper *tk)
{
    struct ipipe_hostrt_data data;
    struct timespec xt;

    xt = tk_xtime(tk);
    ipipe_root_only();
    data.live = 1;
    data.cycle_last = tk->clock->cycle_last;
    data.mask = tk->clock->mask;
    data.mult = tk->mult;
    data.shift = tk->shift;
    data.wall_time_sec = xt.tv_sec;
    data.wall_time_nsec = xt.tv_nsec;
    data.wall_to_monotonic = tk->wall_to_monotonic;
    __ipipe_notify_kevent(IPIPE_KEVT_HOSTRT, &data);
}

tk_xtime() makes a shift to the right on the nanoseconds. This shift is
at our clock source 24. If this shift now run twice consecutively, that
explains naturally why we only get the most significant 8 bits of the
nanosecond value.

a fix that might solve the problem, looks like this

void ipipe_update_hostrt(struct timekeeper *tk)
{
    struct ipipe_hostrt_data data;
    struct timespec xt;

//     xt = tk_xtime(tk);
    ipipe_root_only();
    data.live = 1;
    data.cycle_last = tk->clock->cycle_last;
    data.mask = tk->clock->mask;
    data.mult = tk->mult;
    data.shift = tk->shift;
    data.wall_time_sec = tk->xtime_sec;
    data.wall_time_nsec = (long)tk->xtime_nsec;
    data.wall_to_monotonic = tk->wall_to_monotonic;
    __ipipe_notify_kevent(IPIPE_KEVT_HOSTRT, &data);
}

I have successfully tested this fix on our system.

Regards

Ralf