Re: [Linuxptp-users] Issue with initial high jitter(Path Delay Variation)

[Sujatha G. <suj...@gm...>]

Hi Jacob,

I tried to test the driver with testptp and it seems to be working as
expected.

I was able to settime, gettime, adjtime, adjfreq got the expected values.


The setup I am using is explained below.


MASTER [Linux Ubuntu System with Oregano NIC card for Hardware Time
Stamping] < --> SLAVE [Xilinx FPGA Device which supports the HW time
stamping ]
Slave is getting its clock from an external clock source which is running
at 200MHz Frequency.

Xilinx Ethernet Driver which is used for HW timestamping, it is available
on github @
https://github.com/Xilinx/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_axienet_main.c

settime, gettime, adjtime, adjfreq functionality is developed in a separate
timer driver which is not available on the github but this driver is pretty
straight forward.


When debugging with PTP4l application, In the normal scenario if
step_threshold is set to 0.0, I have observed that
- during s1 state *adjtime *gets called with ADJ_SETOFFSET | ADJ_NANO modes
to adjust the clock.
- when slave moves to s2 state, upon receiving the sync and followup
packets, *adjfreq *is called for every 1 second to adjust the frequency of
the clock

adjtime and adjfreq are implemented in timer driver as below.


static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
{
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);

        int neg_adj = 0;
        u64 freq = 0;
        u32 diff = 0;
        u32 incval = 0;

        /* External clock source Frequency is 200MHz    which is driving
the timer  */
        /* adjust the RTC Increment Control register by (1/200MHZ = 5ns)  */
        /* resolution of the increment register is 1/1048576              */
        /* hence 5 * 1048576 = 0x500000 - value to be written to the
register */
        incval = 0x500000;

        if (ppb < 0) {
          neg_adj = 1;
          ppb = -ppb;
        }

        freq = incval;
        freq *= ppb;
        diff = div_u64(freq, 1000000000ULL);

        incval = neg_adj ? (incval - diff) : (incval + diff);

        /* Write the adjusted value to the *RTC Increment Value Control
Register* */
        /* Writing the adjustment value to this register intern adjusts the
nanoseconds register value by the hw */

        return 0;
}


static int xlnx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
        unsigned long flags = 0;
        struct xlnx_ptp_timer *timer = container_of(ptp, struct
xlnx_ptp_timer,
                                              ptp_clock_info);
        struct timespec offset, then = ns_to_timespec(delta);

        spin_lock_irqsave(&timer->reg_lock, flags);

        /* Read the seconds and nano seconds from the RTC Seconds and RTC
Nano Seconds Registers */
        xlnx_rtc_offset_read(timer, &offset);

        /* set the current offset values */
        offset = then;

        /* Write the seconds and nano seconds to the *RTC Seconds* and *RTC
Nano Seconds* Registers */
        xlnx_rtc_offset_write(timer, (const struct timespec *)&offset);

        spin_unlock_irqrestore(&timer->reg_lock, flags);
        return 0;
}


could you please review these functions and let us know if there are any
issues.


Thank you.


Best Regards,
Sujatha




On Wed, Feb 17, 2016 at 9:37 AM, Sujatha Guguloth <suj...@gm...>
wrote:

> Thank you Jocob and Lichavar for your quick replies.
>
> I will try with testptp.
>
> Best Regards,
> Sujatha
>
> On Wed, Feb 17, 2016 at 1:26 AM, Keller, Jacob E <jac...@in...
> > wrote:
>
>> Hi,
>>
>> On Tue, 2016-02-16 at 16:20 +0530, Sujatha Guguloth wrote:
>> > Hi Miroslav Lichvar,
>> >
>> > What aspects of driver/HW needs to be fixed. could you please
>> > elaborate more on this.
>> >
>> >
>> > Best Regards,
>> > Sujatha
>>
>> At this point, we really can't offer more advice unless the source is
>> available. The driver is definitely doing something funky as evidenced
>> above, and unless the driver is available we can't really comment.
>>
>> I suggest using the provided testptp tool provided in the Linux Kernel
>> documentation to do some sanity checks on all your ptp code paths for
>> adjtime, settime, gettime, adjfreq, etc. Verify these are doing what
>> you expect before you continue your debugging with ptp4l.
>>
>> Regards,
>> Jake
>
>
>