On 25 May 2023 at 17:40, egg car wrote: > > Hi, > > I'm trying to use i350 adapter with a hardware 1pps signal input on a > SDP pin. > > I'm testing on kernel 5.19(i350 hardware ts capture function was > announced to be supported since kernel 5.17), using 'ts2phc' program > could capture the 1PPS input event, but it failed to write time > adjustment to the nic. > > Then I looked into igb driver source code, found these two function > 'igb_ptp_adjtime_82576' and 'igb_ptp_settime_82576' calculated the > target timecounter value, but doesn't write the target value to nic > register. In contrast to i210 routine which works > fine,'igb_ptp_adjtime_i210()' calls 'igb_ptp_write_i210()' method to > write target time value to SYSTIM registers. > > Did I miss something, or the igb_ptp driver is currently broken for > i350? > This is actually interesting :-) Thanks for the question. I myself am just a cheeky bystander, not in any way affiliated with Intel or anyone else here... I merely feel an urge to add my two cents worth.
If memory serves, the i210 and i350 feel very much like siblings. The launch dates at ark.intel.com are not identical, but they seem to share a lot in their feature set. Including e.g. the SDP pins. The i82576 seems like a predecessor of the i350, similarly to the i82574 being a predecessor to the i210. If you look into the lengthy comment at the top of the igb_ptp.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre e/drivers/net/ethernet/intel/igb/igb_ptp.c you'll notice that it describes the structure of the SYSTIM registers in the i82576 vs. the i82580. This seems to be outdated for the i210/i350, whose SYSTIM registers are "flat": 32bit seconds, 32bit nanoseconds, 8bit fractional sub-ns. Just check the datasheets of the i210/i350 and search for "SYSTIMR" = the sub-ns fractional register. Gets you straight to the chapter, describing the SYSTIM register contents and meaning. Thus, I agree that whatever the logic was for the 82576/82580, for the i350 I'd vote for a substitution of the i210-style access routines. I.e., in igb_ptp_init(), use the igb_ptp_settime_i210() . But, there may be another aspect. If I understand correctly, you're trying to respond to an event at the SDP input (1PPS in) by manipulating the SYSTIM register immediately = stepwise. Possibly by resetting the SYSTIML to 0 (plus maybe some estimate of your "IRQ response latency"). Note that if you're after ultimate precision, and you have a source of razor-sharp 1PPS, this is not the right way to adjust your PHC. Instead of introducing steps into your timebase, you can finely adjust the frequency of your PHC. These chips have a synth that can create a precise "virtual" clock out of your NIC's poor 25MHz Xtal. Several years ago, Richard Cochran has published a minimal example here on the mailing list: https://sourceforge.net/p/linuxptp/mailman/message/36151546/ Actually... it is appropriate to do an initial stepwise setting, and follow with continuous and gradual fine adjustment. Why the code is possibly broken for the i350... There's a strong possibility that my impression is off the mark. But I can't help thinking in the following way: The reference PCI-e board for the i210, by Intel, aka the i210-T1, has always had a header, or at least a pad footprint, for the SDP pins. Which has encouraged tinkerers to play, and driver maintainers to update the driver. In contrast, I've never seen an i350 board, where the SDP pins would be exposed. Thus, possibly, noone ever found out, that the timing stuff is not quite right. I'm actually amazed that you have access to those SDP signals on an i350, which is a BGA package. Do you have a custom designed board? Also, as suggested above, ptp4l and possibly other software, adjust the PHC by way of fine frequency adjustment. In the igb_ptp.c, I can actually see igb_ptp_adjfine_82580() used for the i210/i211, as well as for the i350. The function manipulates the TIMINCA register, which has probably retained its semantics through the ages... Which doesn't make perfect sense to me, because even without the SDP pins exposed, when using HW timestamping for PTP, I'd expect ptp4l to initially step-adjust the PHC, before starting the continuous-convergent servo... Should the initial stepwise adjustment fail, the subsequent continuous convergence would last pretty long... The truth is out there, somewhere :-) Frank _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
