> -----Original Message----- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Richard Cochran > Sent: Wednesday, June 05, 2019 8:21 PM > To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com> > Cc: da...@davemloft.net; Keller, Jacob E <jacob.e.kel...@intel.com>; > netdev@vger.kernel.org; nhor...@redhat.com; sassm...@redhat.com; Bowers, > AndrewX <andrewx.bow...@intel.com> > Subject: Re: [net-next 06/15] ixgbe: fix PTP SDP pin setup on X540 hardware > > On Wed, Jun 05, 2019 at 01:23:49PM -0700, Jeff Kirsher wrote: > > + * It calculates when the system time will be on an exact second, and then > > + * aligns the start of the PPS signal to that value. > > + * > > + * This works by using the cycle counter shift and mult values in reverse, > > and > > + * assumes that the values we're shifting will not overflow. > > So I guess that this device can't adjust the frequency in hardware, > and that is why the driver uses a timecounter. >
No. We use the timecounter to track the time offset, not the frequency. That is, our hardware can't represent 64bits of time, but it can adjust frequency. The time counter is used to track the adjustments from adjtime and set time, but not adjfreq. The timecounter is used to provide two features: (a) storing a full 64bits of time for passing back to the PTP stack and (b) atomic adjustments in adjtime. When programming the SDP we need to reverse the calculations done so that they're in terms of the SYSTIME values. But the frequency changes are all done directly to the SYSTIME increment values, and should be reflected properly in the pin output. > BUT your PPS will not be correct. You use the 'mult' to calculate the > future counter time of the PPS, but as soon as the PTP stack adjusts > the frequency (and changes 'mult') the PPS will occur at the wrong > time. Every path which changes mult (which is only link speed changes as far as I remember offhand) re-programs the PPS. We also re-program the pin at adjtime and settime. There should be no caller outside of our driver who adjusts the multiplier. Thanks, Jake > > Sorry to say it, > Richard
