Re: [Linuxptp-devel] Is intel i350 ptp driver broken?
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 于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
Re: [Linuxptp-devel] Is intel i350 ptp driver broken?
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
[Linuxptp-devel] Is intel i350 ptp driver broken?
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? ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
