Hello Egg Car, prompted by your discovery, I've tried comparing the datasheets for the 82576, 82580, i350/354 and i210. And after quite a bit of cross-checking between the sparse and "not quite comparable" datasheets, and the driver source code, I have to agree with your conclusion. It is quite probable. The Intel datasheets are not exactly comprehensive about the topic, but the driver is pretty consistent in treating the SYSTIM "the old way" for the i350. The final clue to me is probably the contents of igb_ptp_systim_to_hwtstamp() .
It is curious to me, why the driver doesn't make any use of the TIMADJH+TIMADJL registers (or just TIMADJ for the i210). At face value, these would seem quite useful for an atomic adjustment of the SYSTIM timebase... The description of the TIMADJ registers in the datasheets are otherwise another clue in favour of your conclusions. It's been an interesting read. For instance, I'm finally getting a grasp of how these NIC's actually mimick the frequency adjustment, using the TIMINCA register - and how that translates into the "sliding 8ns quantisation" seen on the output of the system during servo-regulated settling on an external 1PPS reference (that's phase-synchronous with an externally disciplined 25 MHz master clock). Frank On 26 May 2023 at 15:02, egg car wrote: Well I just read the i350 datasheet again and found why the driver was designed so. i350 SYSTIMH has only 8 valid bits, thus the SYSTIM could only count 2^40 ns aka 1099.5s. It's a bit complicated to use, I see why they use 'struct timecounter' instead of hardware PHC counter, and in this case all the timestamp regs cannot be used directly. Needs more time to find out how to fix this, either the driver or 'ts2phc' program. egg car <eggcar.l...@gmail.com> 于2023年5月26日周五 11:35写道： Hi Frantisek, Thanks for your detailed explanation, that makes things clear. 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. I have checked the i350/i210 datasheets at the beginning to figure out why they use different routine to process with SYSTIMx and AUXTSMPx. In fact, i350 implements old-style timestamp format like 82576(perhaps? I haven't check 82576 datasheet), the SYSTIMH and AUXTSMPH register value are in 2^32 ns resolution, while i210 simplified this with SYSTIMH(and other timestamp regs) value in 1sec resolution. 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. I'm using 'ts2phc' command in linuxptp project to adjust PHC timer. Yes the first step is to capture the 1PPS event timestamp and calculate a coarse offset value of 1PPS+linux system time with PHC SYSTIM, and then step the PHC time once. After the first time-step, the program use fine adjust method to track 1PPS. 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? Aha, yes I have searched the whole market trying to find an i350 nic that exports SDP pins out but failed. Then I fetched a reference design of i350 with 4 SFP ports, that all 4 SDP pins of each port are used for SFP functions. That makes things easier, I just disabled one SFP port by rewriting device id in eeprom, removed the 0Ω resistor between SDP pin and SFP connector, so I can connect an 1PPS signal into i350. Luckily I just need exact 3 SFP ports :) 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... I have the same doubts with that, if I didn't miss something elsewhere, the driver never write SYSTIMx value to the chip, how they made i350 work with PTP? Or just no one have ever tested that before? I'll try modifying the driver to see if that works, then post the result here later. Thanks again Frank Frantisek Rysanek <frantisek.rysa...@post.cz> 于2023年5月25日周四 21:58写道： 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
