Hello Jacob, Thanks for your reply. Yes, I can use the phc_ctl set and I see the phc being updated to the current time of the day. If I try phc get, again I see only the nSec bits being updated. Looks like it is something to do with the drivers.
Regards Prathosh On Tue 15 Nov 2022 at 4:42 p.m., Jacob Keller <jacob.e.kel...@intel.com> wrote: > > > On 11/15/2022 4:58 AM, prathosh shastry wrote: > > Hello team, > > > > I had no issue with using software time stamping and also I am able to > > see the hardware timestamping support by building new kernel. But when I > > try to use the PHC, I see the PHC clock not being updated correctly. I > > see only the nSec bits being updated. Here are some of the tests I did. > > > > --------------------- > > /root@sama7g5ek-sd:~# phc_ctl eth0 get/ > > > > /phc_ctl[60533.796]: clock time is *1.010098874* or Thu Jan 1 > > *00:00:01* 1970/ > > > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > > > /phc_ctl[60536.812]: clock time is *1.015383981* or Thu Jan 1 > > *00:00:01* 1970/ > > > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > > > /phc_ctl[60541.072]: clock time is *1.022850092* or Thu Jan 1 > > *00:00:01* 1970/ > > > > Have you tried set to set the time? > > At a glance it looks like the MACB driver is doing a bunch of logic that > should be replaced by a timecounter+cyclecounter. > > I can't tell immediately if things are wrong but it looks odd. > > > /------------------------/ > > > > And also, I tried the PHC sanity check, and it fails to get the correct > > PHC time. > > > > ------------------------- > > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait > 10.0 > > get____/ > > > > /phc_ctl[61677.633]: adjusted clock frequency offset to > > 100000000.000000ppb____/ > > > > /phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan 1 > > 00:00:00 1970____/ > > > > /phc_ctl[61687.640]: process slept for 10.000000 seconds____/ > > > > /phc_ctl[61687.641]: clock time is *0.048045447* or Thu Jan 1 00:00:00 > > 1970____/ > > > > /__ __/ > > > > This is asking to set a full 10% faster, and we would expect to see a > value of 10 but we get a value 100x slower? This could be a frequency bug. > > > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait > 10.0 > > get____/ > > > > /phc_ctl[61700.096]: adjusted clock frequency offset to > > 100000000.000000ppb____/ > > > > /phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan 1 > > 00:00:00 1970____/ > > > > /phc_ctl[61710.103]: process slept for 10.000000 seconds____/ > > > > /phc_ctl[61710.104]: clock time is *0.088698838* or Thu Jan 1 00:00:00 > > 1970/ > > > > It would be great, if you could provide any information on this > > behaviour. Thanks > > > > > > Does a set (without the time value) work? This tries to set the clock to > match the current time of day according to the system. > > That is what the MACB driver appears to do during init, so its curious > you see such a small value.. Unless the particular hardware has a much > different interval value than the driver expects. > > Your best bet would probably be to talk to the maintainer of the > driver/hardware. > > Thanks, > Jake > > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
