2019-12-02 15:19:49 -08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/* Copyright (c) 2019 Intel Corporation */
|
|
|
|
|
|
|
|
#include "igc.h"
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/ptp_classify.h>
|
|
|
|
#include <linux/clocksource.h>
|
2020-08-20 16:02:17 -07:00
|
|
|
#include <linux/ktime.h>
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/iopoll.h>
|
2024-04-24 14:02:54 -07:00
|
|
|
#include <net/xdp_sock_drv.h>
|
2019-12-02 15:19:49 -08:00
|
|
|
|
|
|
|
#define INCVALUE_MASK 0x7fffffff
|
|
|
|
#define ISGN 0x80000000
|
|
|
|
|
|
|
|
#define IGC_PTP_TX_TIMEOUT (HZ * 15)
|
|
|
|
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
#define IGC_PTM_STAT_SLEEP 2
|
|
|
|
#define IGC_PTM_STAT_TIMEOUT 100
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
/* SYSTIM read access for I225 */
|
2020-09-02 16:36:56 -07:00
|
|
|
void igc_ptp_read(struct igc_adapter *adapter, struct timespec64 *ts)
|
2019-12-02 15:19:49 -08:00
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
u32 sec, nsec;
|
|
|
|
|
2020-08-20 16:02:16 -07:00
|
|
|
/* The timestamp is latched when SYSTIML is read. */
|
2019-12-02 15:19:49 -08:00
|
|
|
nsec = rd32(IGC_SYSTIML);
|
|
|
|
sec = rd32(IGC_SYSTIMH);
|
|
|
|
|
|
|
|
ts->tv_sec = sec;
|
|
|
|
ts->tv_nsec = nsec;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_ptp_write_i225(struct igc_adapter *adapter,
|
|
|
|
const struct timespec64 *ts)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
|
|
|
|
wr32(IGC_SYSTIML, ts->tv_nsec);
|
|
|
|
wr32(IGC_SYSTIMH, ts->tv_sec);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, long scaled_ppm)
|
|
|
|
{
|
|
|
|
struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
|
|
|
|
ptp_caps);
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
int neg_adj = 0;
|
|
|
|
u64 rate;
|
|
|
|
u32 inca;
|
|
|
|
|
|
|
|
if (scaled_ppm < 0) {
|
|
|
|
neg_adj = 1;
|
|
|
|
scaled_ppm = -scaled_ppm;
|
|
|
|
}
|
|
|
|
rate = scaled_ppm;
|
|
|
|
rate <<= 14;
|
|
|
|
rate = div_u64(rate, 78125);
|
|
|
|
|
|
|
|
inca = rate & INCVALUE_MASK;
|
|
|
|
if (neg_adj)
|
|
|
|
inca |= ISGN;
|
|
|
|
|
|
|
|
wr32(IGC_TIMINCA, inca);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_ptp_adjtime_i225(struct ptp_clock_info *ptp, s64 delta)
|
|
|
|
{
|
|
|
|
struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
|
|
|
|
ptp_caps);
|
|
|
|
struct timespec64 now, then = ns_to_timespec64(delta);
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
|
2020-09-02 16:36:56 -07:00
|
|
|
igc_ptp_read(igc, &now);
|
2019-12-02 15:19:49 -08:00
|
|
|
now = timespec64_add(now, then);
|
|
|
|
igc_ptp_write_i225(igc, (const struct timespec64 *)&now);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_ptp_gettimex64_i225(struct ptp_clock_info *ptp,
|
|
|
|
struct timespec64 *ts,
|
|
|
|
struct ptp_system_timestamp *sts)
|
|
|
|
{
|
|
|
|
struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
|
|
|
|
ptp_caps);
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
|
|
|
|
ptp_read_system_prets(sts);
|
|
|
|
ts->tv_nsec = rd32(IGC_SYSTIML);
|
|
|
|
ts->tv_sec = rd32(IGC_SYSTIMH);
|
2020-08-20 16:02:16 -07:00
|
|
|
ptp_read_system_postts(sts);
|
2019-12-02 15:19:49 -08:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_ptp_settime_i225(struct ptp_clock_info *ptp,
|
|
|
|
const struct timespec64 *ts)
|
|
|
|
{
|
|
|
|
struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
|
|
|
|
ptp_caps);
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
|
|
|
|
igc_ptp_write_i225(igc, ts);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
static void igc_pin_direction(int pin, int input, u32 *ctrl, u32 *ctrl_ext)
|
|
|
|
{
|
|
|
|
u32 *ptr = pin < 2 ? ctrl : ctrl_ext;
|
|
|
|
static const u32 mask[IGC_N_SDP] = {
|
|
|
|
IGC_CTRL_SDP0_DIR,
|
|
|
|
IGC_CTRL_SDP1_DIR,
|
|
|
|
IGC_CTRL_EXT_SDP2_DIR,
|
|
|
|
IGC_CTRL_EXT_SDP3_DIR,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (input)
|
|
|
|
*ptr &= ~mask[pin];
|
|
|
|
else
|
|
|
|
*ptr |= mask[pin];
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_pin_perout(struct igc_adapter *igc, int chan, int pin, int freq)
|
|
|
|
{
|
|
|
|
static const u32 igc_aux0_sel_sdp[IGC_N_SDP] = {
|
|
|
|
IGC_AUX0_SEL_SDP0, IGC_AUX0_SEL_SDP1, IGC_AUX0_SEL_SDP2, IGC_AUX0_SEL_SDP3,
|
|
|
|
};
|
|
|
|
static const u32 igc_aux1_sel_sdp[IGC_N_SDP] = {
|
|
|
|
IGC_AUX1_SEL_SDP0, IGC_AUX1_SEL_SDP1, IGC_AUX1_SEL_SDP2, IGC_AUX1_SEL_SDP3,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_en[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_EN, IGC_TS_SDP1_EN, IGC_TS_SDP2_EN, IGC_TS_SDP3_EN,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_sel_tt0[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_SEL_TT0, IGC_TS_SDP1_SEL_TT0,
|
|
|
|
IGC_TS_SDP2_SEL_TT0, IGC_TS_SDP3_SEL_TT0,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_sel_tt1[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_SEL_TT1, IGC_TS_SDP1_SEL_TT1,
|
|
|
|
IGC_TS_SDP2_SEL_TT1, IGC_TS_SDP3_SEL_TT1,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_sel_fc0[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_SEL_FC0, IGC_TS_SDP1_SEL_FC0,
|
|
|
|
IGC_TS_SDP2_SEL_FC0, IGC_TS_SDP3_SEL_FC0,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_sel_fc1[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_SEL_FC1, IGC_TS_SDP1_SEL_FC1,
|
|
|
|
IGC_TS_SDP2_SEL_FC1, IGC_TS_SDP3_SEL_FC1,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_sel_clr[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_SEL_FC1, IGC_TS_SDP1_SEL_FC1,
|
|
|
|
IGC_TS_SDP2_SEL_FC1, IGC_TS_SDP3_SEL_FC1,
|
|
|
|
};
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
u32 ctrl, ctrl_ext, tssdp = 0;
|
|
|
|
|
|
|
|
ctrl = rd32(IGC_CTRL);
|
|
|
|
ctrl_ext = rd32(IGC_CTRL_EXT);
|
|
|
|
tssdp = rd32(IGC_TSSDP);
|
|
|
|
|
|
|
|
igc_pin_direction(pin, 0, &ctrl, &ctrl_ext);
|
|
|
|
|
|
|
|
/* Make sure this pin is not enabled as an input. */
|
|
|
|
if ((tssdp & IGC_AUX0_SEL_SDP3) == igc_aux0_sel_sdp[pin])
|
|
|
|
tssdp &= ~IGC_AUX0_TS_SDP_EN;
|
|
|
|
|
|
|
|
if ((tssdp & IGC_AUX1_SEL_SDP3) == igc_aux1_sel_sdp[pin])
|
|
|
|
tssdp &= ~IGC_AUX1_TS_SDP_EN;
|
|
|
|
|
|
|
|
tssdp &= ~igc_ts_sdp_sel_clr[pin];
|
|
|
|
if (freq) {
|
|
|
|
if (chan == 1)
|
|
|
|
tssdp |= igc_ts_sdp_sel_fc1[pin];
|
|
|
|
else
|
|
|
|
tssdp |= igc_ts_sdp_sel_fc0[pin];
|
|
|
|
} else {
|
|
|
|
if (chan == 1)
|
|
|
|
tssdp |= igc_ts_sdp_sel_tt1[pin];
|
|
|
|
else
|
|
|
|
tssdp |= igc_ts_sdp_sel_tt0[pin];
|
|
|
|
}
|
|
|
|
tssdp |= igc_ts_sdp_en[pin];
|
|
|
|
|
|
|
|
wr32(IGC_TSSDP, tssdp);
|
|
|
|
wr32(IGC_CTRL, ctrl);
|
|
|
|
wr32(IGC_CTRL_EXT, ctrl_ext);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_pin_extts(struct igc_adapter *igc, int chan, int pin)
|
|
|
|
{
|
|
|
|
static const u32 igc_aux0_sel_sdp[IGC_N_SDP] = {
|
|
|
|
IGC_AUX0_SEL_SDP0, IGC_AUX0_SEL_SDP1, IGC_AUX0_SEL_SDP2, IGC_AUX0_SEL_SDP3,
|
|
|
|
};
|
|
|
|
static const u32 igc_aux1_sel_sdp[IGC_N_SDP] = {
|
|
|
|
IGC_AUX1_SEL_SDP0, IGC_AUX1_SEL_SDP1, IGC_AUX1_SEL_SDP2, IGC_AUX1_SEL_SDP3,
|
|
|
|
};
|
|
|
|
static const u32 igc_ts_sdp_en[IGC_N_SDP] = {
|
|
|
|
IGC_TS_SDP0_EN, IGC_TS_SDP1_EN, IGC_TS_SDP2_EN, IGC_TS_SDP3_EN,
|
|
|
|
};
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
u32 ctrl, ctrl_ext, tssdp = 0;
|
|
|
|
|
|
|
|
ctrl = rd32(IGC_CTRL);
|
|
|
|
ctrl_ext = rd32(IGC_CTRL_EXT);
|
|
|
|
tssdp = rd32(IGC_TSSDP);
|
|
|
|
|
|
|
|
igc_pin_direction(pin, 1, &ctrl, &ctrl_ext);
|
|
|
|
|
|
|
|
/* Make sure this pin is not enabled as an output. */
|
|
|
|
tssdp &= ~igc_ts_sdp_en[pin];
|
|
|
|
|
|
|
|
if (chan == 1) {
|
|
|
|
tssdp &= ~IGC_AUX1_SEL_SDP3;
|
|
|
|
tssdp |= igc_aux1_sel_sdp[pin] | IGC_AUX1_TS_SDP_EN;
|
|
|
|
} else {
|
|
|
|
tssdp &= ~IGC_AUX0_SEL_SDP3;
|
|
|
|
tssdp |= igc_aux0_sel_sdp[pin] | IGC_AUX0_TS_SDP_EN;
|
|
|
|
}
|
|
|
|
|
|
|
|
wr32(IGC_TSSDP, tssdp);
|
|
|
|
wr32(IGC_CTRL, ctrl);
|
|
|
|
wr32(IGC_CTRL_EXT, ctrl_ext);
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
static int igc_ptp_feature_enable_i225(struct ptp_clock_info *ptp,
|
|
|
|
struct ptp_clock_request *rq, int on)
|
|
|
|
{
|
2021-02-18 17:31:03 -08:00
|
|
|
struct igc_adapter *igc =
|
|
|
|
container_of(ptp, struct igc_adapter, ptp_caps);
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
unsigned long flags;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
struct timespec64 ts;
|
|
|
|
int use_freq = 0, pin = -1;
|
|
|
|
u32 tsim, tsauxc, tsauxc_mask, tsim_mask, trgttiml, trgttimh, freqout;
|
|
|
|
s64 ns;
|
2021-02-18 17:31:03 -08:00
|
|
|
|
|
|
|
switch (rq->type) {
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
case PTP_CLK_REQ_EXTTS:
|
|
|
|
/* Reject requests with unsupported flags */
|
|
|
|
if (rq->extts.flags & ~(PTP_ENABLE_FEATURE |
|
|
|
|
PTP_RISING_EDGE |
|
|
|
|
PTP_FALLING_EDGE |
|
|
|
|
PTP_STRICT_FLAGS))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
/* Reject requests failing to enable both edges. */
|
|
|
|
if ((rq->extts.flags & PTP_STRICT_FLAGS) &&
|
|
|
|
(rq->extts.flags & PTP_ENABLE_FEATURE) &&
|
|
|
|
(rq->extts.flags & PTP_EXTTS_EDGES) != PTP_EXTTS_EDGES)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (on) {
|
|
|
|
pin = ptp_find_pin(igc->ptp_clock, PTP_PF_EXTTS,
|
|
|
|
rq->extts.index);
|
|
|
|
if (pin < 0)
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
if (rq->extts.index == 1) {
|
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_TS1;
|
|
|
|
tsim_mask = IGC_TSICR_AUTT1;
|
|
|
|
} else {
|
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_TS0;
|
|
|
|
tsim_mask = IGC_TSICR_AUTT0;
|
|
|
|
}
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
tsauxc = rd32(IGC_TSAUXC);
|
|
|
|
tsim = rd32(IGC_TSIM);
|
|
|
|
if (on) {
|
|
|
|
igc_pin_extts(igc, rq->extts.index, pin);
|
|
|
|
tsauxc |= tsauxc_mask;
|
|
|
|
tsim |= tsim_mask;
|
|
|
|
} else {
|
|
|
|
tsauxc &= ~tsauxc_mask;
|
|
|
|
tsim &= ~tsim_mask;
|
|
|
|
}
|
|
|
|
wr32(IGC_TSAUXC, tsauxc);
|
|
|
|
wr32(IGC_TSIM, tsim);
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case PTP_CLK_REQ_PEROUT:
|
|
|
|
/* Reject requests with unsupported flags */
|
|
|
|
if (rq->perout.flags)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (on) {
|
|
|
|
pin = ptp_find_pin(igc->ptp_clock, PTP_PF_PEROUT,
|
|
|
|
rq->perout.index);
|
|
|
|
if (pin < 0)
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
ts.tv_sec = rq->perout.period.sec;
|
|
|
|
ts.tv_nsec = rq->perout.period.nsec;
|
|
|
|
ns = timespec64_to_ns(&ts);
|
|
|
|
ns = ns >> 1;
|
|
|
|
if (on && (ns <= 70000000LL || ns == 125000000LL ||
|
|
|
|
ns == 250000000LL || ns == 500000000LL)) {
|
|
|
|
if (ns < 8LL)
|
|
|
|
return -EINVAL;
|
|
|
|
use_freq = 1;
|
|
|
|
}
|
|
|
|
ts = ns_to_timespec64(ns);
|
|
|
|
if (rq->perout.index == 1) {
|
|
|
|
if (use_freq) {
|
2022-12-14 16:10:38 +08:00
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_CLK1 | IGC_TSAUXC_ST1;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
tsim_mask = 0;
|
|
|
|
} else {
|
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_TT1;
|
|
|
|
tsim_mask = IGC_TSICR_TT1;
|
|
|
|
}
|
|
|
|
trgttiml = IGC_TRGTTIML1;
|
|
|
|
trgttimh = IGC_TRGTTIMH1;
|
|
|
|
freqout = IGC_FREQOUT1;
|
|
|
|
} else {
|
|
|
|
if (use_freq) {
|
2022-12-14 16:10:38 +08:00
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_CLK0 | IGC_TSAUXC_ST0;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
tsim_mask = 0;
|
|
|
|
} else {
|
|
|
|
tsauxc_mask = IGC_TSAUXC_EN_TT0;
|
|
|
|
tsim_mask = IGC_TSICR_TT0;
|
|
|
|
}
|
|
|
|
trgttiml = IGC_TRGTTIML0;
|
|
|
|
trgttimh = IGC_TRGTTIMH0;
|
|
|
|
freqout = IGC_FREQOUT0;
|
|
|
|
}
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
tsauxc = rd32(IGC_TSAUXC);
|
|
|
|
tsim = rd32(IGC_TSIM);
|
|
|
|
if (rq->perout.index == 1) {
|
2022-12-14 16:10:38 +08:00
|
|
|
tsauxc &= ~(IGC_TSAUXC_EN_TT1 | IGC_TSAUXC_EN_CLK1 |
|
|
|
|
IGC_TSAUXC_ST1);
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
tsim &= ~IGC_TSICR_TT1;
|
|
|
|
} else {
|
2022-12-14 16:10:38 +08:00
|
|
|
tsauxc &= ~(IGC_TSAUXC_EN_TT0 | IGC_TSAUXC_EN_CLK0 |
|
|
|
|
IGC_TSAUXC_ST0);
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
tsim &= ~IGC_TSICR_TT0;
|
|
|
|
}
|
|
|
|
if (on) {
|
2023-06-15 12:00:43 +05:30
|
|
|
struct timespec64 safe_start;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
int i = rq->perout.index;
|
|
|
|
|
|
|
|
igc_pin_perout(igc, i, pin, use_freq);
|
2023-06-15 12:00:43 +05:30
|
|
|
igc_ptp_read(igc, &safe_start);
|
|
|
|
|
|
|
|
/* PPS output start time is triggered by Target time(TT)
|
|
|
|
* register. Programming any past time value into TT
|
|
|
|
* register will cause PPS to never start. Need to make
|
|
|
|
* sure we program the TT register a time ahead in
|
|
|
|
* future. There isn't a stringent need to fire PPS out
|
|
|
|
* right away. Adding +2 seconds should take care of
|
|
|
|
* corner cases. Let's say if the SYSTIML is close to
|
|
|
|
* wrap up and the timer keeps ticking as we program the
|
|
|
|
* register, adding +2seconds is safe bet.
|
|
|
|
*/
|
|
|
|
safe_start.tv_sec += 2;
|
|
|
|
|
|
|
|
if (rq->perout.start.sec < safe_start.tv_sec)
|
|
|
|
igc->perout[i].start.tv_sec = safe_start.tv_sec;
|
|
|
|
else
|
|
|
|
igc->perout[i].start.tv_sec = rq->perout.start.sec;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
igc->perout[i].start.tv_nsec = rq->perout.start.nsec;
|
|
|
|
igc->perout[i].period.tv_sec = ts.tv_sec;
|
|
|
|
igc->perout[i].period.tv_nsec = ts.tv_nsec;
|
2023-06-15 12:00:43 +05:30
|
|
|
wr32(trgttimh, (u32)igc->perout[i].start.tv_sec);
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
/* For now, always select timer 0 as source. */
|
2023-06-15 12:00:43 +05:30
|
|
|
wr32(trgttiml, (u32)(igc->perout[i].start.tv_nsec |
|
|
|
|
IGC_TT_IO_TIMER_SEL_SYSTIM0));
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
if (use_freq)
|
|
|
|
wr32(freqout, ns);
|
|
|
|
tsauxc |= tsauxc_mask;
|
|
|
|
tsim |= tsim_mask;
|
|
|
|
}
|
|
|
|
wr32(IGC_TSAUXC, tsauxc);
|
|
|
|
wr32(IGC_TSIM, tsim);
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
return 0;
|
|
|
|
|
2021-02-18 17:31:03 -08:00
|
|
|
case PTP_CLK_REQ_PPS:
|
|
|
|
spin_lock_irqsave(&igc->tmreg_lock, flags);
|
|
|
|
tsim = rd32(IGC_TSIM);
|
|
|
|
if (on)
|
|
|
|
tsim |= IGC_TSICR_SYS_WRAP;
|
|
|
|
else
|
|
|
|
tsim &= ~IGC_TSICR_SYS_WRAP;
|
|
|
|
igc->pps_sys_wrap_on = on;
|
|
|
|
wr32(IGC_TSIM, tsim);
|
|
|
|
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
static int igc_ptp_verify_pin(struct ptp_clock_info *ptp, unsigned int pin,
|
|
|
|
enum ptp_pin_function func, unsigned int chan)
|
|
|
|
{
|
|
|
|
switch (func) {
|
|
|
|
case PTP_PF_NONE:
|
|
|
|
case PTP_PF_EXTTS:
|
|
|
|
case PTP_PF_PEROUT:
|
|
|
|
break;
|
|
|
|
case PTP_PF_PHYSYNC:
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:50 -08:00
|
|
|
/**
|
|
|
|
* igc_ptp_systim_to_hwtstamp - convert system time value to HW timestamp
|
|
|
|
* @adapter: board private structure
|
|
|
|
* @hwtstamps: timestamp structure to update
|
|
|
|
* @systim: unsigned 64bit system time value
|
|
|
|
*
|
|
|
|
* We need to convert the system time value stored in the RX/TXSTMP registers
|
|
|
|
* into a hwtstamp which can be used by the upper level timestamping functions.
|
2023-01-31 13:54:37 -08:00
|
|
|
*
|
|
|
|
* Returns 0 on success.
|
2019-12-02 15:19:50 -08:00
|
|
|
**/
|
2023-01-31 13:54:37 -08:00
|
|
|
static int igc_ptp_systim_to_hwtstamp(struct igc_adapter *adapter,
|
|
|
|
struct skb_shared_hwtstamps *hwtstamps,
|
|
|
|
u64 systim)
|
2019-12-02 15:19:50 -08:00
|
|
|
{
|
|
|
|
switch (adapter->hw.mac.type) {
|
|
|
|
case igc_i225:
|
|
|
|
memset(hwtstamps, 0, sizeof(*hwtstamps));
|
|
|
|
/* Upper 32 bits contain s, lower 32 bits contain ns. */
|
|
|
|
hwtstamps->hwtstamp = ktime_set(systim >> 32,
|
|
|
|
systim & 0xFFFFFFFF);
|
|
|
|
break;
|
|
|
|
default:
|
2023-01-31 13:54:37 -08:00
|
|
|
return -EINVAL;
|
2019-12-02 15:19:50 -08:00
|
|
|
}
|
2023-01-31 13:54:37 -08:00
|
|
|
return 0;
|
2019-12-02 15:19:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2021-03-09 22:42:56 -08:00
|
|
|
* igc_ptp_rx_pktstamp - Retrieve timestamp from Rx packet buffer
|
2021-03-09 23:13:18 -08:00
|
|
|
* @adapter: Pointer to adapter the packet buffer belongs to
|
2023-09-21 18:40:49 -07:00
|
|
|
* @buf: Pointer to start of timestamp in HW format (2 32-bit words)
|
2019-12-02 15:19:50 -08:00
|
|
|
*
|
2023-09-21 18:40:49 -07:00
|
|
|
* This function retrieves and converts the timestamp stored at @buf
|
|
|
|
* to ktime_t, adjusting for hardware latencies.
|
2021-03-09 23:13:18 -08:00
|
|
|
*
|
|
|
|
* Returns timestamp value.
|
2021-03-09 22:42:56 -08:00
|
|
|
*/
|
2021-03-09 23:13:18 -08:00
|
|
|
ktime_t igc_ptp_rx_pktstamp(struct igc_adapter *adapter, __le32 *buf)
|
2019-12-02 15:19:50 -08:00
|
|
|
{
|
2021-03-09 23:13:18 -08:00
|
|
|
ktime_t timestamp;
|
|
|
|
u32 secs, nsecs;
|
2021-03-09 22:42:56 -08:00
|
|
|
int adjust;
|
|
|
|
|
2023-09-21 18:40:49 -07:00
|
|
|
nsecs = le32_to_cpu(buf[0]);
|
|
|
|
secs = le32_to_cpu(buf[1]);
|
2021-03-09 23:13:18 -08:00
|
|
|
|
|
|
|
timestamp = ktime_set(secs, nsecs);
|
2021-03-09 22:42:56 -08:00
|
|
|
|
|
|
|
/* Adjust timestamp for the RX latency based on link speed */
|
|
|
|
switch (adapter->link_speed) {
|
|
|
|
case SPEED_10:
|
|
|
|
adjust = IGC_I225_RX_LATENCY_10;
|
|
|
|
break;
|
|
|
|
case SPEED_100:
|
|
|
|
adjust = IGC_I225_RX_LATENCY_100;
|
|
|
|
break;
|
|
|
|
case SPEED_1000:
|
|
|
|
adjust = IGC_I225_RX_LATENCY_1000;
|
|
|
|
break;
|
|
|
|
case SPEED_2500:
|
|
|
|
adjust = IGC_I225_RX_LATENCY_2500;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
adjust = 0;
|
|
|
|
netdev_warn_once(adapter->netdev, "Imprecise timestamp\n");
|
|
|
|
break;
|
2019-12-02 15:19:50 -08:00
|
|
|
}
|
2021-03-09 23:13:18 -08:00
|
|
|
|
|
|
|
return ktime_sub_ns(timestamp, adjust);
|
2019-12-02 15:19:50 -08:00
|
|
|
}
|
|
|
|
|
2020-06-03 17:01:04 -07:00
|
|
|
static void igc_ptp_disable_rx_timestamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
u32 val;
|
2020-06-03 17:01:05 -07:00
|
|
|
int i;
|
2020-06-03 17:01:04 -07:00
|
|
|
|
|
|
|
wr32(IGC_TSYNCRXCTL, 0);
|
|
|
|
|
2020-06-03 17:01:05 -07:00
|
|
|
for (i = 0; i < adapter->num_rx_queues; i++) {
|
|
|
|
val = rd32(IGC_SRRCTL(i));
|
|
|
|
val &= ~IGC_SRRCTL_TIMESTAMP;
|
|
|
|
wr32(IGC_SRRCTL(i), val);
|
|
|
|
}
|
|
|
|
|
2020-06-03 17:01:04 -07:00
|
|
|
val = rd32(IGC_RXPBS);
|
|
|
|
val &= ~IGC_RXPBS_CFG_TS_EN;
|
|
|
|
wr32(IGC_RXPBS, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_ptp_enable_rx_timestamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
u32 val;
|
2020-06-03 17:01:05 -07:00
|
|
|
int i;
|
2020-06-03 17:01:04 -07:00
|
|
|
|
|
|
|
val = rd32(IGC_RXPBS);
|
|
|
|
val |= IGC_RXPBS_CFG_TS_EN;
|
|
|
|
wr32(IGC_RXPBS, val);
|
|
|
|
|
2020-06-03 17:01:05 -07:00
|
|
|
for (i = 0; i < adapter->num_rx_queues; i++) {
|
|
|
|
val = rd32(IGC_SRRCTL(i));
|
2023-09-21 18:40:49 -07:00
|
|
|
/* Enable retrieving timestamps from timer 0, the
|
|
|
|
* "adjustable clock" and timer 1 the "free running
|
|
|
|
* clock".
|
2020-06-03 17:01:05 -07:00
|
|
|
*/
|
2023-09-21 18:40:49 -07:00
|
|
|
val |= IGC_SRRCTL_TIMER1SEL(1) | IGC_SRRCTL_TIMER0SEL(0) |
|
2020-06-03 17:01:05 -07:00
|
|
|
IGC_SRRCTL_TIMESTAMP;
|
|
|
|
wr32(IGC_SRRCTL(i), val);
|
|
|
|
}
|
2020-06-03 17:01:04 -07:00
|
|
|
|
|
|
|
val = IGC_TSYNCRXCTL_ENABLED | IGC_TSYNCRXCTL_TYPE_ALL |
|
|
|
|
IGC_TSYNCRXCTL_RXSYNSIG;
|
|
|
|
wr32(IGC_TSYNCRXCTL, val);
|
|
|
|
}
|
|
|
|
|
2024-04-24 14:02:54 -07:00
|
|
|
static void igc_ptp_free_tx_buffer(struct igc_adapter *adapter,
|
|
|
|
struct igc_tx_timestamp_request *tstamp)
|
|
|
|
{
|
|
|
|
if (tstamp->buffer_type == IGC_TX_BUFFER_TYPE_XSK) {
|
|
|
|
/* Release the transmit completion */
|
|
|
|
tstamp->xsk_tx_buffer->xsk_pending_ts = false;
|
|
|
|
|
|
|
|
/* Note: tstamp->skb and tstamp->xsk_tx_buffer are in union.
|
|
|
|
* By setting tstamp->xsk_tx_buffer to NULL, tstamp->skb will
|
|
|
|
* become NULL as well.
|
|
|
|
*/
|
|
|
|
tstamp->xsk_tx_buffer = NULL;
|
|
|
|
tstamp->buffer_type = 0;
|
|
|
|
|
|
|
|
/* Trigger txrx interrupt for transmit completion */
|
|
|
|
igc_xsk_wakeup(adapter->netdev, tstamp->xsk_queue_index, 0);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_kfree_skb_any(tstamp->skb);
|
|
|
|
tstamp->skb = NULL;
|
|
|
|
}
|
|
|
|
|
2023-06-07 14:32:30 -07:00
|
|
|
static void igc_ptp_clear_tx_tstamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2023-07-28 17:17:59 -07:00
|
|
|
int i;
|
2023-06-07 14:32:30 -07:00
|
|
|
|
|
|
|
spin_lock_irqsave(&adapter->ptp_tx_lock, flags);
|
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
for (i = 0; i < IGC_MAX_TX_TSTAMP_REGS; i++) {
|
|
|
|
struct igc_tx_timestamp_request *tstamp = &adapter->tx_tstamp[i];
|
|
|
|
|
2024-04-24 14:02:54 -07:00
|
|
|
if (tstamp->skb)
|
|
|
|
igc_ptp_free_tx_buffer(adapter, tstamp);
|
2023-07-28 17:17:59 -07:00
|
|
|
}
|
2023-06-07 14:32:30 -07:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&adapter->ptp_tx_lock, flags);
|
|
|
|
}
|
|
|
|
|
2020-06-03 17:01:04 -07:00
|
|
|
static void igc_ptp_disable_tx_timestamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
2023-06-07 14:32:30 -07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Clear the flags first to avoid new packets to be enqueued
|
|
|
|
* for TX timestamping.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < adapter->num_tx_queues; i++) {
|
|
|
|
struct igc_ring *tx_ring = adapter->tx_ring[i];
|
|
|
|
|
|
|
|
clear_bit(IGC_RING_FLAG_TX_HWTSTAMP, &tx_ring->flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now we can clean the pending TX timestamp requests. */
|
|
|
|
igc_ptp_clear_tx_tstamp(adapter);
|
2020-06-03 17:01:04 -07:00
|
|
|
|
|
|
|
wr32(IGC_TSYNCTXCTL, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_ptp_enable_tx_timestamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
2023-06-07 14:32:30 -07:00
|
|
|
int i;
|
2020-06-03 17:01:04 -07:00
|
|
|
|
|
|
|
wr32(IGC_TSYNCTXCTL, IGC_TSYNCTXCTL_ENABLED | IGC_TSYNCTXCTL_TXSYNSIG);
|
|
|
|
|
|
|
|
/* Read TXSTMP registers to discard any timestamp previously stored. */
|
|
|
|
rd32(IGC_TXSTMPL);
|
|
|
|
rd32(IGC_TXSTMPH);
|
2023-06-07 14:32:30 -07:00
|
|
|
|
|
|
|
/* The hardware is ready to accept TX timestamp requests,
|
|
|
|
* notify the transmit path.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < adapter->num_tx_queues; i++) {
|
|
|
|
struct igc_ring *tx_ring = adapter->tx_ring[i];
|
|
|
|
|
|
|
|
set_bit(IGC_RING_FLAG_TX_HWTSTAMP, &tx_ring->flags);
|
|
|
|
}
|
|
|
|
|
2020-06-03 17:01:04 -07:00
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:50 -08:00
|
|
|
/**
|
|
|
|
* igc_ptp_set_timestamp_mode - setup hardware for timestamping
|
|
|
|
* @adapter: networking device structure
|
|
|
|
* @config: hwtstamp configuration
|
|
|
|
*
|
2020-06-03 17:01:03 -07:00
|
|
|
* Return: 0 in case of success, negative errno code otherwise.
|
2019-12-02 15:19:50 -08:00
|
|
|
*/
|
2019-12-02 15:19:49 -08:00
|
|
|
static int igc_ptp_set_timestamp_mode(struct igc_adapter *adapter,
|
|
|
|
struct hwtstamp_config *config)
|
|
|
|
{
|
2019-12-02 15:19:51 -08:00
|
|
|
switch (config->tx_type) {
|
|
|
|
case HWTSTAMP_TX_OFF:
|
2020-06-03 17:01:04 -07:00
|
|
|
igc_ptp_disable_tx_timestamp(adapter);
|
|
|
|
break;
|
2019-12-02 15:19:51 -08:00
|
|
|
case HWTSTAMP_TX_ON:
|
2020-06-03 17:01:04 -07:00
|
|
|
igc_ptp_enable_tx_timestamp(adapter);
|
2019-12-02 15:19:51 -08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -ERANGE;
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:50 -08:00
|
|
|
switch (config->rx_filter) {
|
|
|
|
case HWTSTAMP_FILTER_NONE:
|
2020-06-03 17:01:04 -07:00
|
|
|
igc_ptp_disable_rx_timestamp(adapter);
|
2019-12-02 15:19:50 -08:00
|
|
|
break;
|
|
|
|
case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_EVENT:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_SYNC:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
|
|
|
|
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
|
|
|
|
case HWTSTAMP_FILTER_NTP_ALL:
|
|
|
|
case HWTSTAMP_FILTER_ALL:
|
2020-06-03 17:01:04 -07:00
|
|
|
igc_ptp_enable_rx_timestamp(adapter);
|
2019-12-02 15:19:50 -08:00
|
|
|
config->rx_filter = HWTSTAMP_FILTER_ALL;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -ERANGE;
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
/* Requires adapter->ptp_tx_lock held by caller. */
|
2023-07-28 17:17:59 -07:00
|
|
|
static void igc_ptp_tx_timeout(struct igc_adapter *adapter,
|
|
|
|
struct igc_tx_timestamp_request *tstamp)
|
2020-06-03 17:01:01 -07:00
|
|
|
{
|
2024-04-24 14:02:54 -07:00
|
|
|
if (tstamp->skb)
|
|
|
|
igc_ptp_free_tx_buffer(adapter, tstamp);
|
|
|
|
|
2020-06-03 17:01:01 -07:00
|
|
|
adapter->tx_hwtstamp_timeouts++;
|
2023-07-28 17:17:59 -07:00
|
|
|
|
2020-06-03 17:01:01 -07:00
|
|
|
netdev_warn(adapter->netdev, "Tx timestamp timeout\n");
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
void igc_ptp_tx_hang(struct igc_adapter *adapter)
|
|
|
|
{
|
2023-07-28 17:17:59 -07:00
|
|
|
struct igc_tx_timestamp_request *tstamp;
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
unsigned long flags;
|
2023-07-28 17:17:59 -07:00
|
|
|
bool found = false;
|
|
|
|
int i;
|
2019-12-02 15:19:49 -08:00
|
|
|
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
spin_lock_irqsave(&adapter->ptp_tx_lock, flags);
|
2019-12-02 15:19:49 -08:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
for (i = 0; i < IGC_MAX_TX_TSTAMP_REGS; i++) {
|
|
|
|
tstamp = &adapter->tx_tstamp[i];
|
|
|
|
|
|
|
|
if (!tstamp->skb)
|
|
|
|
continue;
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
if (time_is_after_jiffies(tstamp->start + IGC_PTP_TX_TIMEOUT))
|
|
|
|
continue;
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
igc_ptp_tx_timeout(adapter, tstamp);
|
|
|
|
found = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (found) {
|
|
|
|
/* Reading the high register of the first set of timestamp registers
|
|
|
|
* clears all the equivalent bits in the TSYNCTXCTL register.
|
|
|
|
*/
|
|
|
|
rd32(IGC_TXSTMPH_0);
|
|
|
|
}
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&adapter->ptp_tx_lock, flags);
|
2019-12-02 15:19:49 -08:00
|
|
|
}
|
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
static void igc_ptp_tx_reg_to_stamp(struct igc_adapter *adapter,
|
|
|
|
struct igc_tx_timestamp_request *tstamp, u64 regval)
|
|
|
|
{
|
|
|
|
struct skb_shared_hwtstamps shhwtstamps;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
int adjust = 0;
|
|
|
|
|
|
|
|
skb = tstamp->skb;
|
|
|
|
if (!skb)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (igc_ptp_systim_to_hwtstamp(adapter, &shhwtstamps, regval))
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (adapter->link_speed) {
|
|
|
|
case SPEED_10:
|
|
|
|
adjust = IGC_I225_TX_LATENCY_10;
|
|
|
|
break;
|
|
|
|
case SPEED_100:
|
|
|
|
adjust = IGC_I225_TX_LATENCY_100;
|
|
|
|
break;
|
|
|
|
case SPEED_1000:
|
|
|
|
adjust = IGC_I225_TX_LATENCY_1000;
|
|
|
|
break;
|
|
|
|
case SPEED_2500:
|
|
|
|
adjust = IGC_I225_TX_LATENCY_2500;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
shhwtstamps.hwtstamp =
|
|
|
|
ktime_add_ns(shhwtstamps.hwtstamp, adjust);
|
|
|
|
|
2024-04-24 14:02:54 -07:00
|
|
|
/* Copy the tx hardware timestamp into xdp metadata or skb */
|
|
|
|
if (tstamp->buffer_type == IGC_TX_BUFFER_TYPE_XSK) {
|
|
|
|
struct xsk_buff_pool *xsk_pool;
|
|
|
|
|
|
|
|
xsk_pool = adapter->tx_ring[tstamp->xsk_queue_index]->xsk_pool;
|
|
|
|
if (xsk_pool && xp_tx_metadata_enabled(xsk_pool)) {
|
|
|
|
xsk_tx_metadata_complete(&tstamp->xsk_meta,
|
|
|
|
&igc_xsk_tx_metadata_ops,
|
|
|
|
&shhwtstamps.hwtstamp);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
skb_tstamp_tx(skb, &shhwtstamps);
|
|
|
|
}
|
2023-07-28 17:17:59 -07:00
|
|
|
|
2024-04-24 14:02:54 -07:00
|
|
|
igc_ptp_free_tx_buffer(adapter, tstamp);
|
2023-07-28 17:17:59 -07:00
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:51 -08:00
|
|
|
/**
|
|
|
|
* igc_ptp_tx_hwtstamp - utility function which checks for TX time stamp
|
|
|
|
* @adapter: Board private structure
|
|
|
|
*
|
2023-07-28 17:17:59 -07:00
|
|
|
* Check against the ready mask for which of the timestamp register
|
|
|
|
* sets are ready to be retrieved, then retrieve that and notify the
|
|
|
|
* rest of the stack.
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
*
|
|
|
|
* Context: Expects adapter->ptp_tx_lock to be held by caller.
|
2019-12-02 15:19:51 -08:00
|
|
|
*/
|
|
|
|
static void igc_ptp_tx_hwtstamp(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
u64 regval;
|
2023-07-28 17:17:59 -07:00
|
|
|
u32 mask;
|
|
|
|
int i;
|
2019-12-02 15:19:51 -08:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
mask = rd32(IGC_TSYNCTXCTL) & IGC_TSYNCTXCTL_TXTT_ANY;
|
|
|
|
if (mask & IGC_TSYNCTXCTL_TXTT_0) {
|
igc: Work around HW bug causing missing timestamps
There's an hardware issue that can cause missing timestamps. The bug
is that the interrupt is only cleared if the IGC_TXSTMPH_0 register is
read.
The bug can cause a race condition if a timestamp is captured at the
wrong time, and we will miss that timestamp. To reduce the time window
that the problem is able to happen, in case no timestamp was ready, we
read the "previous" value of the timestamp registers, and we compare
with the "current" one, if it didn't change we can be reasonably sure
that no timestamp was captured. If they are different, we use the new
value as the captured timestamp.
The HW bug is not easy to reproduce, got to reproduce it when smashing
the NIC with timestamping requests from multiple applications (e.g.
multiple ntpperf instances + ptp4l), after 10s of minutes.
This workaround has more impact when multiple timestamp registers are
used, and the IGC_TXSTMPH_0 register always need to be read, so the
interrupt is cleared.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:32 -07:00
|
|
|
regval = rd32(IGC_TXSTMPL);
|
|
|
|
regval |= (u64)rd32(IGC_TXSTMPH) << 32;
|
|
|
|
} else {
|
|
|
|
/* There's a bug in the hardware that could cause
|
|
|
|
* missing interrupts for TX timestamping. The issue
|
|
|
|
* is that for new interrupts to be triggered, the
|
|
|
|
* IGC_TXSTMPH_0 register must be read.
|
|
|
|
*
|
|
|
|
* To avoid discarding a valid timestamp that just
|
|
|
|
* happened at the "wrong" time, we need to confirm
|
|
|
|
* that there was no timestamp captured, we do that by
|
|
|
|
* assuming that no two timestamps in sequence have
|
|
|
|
* the same nanosecond value.
|
|
|
|
*
|
|
|
|
* So, we read the "low" register, read the "high"
|
|
|
|
* register (to latch a new timestamp) and read the
|
|
|
|
* "low" register again, if "old" and "new" versions
|
|
|
|
* of the "low" register are different, a valid
|
|
|
|
* timestamp was captured, we can read the "high"
|
|
|
|
* register again.
|
|
|
|
*/
|
|
|
|
u32 txstmpl_old, txstmpl_new;
|
|
|
|
|
|
|
|
txstmpl_old = rd32(IGC_TXSTMPL);
|
|
|
|
rd32(IGC_TXSTMPH);
|
|
|
|
txstmpl_new = rd32(IGC_TXSTMPL);
|
|
|
|
|
|
|
|
if (txstmpl_old == txstmpl_new)
|
2023-07-28 17:17:59 -07:00
|
|
|
goto done;
|
igc: Work around HW bug causing missing timestamps
There's an hardware issue that can cause missing timestamps. The bug
is that the interrupt is only cleared if the IGC_TXSTMPH_0 register is
read.
The bug can cause a race condition if a timestamp is captured at the
wrong time, and we will miss that timestamp. To reduce the time window
that the problem is able to happen, in case no timestamp was ready, we
read the "previous" value of the timestamp registers, and we compare
with the "current" one, if it didn't change we can be reasonably sure
that no timestamp was captured. If they are different, we use the new
value as the captured timestamp.
The HW bug is not easy to reproduce, got to reproduce it when smashing
the NIC with timestamping requests from multiple applications (e.g.
multiple ntpperf instances + ptp4l), after 10s of minutes.
This workaround has more impact when multiple timestamp registers are
used, and the IGC_TXSTMPH_0 register always need to be read, so the
interrupt is cleared.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:32 -07:00
|
|
|
|
|
|
|
regval = txstmpl_new;
|
|
|
|
regval |= (u64)rd32(IGC_TXSTMPH) << 32;
|
|
|
|
}
|
2019-12-02 15:19:51 -08:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
igc_ptp_tx_reg_to_stamp(adapter, &adapter->tx_tstamp[0], regval);
|
2020-08-18 16:40:02 -07:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
done:
|
|
|
|
/* Now that the problematic first register was handled, we can
|
|
|
|
* use retrieve the timestamps from the other registers
|
|
|
|
* (starting from '1') with less complications.
|
|
|
|
*/
|
|
|
|
for (i = 1; i < IGC_MAX_TX_TSTAMP_REGS; i++) {
|
|
|
|
struct igc_tx_timestamp_request *tstamp = &adapter->tx_tstamp[i];
|
2020-08-18 16:40:02 -07:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
if (!(tstamp->mask & mask))
|
|
|
|
continue;
|
2019-12-02 15:19:51 -08:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
regval = rd32(tstamp->regl);
|
|
|
|
regval |= (u64)rd32(tstamp->regh) << 32;
|
|
|
|
|
|
|
|
igc_ptp_tx_reg_to_stamp(adapter, tstamp, regval);
|
|
|
|
}
|
2019-12-02 15:19:51 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-06-07 14:32:31 -07:00
|
|
|
* igc_ptp_tx_tstamp_event
|
|
|
|
* @adapter: board private structure
|
2019-12-02 15:19:51 -08:00
|
|
|
*
|
2023-06-07 14:32:31 -07:00
|
|
|
* Called when a TX timestamp interrupt happens to retrieve the
|
|
|
|
* timestamp and send it up to the socket.
|
2019-12-02 15:19:51 -08:00
|
|
|
*/
|
2023-06-07 14:32:31 -07:00
|
|
|
void igc_ptp_tx_tstamp_event(struct igc_adapter *adapter)
|
2019-12-02 15:19:49 -08:00
|
|
|
{
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
unsigned long flags;
|
2019-12-02 15:19:51 -08:00
|
|
|
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
spin_lock_irqsave(&adapter->ptp_tx_lock, flags);
|
|
|
|
|
2020-07-28 16:37:52 -07:00
|
|
|
igc_ptp_tx_hwtstamp(adapter);
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&adapter->ptp_tx_lock, flags);
|
2019-12-02 15:19:49 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* igc_ptp_set_ts_config - set hardware time stamping config
|
|
|
|
* @netdev: network interface device structure
|
2020-09-25 15:24:37 -07:00
|
|
|
* @ifr: interface request data
|
2019-12-02 15:19:49 -08:00
|
|
|
*
|
|
|
|
**/
|
|
|
|
int igc_ptp_set_ts_config(struct net_device *netdev, struct ifreq *ifr)
|
|
|
|
{
|
|
|
|
struct igc_adapter *adapter = netdev_priv(netdev);
|
|
|
|
struct hwtstamp_config config;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
err = igc_ptp_set_timestamp_mode(adapter, &config);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* save these settings for future reference */
|
|
|
|
memcpy(&adapter->tstamp_config, &config,
|
|
|
|
sizeof(adapter->tstamp_config));
|
|
|
|
|
|
|
|
return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
|
|
|
|
-EFAULT : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* igc_ptp_get_ts_config - get hardware time stamping config
|
|
|
|
* @netdev: network interface device structure
|
2020-09-25 15:24:37 -07:00
|
|
|
* @ifr: interface request data
|
2019-12-02 15:19:49 -08:00
|
|
|
*
|
|
|
|
* Get the hwtstamp_config settings to return to the user. Rather than attempt
|
|
|
|
* to deconstruct the settings from the registers, just return a shadow copy
|
|
|
|
* of the last known settings.
|
|
|
|
**/
|
|
|
|
int igc_ptp_get_ts_config(struct net_device *netdev, struct ifreq *ifr)
|
|
|
|
{
|
|
|
|
struct igc_adapter *adapter = netdev_priv(netdev);
|
|
|
|
struct hwtstamp_config *config = &adapter->tstamp_config;
|
|
|
|
|
|
|
|
return copy_to_user(ifr->ifr_data, config, sizeof(*config)) ?
|
|
|
|
-EFAULT : 0;
|
|
|
|
}
|
|
|
|
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
/* The two conditions below must be met for cross timestamping via
|
|
|
|
* PCIe PTM:
|
|
|
|
*
|
|
|
|
* 1. We have an way to convert the timestamps in the PTM messages
|
|
|
|
* to something related to the system clocks (right now, only
|
|
|
|
* X86 systems with support for the Always Running Timer allow that);
|
|
|
|
*
|
|
|
|
* 2. We have PTM enabled in the path from the device to the PCIe root port.
|
|
|
|
*/
|
|
|
|
static bool igc_is_crosststamp_supported(struct igc_adapter *adapter)
|
|
|
|
{
|
2021-12-13 16:39:49 -08:00
|
|
|
if (!IS_ENABLED(CONFIG_X86_TSC))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* FIXME: it was noticed that enabling support for PCIe PTM in
|
|
|
|
* some i225-V models could cause lockups when bringing the
|
|
|
|
* interface up/down. There should be no downsides to
|
|
|
|
* disabling crosstimestamping support for i225-V, as it
|
|
|
|
* doesn't have any PTP support. That way we gain some time
|
|
|
|
* while root causing the issue.
|
|
|
|
*/
|
|
|
|
if (adapter->pdev->device == IGC_DEV_ID_I225_V)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return pcie_ptm_enabled(adapter->pdev);
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct system_counterval_t igc_device_tstamp_to_system(u64 tstamp)
|
|
|
|
{
|
2021-10-13 22:05:16 -07:00
|
|
|
#if IS_ENABLED(CONFIG_X86_TSC) && !defined(CONFIG_UML)
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
return convert_art_ns_to_tsc(tstamp);
|
|
|
|
#else
|
|
|
|
return (struct system_counterval_t) { };
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_ptm_log_error(struct igc_adapter *adapter, u32 ptm_stat)
|
|
|
|
{
|
|
|
|
struct net_device *netdev = adapter->netdev;
|
|
|
|
|
|
|
|
switch (ptm_stat) {
|
|
|
|
case IGC_PTM_STAT_RET_ERR:
|
|
|
|
netdev_err(netdev, "PTM Error: Root port timeout\n");
|
|
|
|
break;
|
|
|
|
case IGC_PTM_STAT_BAD_PTM_RES:
|
|
|
|
netdev_err(netdev, "PTM Error: Bad response, PTM Response Data expected\n");
|
|
|
|
break;
|
|
|
|
case IGC_PTM_STAT_T4M1_OVFL:
|
|
|
|
netdev_err(netdev, "PTM Error: T4 minus T1 overflow\n");
|
|
|
|
break;
|
|
|
|
case IGC_PTM_STAT_ADJUST_1ST:
|
|
|
|
netdev_err(netdev, "PTM Error: 1588 timer adjusted during first PTM cycle\n");
|
|
|
|
break;
|
|
|
|
case IGC_PTM_STAT_ADJUST_CYC:
|
|
|
|
netdev_err(netdev, "PTM Error: 1588 timer adjusted during non-first PTM cycle\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
netdev_err(netdev, "PTM Error: Unknown error (%#x)\n", ptm_stat);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_phc_get_syncdevicetime(ktime_t *device,
|
|
|
|
struct system_counterval_t *system,
|
|
|
|
void *ctx)
|
|
|
|
{
|
|
|
|
u32 stat, t2_curr_h, t2_curr_l, ctrl;
|
|
|
|
struct igc_adapter *adapter = ctx;
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
int err, count = 100;
|
|
|
|
ktime_t t1, t2_curr;
|
|
|
|
|
|
|
|
/* Get a snapshot of system clocks to use as historic value. */
|
|
|
|
ktime_get_snapshot(&adapter->snapshot);
|
|
|
|
|
|
|
|
do {
|
|
|
|
/* Doing this in a loop because in the event of a
|
|
|
|
* badly timed (ha!) system clock adjustment, we may
|
|
|
|
* get PTM errors from the PCI root, but these errors
|
|
|
|
* are transitory. Repeating the process returns valid
|
|
|
|
* data eventually.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* To "manually" start the PTM cycle we need to clear and
|
|
|
|
* then set again the TRIG bit.
|
|
|
|
*/
|
|
|
|
ctrl = rd32(IGC_PTM_CTRL);
|
|
|
|
ctrl &= ~IGC_PTM_CTRL_TRIG;
|
|
|
|
wr32(IGC_PTM_CTRL, ctrl);
|
|
|
|
ctrl |= IGC_PTM_CTRL_TRIG;
|
|
|
|
wr32(IGC_PTM_CTRL, ctrl);
|
|
|
|
|
|
|
|
/* The cycle only starts "for real" when software notifies
|
|
|
|
* that it has read the registers, this is done by setting
|
|
|
|
* VALID bit.
|
|
|
|
*/
|
|
|
|
wr32(IGC_PTM_STAT, IGC_PTM_STAT_VALID);
|
|
|
|
|
|
|
|
err = readx_poll_timeout(rd32, IGC_PTM_STAT, stat,
|
|
|
|
stat, IGC_PTM_STAT_SLEEP,
|
|
|
|
IGC_PTM_STAT_TIMEOUT);
|
|
|
|
if (err < 0) {
|
|
|
|
netdev_err(adapter->netdev, "Timeout reading IGC_PTM_STAT register\n");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((stat & IGC_PTM_STAT_VALID) == IGC_PTM_STAT_VALID)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (stat & ~IGC_PTM_STAT_VALID) {
|
|
|
|
/* An error occurred, log it. */
|
|
|
|
igc_ptm_log_error(adapter, stat);
|
|
|
|
/* The STAT register is write-1-to-clear (W1C),
|
|
|
|
* so write the previous error status to clear it.
|
|
|
|
*/
|
|
|
|
wr32(IGC_PTM_STAT, stat);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} while (--count);
|
|
|
|
|
|
|
|
if (!count) {
|
|
|
|
netdev_err(adapter->netdev, "Exceeded number of tries for PTM cycle\n");
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
t1 = ktime_set(rd32(IGC_PTM_T1_TIM0_H), rd32(IGC_PTM_T1_TIM0_L));
|
|
|
|
|
|
|
|
t2_curr_l = rd32(IGC_PTM_CURR_T2_L);
|
|
|
|
t2_curr_h = rd32(IGC_PTM_CURR_T2_H);
|
|
|
|
|
|
|
|
/* FIXME: When the register that tells the endianness of the
|
|
|
|
* PTM registers are implemented, check them here and add the
|
|
|
|
* appropriate conversion.
|
|
|
|
*/
|
|
|
|
t2_curr_h = swab32(t2_curr_h);
|
|
|
|
|
|
|
|
t2_curr = ((s64)t2_curr_h << 32 | t2_curr_l);
|
|
|
|
|
|
|
|
*device = t1;
|
|
|
|
*system = igc_device_tstamp_to_system(t2_curr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int igc_ptp_getcrosststamp(struct ptp_clock_info *ptp,
|
|
|
|
struct system_device_crosststamp *cts)
|
|
|
|
{
|
|
|
|
struct igc_adapter *adapter = container_of(ptp, struct igc_adapter,
|
|
|
|
ptp_caps);
|
|
|
|
|
|
|
|
return get_device_system_crosststamp(igc_phc_get_syncdevicetime,
|
|
|
|
adapter, &adapter->snapshot, cts);
|
|
|
|
}
|
|
|
|
|
2023-09-21 18:40:49 -07:00
|
|
|
static int igc_ptp_getcyclesx64(struct ptp_clock_info *ptp,
|
|
|
|
struct timespec64 *ts,
|
|
|
|
struct ptp_system_timestamp *sts)
|
|
|
|
{
|
|
|
|
struct igc_adapter *igc = container_of(ptp, struct igc_adapter, ptp_caps);
|
|
|
|
struct igc_hw *hw = &igc->hw;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&igc->free_timer_lock, flags);
|
|
|
|
|
|
|
|
ptp_read_system_prets(sts);
|
|
|
|
ts->tv_nsec = rd32(IGC_SYSTIML_1);
|
|
|
|
ts->tv_sec = rd32(IGC_SYSTIMH_1);
|
|
|
|
ptp_read_system_postts(sts);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&igc->free_timer_lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
/**
|
|
|
|
* igc_ptp_init - Initialize PTP functionality
|
|
|
|
* @adapter: Board private structure
|
|
|
|
*
|
|
|
|
* This function is called at device probe to initialize the PTP
|
|
|
|
* functionality.
|
|
|
|
*/
|
|
|
|
void igc_ptp_init(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct net_device *netdev = adapter->netdev;
|
2023-07-28 17:17:59 -07:00
|
|
|
struct igc_tx_timestamp_request *tstamp;
|
2019-12-02 15:19:49 -08:00
|
|
|
struct igc_hw *hw = &adapter->hw;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
int i;
|
2019-12-02 15:19:49 -08:00
|
|
|
|
2023-07-28 17:17:59 -07:00
|
|
|
tstamp = &adapter->tx_tstamp[0];
|
|
|
|
tstamp->mask = IGC_TSYNCTXCTL_TXTT_0;
|
|
|
|
tstamp->regl = IGC_TXSTMPL_0;
|
|
|
|
tstamp->regh = IGC_TXSTMPH_0;
|
|
|
|
tstamp->flags = 0;
|
|
|
|
|
|
|
|
tstamp = &adapter->tx_tstamp[1];
|
|
|
|
tstamp->mask = IGC_TSYNCTXCTL_TXTT_1;
|
|
|
|
tstamp->regl = IGC_TXSTMPL_1;
|
|
|
|
tstamp->regh = IGC_TXSTMPH_1;
|
|
|
|
tstamp->flags = IGC_TX_FLAGS_TSTAMP_1;
|
|
|
|
|
|
|
|
tstamp = &adapter->tx_tstamp[2];
|
|
|
|
tstamp->mask = IGC_TSYNCTXCTL_TXTT_2;
|
|
|
|
tstamp->regl = IGC_TXSTMPL_2;
|
|
|
|
tstamp->regh = IGC_TXSTMPH_2;
|
|
|
|
tstamp->flags = IGC_TX_FLAGS_TSTAMP_2;
|
|
|
|
|
|
|
|
tstamp = &adapter->tx_tstamp[3];
|
|
|
|
tstamp->mask = IGC_TSYNCTXCTL_TXTT_3;
|
|
|
|
tstamp->regl = IGC_TXSTMPL_3;
|
|
|
|
tstamp->regh = IGC_TXSTMPH_3;
|
|
|
|
tstamp->flags = IGC_TX_FLAGS_TSTAMP_3;
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
switch (hw->mac.type) {
|
|
|
|
case igc_i225:
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
for (i = 0; i < IGC_N_SDP; i++) {
|
|
|
|
struct ptp_pin_desc *ppd = &adapter->sdp_config[i];
|
|
|
|
|
|
|
|
snprintf(ppd->name, sizeof(ppd->name), "SDP%d", i);
|
|
|
|
ppd->index = i;
|
|
|
|
ppd->func = PTP_PF_NONE;
|
|
|
|
}
|
2019-12-02 15:19:49 -08:00
|
|
|
snprintf(adapter->ptp_caps.name, 16, "%pm", netdev->dev_addr);
|
|
|
|
adapter->ptp_caps.owner = THIS_MODULE;
|
|
|
|
adapter->ptp_caps.max_adj = 62499999;
|
|
|
|
adapter->ptp_caps.adjfine = igc_ptp_adjfine_i225;
|
|
|
|
adapter->ptp_caps.adjtime = igc_ptp_adjtime_i225;
|
|
|
|
adapter->ptp_caps.gettimex64 = igc_ptp_gettimex64_i225;
|
2023-09-21 18:40:49 -07:00
|
|
|
adapter->ptp_caps.getcyclesx64 = igc_ptp_getcyclesx64;
|
2019-12-02 15:19:49 -08:00
|
|
|
adapter->ptp_caps.settime64 = igc_ptp_settime_i225;
|
|
|
|
adapter->ptp_caps.enable = igc_ptp_feature_enable_i225;
|
2021-02-18 17:31:03 -08:00
|
|
|
adapter->ptp_caps.pps = 1;
|
igc: enable auxiliary PHC functions for the i225
The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.
The assignment of PHC functions to the four SDP can be freely chosen by
the user.
For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.
For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-02-18 17:31:04 -08:00
|
|
|
adapter->ptp_caps.pin_config = adapter->sdp_config;
|
|
|
|
adapter->ptp_caps.n_ext_ts = IGC_N_EXTTS;
|
|
|
|
adapter->ptp_caps.n_per_out = IGC_N_PEROUT;
|
|
|
|
adapter->ptp_caps.n_pins = IGC_N_SDP;
|
|
|
|
adapter->ptp_caps.verify = igc_ptp_verify_pin;
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
|
|
|
|
if (!igc_is_crosststamp_supported(adapter))
|
|
|
|
break;
|
|
|
|
|
|
|
|
adapter->ptp_caps.getcrosststamp = igc_ptp_getcrosststamp;
|
2019-12-02 15:19:49 -08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
adapter->ptp_clock = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
igc: Fix race condition in PTP tx code
Currently, the igc driver supports timestamping only one tx packet at a
time. During the transmission flow, the skb that requires hardware
timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
adapter->ptp_tx_skb, and notify the network stack.
While the thread executing the transmission flow (the user process
running in kernel mode) and the thread executing ptp_tx_work don't
access adapter->ptp_tx_skb concurrently, there are two other places
where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
igc_ptp_suspend().
igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
thread which runs periodically so it is possible we have two threads
accessing ptp_tx_skb at the same time. Consider the following scenario:
right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
written yet, this is considered a timeout and adapter->ptp_tx_skb is
cleaned up.
This patch fixes the issue described above by adding the ptp_tx_lock to
protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
Since igc_xmit_frame_ring() called in atomic context by the networking
stack, ptp_tx_lock is defined as a spinlock, and the irq safe variants
of lock/unlock are used.
With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
flag doesn't provide much of a use anymore so this patch gets rid of it.
Fixes: 2c344ae24501 ("igc: Add support for TX timestamping")
Signed-off-by: Andre Guedes <andre.guedes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-07 14:32:29 -07:00
|
|
|
spin_lock_init(&adapter->ptp_tx_lock);
|
2023-09-21 18:40:49 -07:00
|
|
|
spin_lock_init(&adapter->free_timer_lock);
|
2019-12-02 15:19:49 -08:00
|
|
|
spin_lock_init(&adapter->tmreg_lock);
|
|
|
|
|
|
|
|
adapter->tstamp_config.rx_filter = HWTSTAMP_FILTER_NONE;
|
|
|
|
adapter->tstamp_config.tx_type = HWTSTAMP_TX_OFF;
|
|
|
|
|
2020-08-20 16:02:17 -07:00
|
|
|
adapter->prev_ptp_time = ktime_to_timespec64(ktime_get_real());
|
|
|
|
adapter->ptp_reset_start = ktime_get();
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
adapter->ptp_clock = ptp_clock_register(&adapter->ptp_caps,
|
|
|
|
&adapter->pdev->dev);
|
|
|
|
if (IS_ERR(adapter->ptp_clock)) {
|
|
|
|
adapter->ptp_clock = NULL;
|
2020-03-24 17:38:17 -07:00
|
|
|
netdev_err(netdev, "ptp_clock_register failed\n");
|
2019-12-02 15:19:49 -08:00
|
|
|
} else if (adapter->ptp_clock) {
|
2020-03-24 17:38:17 -07:00
|
|
|
netdev_info(netdev, "PHC added\n");
|
2019-12-02 15:19:49 -08:00
|
|
|
adapter->ptp_flags |= IGC_PTP_ENABLED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-20 16:02:17 -07:00
|
|
|
static void igc_ptp_time_save(struct igc_adapter *adapter)
|
|
|
|
{
|
2020-09-02 16:36:56 -07:00
|
|
|
igc_ptp_read(adapter, &adapter->prev_ptp_time);
|
2020-08-20 16:02:17 -07:00
|
|
|
adapter->ptp_reset_start = ktime_get();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void igc_ptp_time_restore(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct timespec64 ts = adapter->prev_ptp_time;
|
|
|
|
ktime_t delta;
|
|
|
|
|
|
|
|
delta = ktime_sub(ktime_get(), adapter->ptp_reset_start);
|
|
|
|
|
|
|
|
timespec64_add_ns(&ts, ktime_to_ns(delta));
|
|
|
|
|
|
|
|
igc_ptp_write_i225(adapter, &ts);
|
|
|
|
}
|
|
|
|
|
2022-04-12 18:58:15 -07:00
|
|
|
static void igc_ptm_stop(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
|
|
|
u32 ctrl;
|
|
|
|
|
|
|
|
ctrl = rd32(IGC_PTM_CTRL);
|
|
|
|
ctrl &= ~IGC_PTM_CTRL_EN;
|
|
|
|
|
|
|
|
wr32(IGC_PTM_CTRL, ctrl);
|
|
|
|
}
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
/**
|
|
|
|
* igc_ptp_suspend - Disable PTP work items and prepare for suspend
|
|
|
|
* @adapter: Board private structure
|
|
|
|
*
|
|
|
|
* This function stops the overflow check work and PTP Tx timestamp work, and
|
|
|
|
* will prepare the device for OS suspend.
|
|
|
|
*/
|
2020-01-22 11:21:13 +02:00
|
|
|
void igc_ptp_suspend(struct igc_adapter *adapter)
|
2019-12-02 15:19:49 -08:00
|
|
|
{
|
|
|
|
if (!(adapter->ptp_flags & IGC_PTP_ENABLED))
|
|
|
|
return;
|
|
|
|
|
2023-06-07 14:32:30 -07:00
|
|
|
igc_ptp_clear_tx_tstamp(adapter);
|
2020-08-20 16:02:17 -07:00
|
|
|
|
2022-04-12 18:58:15 -07:00
|
|
|
if (pci_device_is_present(adapter->pdev)) {
|
2021-07-13 21:00:36 +08:00
|
|
|
igc_ptp_time_save(adapter);
|
2022-04-12 18:58:15 -07:00
|
|
|
igc_ptm_stop(adapter);
|
|
|
|
}
|
2019-12-02 15:19:49 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* igc_ptp_stop - Disable PTP device and stop the overflow check.
|
|
|
|
* @adapter: Board private structure.
|
|
|
|
*
|
|
|
|
* This function stops the PTP support and cancels the delayed work.
|
|
|
|
**/
|
|
|
|
void igc_ptp_stop(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
igc_ptp_suspend(adapter);
|
|
|
|
|
|
|
|
if (adapter->ptp_clock) {
|
|
|
|
ptp_clock_unregister(adapter->ptp_clock);
|
2020-03-24 17:38:17 -07:00
|
|
|
netdev_info(adapter->netdev, "PHC removed\n");
|
2019-12-02 15:19:49 -08:00
|
|
|
adapter->ptp_flags &= ~IGC_PTP_ENABLED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* igc_ptp_reset - Re-enable the adapter for PTP following a reset.
|
|
|
|
* @adapter: Board private structure.
|
|
|
|
*
|
|
|
|
* This function handles the reset work required to re-enable the PTP device.
|
|
|
|
**/
|
|
|
|
void igc_ptp_reset(struct igc_adapter *adapter)
|
|
|
|
{
|
|
|
|
struct igc_hw *hw = &adapter->hw;
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
u32 cycle_ctrl, ctrl;
|
2019-12-02 15:19:49 -08:00
|
|
|
unsigned long flags;
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
u32 timadj;
|
2019-12-02 15:19:49 -08:00
|
|
|
|
|
|
|
/* reset the tstamp_config */
|
|
|
|
igc_ptp_set_timestamp_mode(adapter, &adapter->tstamp_config);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&adapter->tmreg_lock, flags);
|
|
|
|
|
|
|
|
switch (adapter->hw.mac.type) {
|
|
|
|
case igc_i225:
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
timadj = rd32(IGC_TIMADJ);
|
|
|
|
timadj |= IGC_TIMADJ_ADJUST_METH;
|
|
|
|
wr32(IGC_TIMADJ, timadj);
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
wr32(IGC_TSAUXC, 0x0);
|
|
|
|
wr32(IGC_TSSDP, 0x0);
|
2021-02-18 17:31:03 -08:00
|
|
|
wr32(IGC_TSIM,
|
|
|
|
IGC_TSICR_INTERRUPTS |
|
|
|
|
(adapter->pps_sys_wrap_on ? IGC_TSICR_SYS_WRAP : 0));
|
2019-12-02 15:19:49 -08:00
|
|
|
wr32(IGC_IMS, IGC_IMS_TS);
|
igc: Add support for PTP getcrosststamp()
i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.
The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.
i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.
PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():
phc2sys[191.382]: enp4s0 sys offset -959 s2 freq -454 delay 4492
phc2sys[191.482]: enp4s0 sys offset 798 s2 freq +1015 delay 4069
phc2sys[191.583]: enp4s0 sys offset 962 s2 freq +1418 delay 3849
phc2sys[191.683]: enp4s0 sys offset 924 s2 freq +1669 delay 3753
phc2sys[191.783]: enp4s0 sys offset 664 s2 freq +1686 delay 3349
phc2sys[191.883]: enp4s0 sys offset 218 s2 freq +1439 delay 2585
phc2sys[191.983]: enp4s0 sys offset 761 s2 freq +2048 delay 3750
phc2sys[192.083]: enp4s0 sys offset 756 s2 freq +2271 delay 4061
phc2sys[192.183]: enp4s0 sys offset 809 s2 freq +2551 delay 4384
phc2sys[192.283]: enp4s0 sys offset -108 s2 freq +1877 delay 2480
phc2sys[192.383]: enp4s0 sys offset -1145 s2 freq +807 delay 4438
phc2sys[192.484]: enp4s0 sys offset 571 s2 freq +2180 delay 3849
phc2sys[192.584]: enp4s0 sys offset 241 s2 freq +2021 delay 3389
phc2sys[192.684]: enp4s0 sys offset 405 s2 freq +2257 delay 3829
phc2sys[192.784]: enp4s0 sys offset 17 s2 freq +1991 delay 3273
phc2sys[192.884]: enp4s0 sys offset 152 s2 freq +2131 delay 3948
phc2sys[192.984]: enp4s0 sys offset -187 s2 freq +1837 delay 3162
phc2sys[193.084]: enp4s0 sys offset -1595 s2 freq +373 delay 4557
phc2sys[193.184]: enp4s0 sys offset 107 s2 freq +1597 delay 3740
phc2sys[193.284]: enp4s0 sys offset 199 s2 freq +1721 delay 4010
phc2sys[193.385]: enp4s0 sys offset -169 s2 freq +1413 delay 3701
phc2sys[193.485]: enp4s0 sys offset -47 s2 freq +1484 delay 3581
phc2sys[193.585]: enp4s0 sys offset -65 s2 freq +1452 delay 3778
phc2sys[193.685]: enp4s0 sys offset 95 s2 freq +1592 delay 3888
phc2sys[193.785]: enp4s0 sys offset 206 s2 freq +1732 delay 4445
phc2sys[193.885]: enp4s0 sys offset -652 s2 freq +936 delay 2521
phc2sys[193.985]: enp4s0 sys offset -203 s2 freq +1189 delay 3391
phc2sys[194.085]: enp4s0 sys offset -376 s2 freq +955 delay 2951
phc2sys[194.185]: enp4s0 sys offset -134 s2 freq +1084 delay 3330
phc2sys[194.285]: enp4s0 sys offset -22 s2 freq +1156 delay 3479
phc2sys[194.386]: enp4s0 sys offset 32 s2 freq +1204 delay 3602
phc2sys[194.486]: enp4s0 sys offset 122 s2 freq +1303 delay 3731
Statistics for this run (total of 2179 lines), in nanoseconds:
average: -1.12
stdev: 634.80
max: 1551
min: -2215
With .getcrosststamp() via PCIe PTM:
phc2sys[367.859]: enp4s0 sys offset 6 s2 freq +1727 delay 0
phc2sys[367.959]: enp4s0 sys offset -2 s2 freq +1721 delay 0
phc2sys[368.059]: enp4s0 sys offset 5 s2 freq +1727 delay 0
phc2sys[368.160]: enp4s0 sys offset -1 s2 freq +1723 delay 0
phc2sys[368.260]: enp4s0 sys offset -4 s2 freq +1719 delay 0
phc2sys[368.360]: enp4s0 sys offset -5 s2 freq +1717 delay 0
phc2sys[368.460]: enp4s0 sys offset 1 s2 freq +1722 delay 0
phc2sys[368.560]: enp4s0 sys offset -3 s2 freq +1718 delay 0
phc2sys[368.660]: enp4s0 sys offset 5 s2 freq +1725 delay 0
phc2sys[368.760]: enp4s0 sys offset -1 s2 freq +1721 delay 0
phc2sys[368.860]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[368.960]: enp4s0 sys offset 0 s2 freq +1721 delay 0
phc2sys[369.061]: enp4s0 sys offset 4 s2 freq +1725 delay 0
phc2sys[369.161]: enp4s0 sys offset 1 s2 freq +1724 delay 0
phc2sys[369.261]: enp4s0 sys offset 4 s2 freq +1727 delay 0
phc2sys[369.361]: enp4s0 sys offset 8 s2 freq +1732 delay 0
phc2sys[369.461]: enp4s0 sys offset 7 s2 freq +1733 delay 0
phc2sys[369.561]: enp4s0 sys offset 4 s2 freq +1733 delay 0
phc2sys[369.661]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.761]: enp4s0 sys offset 1 s2 freq +1731 delay 0
phc2sys[369.861]: enp4s0 sys offset -5 s2 freq +1725 delay 0
phc2sys[369.961]: enp4s0 sys offset -4 s2 freq +1725 delay 0
phc2sys[370.062]: enp4s0 sys offset 2 s2 freq +1730 delay 0
phc2sys[370.162]: enp4s0 sys offset -7 s2 freq +1721 delay 0
phc2sys[370.262]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.362]: enp4s0 sys offset 1 s2 freq +1726 delay 0
phc2sys[370.462]: enp4s0 sys offset -3 s2 freq +1723 delay 0
phc2sys[370.562]: enp4s0 sys offset -1 s2 freq +1724 delay 0
phc2sys[370.662]: enp4s0 sys offset -4 s2 freq +1720 delay 0
phc2sys[370.762]: enp4s0 sys offset -7 s2 freq +1716 delay 0
phc2sys[370.862]: enp4s0 sys offset -2 s2 freq +1719 delay 0
Statistics for this run (total of 2179 lines), in nanoseconds:
average: 0.14
stdev: 5.03
max: 48
min: -27
For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
without PTM: avg -0.04 stdev 10.57 max 39 min -42
with PTM: avg 0.01 stdev 4.20 max 19 min -16
One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.
When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.
This was implemented following the i225 EAS version 0.993.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-07-26 20:36:57 -07:00
|
|
|
|
|
|
|
if (!igc_is_crosststamp_supported(adapter))
|
|
|
|
break;
|
|
|
|
|
|
|
|
wr32(IGC_PCIE_DIG_DELAY, IGC_PCIE_DIG_DELAY_DEFAULT);
|
|
|
|
wr32(IGC_PCIE_PHY_DELAY, IGC_PCIE_PHY_DELAY_DEFAULT);
|
|
|
|
|
|
|
|
cycle_ctrl = IGC_PTM_CYCLE_CTRL_CYC_TIME(IGC_PTM_CYC_TIME_DEFAULT);
|
|
|
|
|
|
|
|
wr32(IGC_PTM_CYCLE_CTRL, cycle_ctrl);
|
|
|
|
|
|
|
|
ctrl = IGC_PTM_CTRL_EN |
|
|
|
|
IGC_PTM_CTRL_START_NOW |
|
|
|
|
IGC_PTM_CTRL_SHRT_CYC(IGC_PTM_SHORT_CYC_DEFAULT) |
|
|
|
|
IGC_PTM_CTRL_PTM_TO(IGC_PTM_TIMEOUT_DEFAULT) |
|
|
|
|
IGC_PTM_CTRL_TRIG;
|
|
|
|
|
|
|
|
wr32(IGC_PTM_CTRL, ctrl);
|
|
|
|
|
|
|
|
/* Force the first cycle to run. */
|
|
|
|
wr32(IGC_PTM_STAT, IGC_PTM_STAT_VALID);
|
|
|
|
|
2019-12-02 15:19:49 -08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* No work to do. */
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Re-initialize the timer. */
|
|
|
|
if (hw->mac.type == igc_i225) {
|
2020-08-20 16:02:17 -07:00
|
|
|
igc_ptp_time_restore(adapter);
|
2019-12-02 15:19:49 -08:00
|
|
|
} else {
|
|
|
|
timecounter_init(&adapter->tc, &adapter->cc,
|
|
|
|
ktime_to_ns(ktime_get_real()));
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
spin_unlock_irqrestore(&adapter->tmreg_lock, flags);
|
|
|
|
|
|
|
|
wrfl();
|
|
|
|
}
|