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 >> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/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
