2021-06-09 09:39:50 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/* Copyright (C) 2021, Intel Corporation. */
|
|
|
|
|
|
|
|
#include "ice.h"
|
|
|
|
#include "ice_lib.h"
|
ice: add trace events for tx timestamps
We've previously run into many issues related to the latency of a Tx
timestamp completion with the ice hardware. It can be difficult to
determine the root cause of a slow Tx timestamp. To aid in this,
introduce new trace events which capture timing data about when the
driver reaches certain points while processing a transmit timestamp
* ice_tx_tstamp_request: Trace when the stack initiates a new timestamp
request.
* ice_tx_tstamp_fw_req: Trace when the driver begins a read of the
timestamp register in the work thread.
* ice_tx_tstamp_fw_done: Trace when the driver finishes reading a
timestamp register in the work thread.
* ice_tx_tstamp_complete: Trace when the driver submits the skb back to
the stack with a completed Tx timestamp.
These trace events can be enabled using the standard trace event
subsystem exposed by the ice driver. If they are disabled, they become
no-ops with no run time cost.
The following is a simple GNU AWK script which can highlight one
potential way to use the trace events to capture latency data from the
trace buffer about how long the driver takes to process a timestamp:
-----
BEGIN {
PREC=256
}
# Detect requests
/tx_tstamp_request/ {
time=strtonum($4)
skb=$7
# Store the time of request for this skb
requests[skb] = time
printf("skb %s: idx %d at %.6f\n", skb, idx, time)
}
# Detect completions
/tx_tstamp_complete/ {
time=strtonum($4)
skb=$7
idx=$9
if (skb in requests) {
latency = (time - requests[skb]) * 1000
printf("skb %s: %.3f to complete\n", skb, latency)
if (latency > 4) {
printf(">>> HIGH LATENCY <<<\n")
}
printf("\n")
} else {
printf("!!! skb %s (idx %d) at %.6f\n", skb, idx, time)
}
}
-----
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-01 15:02:28 -08:00
|
|
|
#include "ice_trace.h"
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
#define E810_OUT_PROP_DELAY_NS 1
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
#define UNKNOWN_INCVAL_E822 0x100000000ULL
|
|
|
|
|
2021-08-17 13:09:18 +02:00
|
|
|
static const struct ptp_pin_desc ice_pin_desc_e810t[] = {
|
|
|
|
/* name idx func chan */
|
|
|
|
{ "GNSS", GNSS, PTP_PF_EXTTS, 0, { 0, } },
|
|
|
|
{ "SMA1", SMA1, PTP_PF_NONE, 1, { 0, } },
|
|
|
|
{ "U.FL1", UFL1, PTP_PF_NONE, 1, { 0, } },
|
|
|
|
{ "SMA2", SMA2, PTP_PF_NONE, 2, { 0, } },
|
|
|
|
{ "U.FL2", UFL2, PTP_PF_NONE, 2, { 0, } },
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_get_sma_config_e810t
|
|
|
|
* @hw: pointer to the hw struct
|
|
|
|
* @ptp_pins: pointer to the ptp_pin_desc struture
|
|
|
|
*
|
|
|
|
* Read the configuration of the SMA control logic and put it into the
|
|
|
|
* ptp_pin_desc structure
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_get_sma_config_e810t(struct ice_hw *hw, struct ptp_pin_desc *ptp_pins)
|
|
|
|
{
|
|
|
|
u8 data, i;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
/* Read initial pin state */
|
|
|
|
status = ice_read_sma_ctrl_e810t(hw, &data);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/* initialize with defaults */
|
|
|
|
for (i = 0; i < NUM_PTP_PINS_E810T; i++) {
|
|
|
|
snprintf(ptp_pins[i].name, sizeof(ptp_pins[i].name),
|
|
|
|
"%s", ice_pin_desc_e810t[i].name);
|
|
|
|
ptp_pins[i].index = ice_pin_desc_e810t[i].index;
|
|
|
|
ptp_pins[i].func = ice_pin_desc_e810t[i].func;
|
|
|
|
ptp_pins[i].chan = ice_pin_desc_e810t[i].chan;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse SMA1/UFL1 */
|
|
|
|
switch (data & ICE_SMA1_MASK_E810T) {
|
|
|
|
case ICE_SMA1_MASK_E810T:
|
|
|
|
default:
|
|
|
|
ptp_pins[SMA1].func = PTP_PF_NONE;
|
|
|
|
ptp_pins[UFL1].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case ICE_SMA1_DIR_EN_E810T:
|
|
|
|
ptp_pins[SMA1].func = PTP_PF_PEROUT;
|
|
|
|
ptp_pins[UFL1].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case ICE_SMA1_TX_EN_E810T:
|
|
|
|
ptp_pins[SMA1].func = PTP_PF_EXTTS;
|
|
|
|
ptp_pins[UFL1].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
ptp_pins[SMA1].func = PTP_PF_EXTTS;
|
|
|
|
ptp_pins[UFL1].func = PTP_PF_PEROUT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse SMA2/UFL2 */
|
|
|
|
switch (data & ICE_SMA2_MASK_E810T) {
|
|
|
|
case ICE_SMA2_MASK_E810T:
|
|
|
|
default:
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_NONE;
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case (ICE_SMA2_TX_EN_E810T | ICE_SMA2_UFL2_RX_DIS_E810T):
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_EXTTS;
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case (ICE_SMA2_DIR_EN_E810T | ICE_SMA2_UFL2_RX_DIS_E810T):
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_PEROUT;
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_NONE;
|
|
|
|
break;
|
|
|
|
case (ICE_SMA2_DIR_EN_E810T | ICE_SMA2_TX_EN_E810T):
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_NONE;
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_EXTTS;
|
|
|
|
break;
|
|
|
|
case ICE_SMA2_DIR_EN_E810T:
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_PEROUT;
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_EXTTS;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_set_sma_config_e810t
|
|
|
|
* @hw: pointer to the hw struct
|
|
|
|
* @ptp_pins: pointer to the ptp_pin_desc struture
|
|
|
|
*
|
|
|
|
* Set the configuration of the SMA control logic based on the configuration in
|
|
|
|
* num_pins parameter
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_set_sma_config_e810t(struct ice_hw *hw,
|
|
|
|
const struct ptp_pin_desc *ptp_pins)
|
|
|
|
{
|
|
|
|
int status;
|
|
|
|
u8 data;
|
|
|
|
|
|
|
|
/* SMA1 and UFL1 cannot be set to TX at the same time */
|
|
|
|
if (ptp_pins[SMA1].func == PTP_PF_PEROUT &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_PEROUT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* SMA2 and UFL2 cannot be set to RX at the same time */
|
|
|
|
if (ptp_pins[SMA2].func == PTP_PF_EXTTS &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_EXTTS)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Read initial pin state value */
|
|
|
|
status = ice_read_sma_ctrl_e810t(hw, &data);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/* Set the right sate based on the desired configuration */
|
|
|
|
data &= ~ICE_SMA1_MASK_E810T;
|
|
|
|
if (ptp_pins[SMA1].func == PTP_PF_NONE &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA1 + U.FL1 disabled");
|
|
|
|
data |= ICE_SMA1_MASK_E810T;
|
|
|
|
} else if (ptp_pins[SMA1].func == PTP_PF_EXTTS &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA1 RX");
|
|
|
|
data |= ICE_SMA1_TX_EN_E810T;
|
|
|
|
} else if (ptp_pins[SMA1].func == PTP_PF_NONE &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_PEROUT) {
|
|
|
|
/* U.FL 1 TX will always enable SMA 1 RX */
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA1 RX + U.FL1 TX");
|
|
|
|
} else if (ptp_pins[SMA1].func == PTP_PF_EXTTS &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_PEROUT) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA1 RX + U.FL1 TX");
|
|
|
|
} else if (ptp_pins[SMA1].func == PTP_PF_PEROUT &&
|
|
|
|
ptp_pins[UFL1].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA1 TX");
|
|
|
|
data |= ICE_SMA1_DIR_EN_E810T;
|
|
|
|
}
|
|
|
|
|
|
|
|
data &= ~ICE_SMA2_MASK_E810T;
|
|
|
|
if (ptp_pins[SMA2].func == PTP_PF_NONE &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA2 + U.FL2 disabled");
|
|
|
|
data |= ICE_SMA2_MASK_E810T;
|
|
|
|
} else if (ptp_pins[SMA2].func == PTP_PF_EXTTS &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA2 RX");
|
|
|
|
data |= (ICE_SMA2_TX_EN_E810T |
|
|
|
|
ICE_SMA2_UFL2_RX_DIS_E810T);
|
|
|
|
} else if (ptp_pins[SMA2].func == PTP_PF_NONE &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_EXTTS) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "UFL2 RX");
|
|
|
|
data |= (ICE_SMA2_DIR_EN_E810T | ICE_SMA2_TX_EN_E810T);
|
|
|
|
} else if (ptp_pins[SMA2].func == PTP_PF_PEROUT &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_NONE) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA2 TX");
|
|
|
|
data |= (ICE_SMA2_DIR_EN_E810T |
|
|
|
|
ICE_SMA2_UFL2_RX_DIS_E810T);
|
|
|
|
} else if (ptp_pins[SMA2].func == PTP_PF_PEROUT &&
|
|
|
|
ptp_pins[UFL2].func == PTP_PF_EXTTS) {
|
|
|
|
dev_info(ice_hw_to_dev(hw), "SMA2 TX + U.FL2 RX");
|
|
|
|
data |= ICE_SMA2_DIR_EN_E810T;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ice_write_sma_ctrl_e810t(hw, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_set_sma_e810t
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @pin: pin index in kernel structure
|
|
|
|
* @func: Pin function to be set (PTP_PF_NONE, PTP_PF_EXTTS or PTP_PF_PEROUT)
|
|
|
|
*
|
|
|
|
* Set the configuration of a single SMA pin
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_set_sma_e810t(struct ptp_clock_info *info, unsigned int pin,
|
|
|
|
enum ptp_pin_function func)
|
|
|
|
{
|
|
|
|
struct ptp_pin_desc ptp_pins[NUM_PTP_PINS_E810T];
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (pin < SMA1 || func > PTP_PF_PEROUT)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
err = ice_get_sma_config_e810t(hw, ptp_pins);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Disable the same function on the other pin sharing the channel */
|
|
|
|
if (pin == SMA1 && ptp_pins[UFL1].func == func)
|
|
|
|
ptp_pins[UFL1].func = PTP_PF_NONE;
|
|
|
|
if (pin == UFL1 && ptp_pins[SMA1].func == func)
|
|
|
|
ptp_pins[SMA1].func = PTP_PF_NONE;
|
|
|
|
|
|
|
|
if (pin == SMA2 && ptp_pins[UFL2].func == func)
|
|
|
|
ptp_pins[UFL2].func = PTP_PF_NONE;
|
|
|
|
if (pin == UFL2 && ptp_pins[SMA2].func == func)
|
|
|
|
ptp_pins[SMA2].func = PTP_PF_NONE;
|
|
|
|
|
|
|
|
/* Set up new pin function in the temp table */
|
|
|
|
ptp_pins[pin].func = func;
|
|
|
|
|
|
|
|
return ice_ptp_set_sma_config_e810t(hw, ptp_pins);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_verify_pin_e810t
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @pin: Pin index
|
|
|
|
* @func: Assigned function
|
|
|
|
* @chan: Assigned channel
|
|
|
|
*
|
|
|
|
* Verify if pin supports requested pin function. If the Check pins consistency.
|
|
|
|
* Reconfigure the SMA logic attached to the given pin to enable its
|
|
|
|
* desired functionality
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_verify_pin_e810t(struct ptp_clock_info *info, unsigned int pin,
|
|
|
|
enum ptp_pin_function func, unsigned int chan)
|
|
|
|
{
|
|
|
|
/* Don't allow channel reassignment */
|
|
|
|
if (chan != ice_pin_desc_e810t[pin].chan)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
/* Check if functions are properly assigned */
|
|
|
|
switch (func) {
|
|
|
|
case PTP_PF_NONE:
|
|
|
|
break;
|
|
|
|
case PTP_PF_EXTTS:
|
|
|
|
if (pin == UFL1)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
break;
|
|
|
|
case PTP_PF_PEROUT:
|
|
|
|
if (pin == UFL2 || pin == GNSS)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
break;
|
|
|
|
case PTP_PF_PHYSYNC:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ice_ptp_set_sma_e810t(info, pin, func);
|
|
|
|
}
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_configure_tx_tstamp - Enable or disable Tx timestamp interrupt
|
|
|
|
* @pf: The PF pointer to search in
|
|
|
|
* @on: bool value for whether timestamp interrupt is enabled or disabled
|
|
|
|
*/
|
|
|
|
static void ice_ptp_configure_tx_tstamp(struct ice_pf *pf, bool on)
|
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
/* Configure the Tx timestamp interrupt */
|
|
|
|
val = rd32(&pf->hw, PFINT_OICR_ENA);
|
|
|
|
if (on)
|
|
|
|
val |= PFINT_OICR_TSYN_TX_M;
|
|
|
|
else
|
|
|
|
val &= ~PFINT_OICR_TSYN_TX_M;
|
|
|
|
wr32(&pf->hw, PFINT_OICR_ENA, val);
|
|
|
|
}
|
|
|
|
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
/**
|
|
|
|
* ice_set_tx_tstamp - Enable or disable Tx timestamping
|
|
|
|
* @pf: The PF pointer to search in
|
|
|
|
* @on: bool value for whether timestamps are enabled or disabled
|
|
|
|
*/
|
|
|
|
static void ice_set_tx_tstamp(struct ice_pf *pf, bool on)
|
|
|
|
{
|
|
|
|
struct ice_vsi *vsi;
|
|
|
|
u16 i;
|
|
|
|
|
|
|
|
vsi = ice_get_main_vsi(pf);
|
|
|
|
if (!vsi)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Set the timestamp enable flag for all the Tx rings */
|
2021-08-23 17:01:46 -07:00
|
|
|
ice_for_each_txq(vsi, i) {
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
if (!vsi->tx_rings[i])
|
|
|
|
continue;
|
|
|
|
vsi->tx_rings[i]->ptp_tx = on;
|
|
|
|
}
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
if (pf->ptp.tx_interrupt_mode == ICE_PTP_TX_INTERRUPT_SELF)
|
|
|
|
ice_ptp_configure_tx_tstamp(pf, on);
|
2021-10-13 08:48:13 -07:00
|
|
|
|
|
|
|
pf->ptp.tstamp_config.tx_type = on ? HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
}
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/**
|
|
|
|
* ice_set_rx_tstamp - Enable or disable Rx timestamping
|
|
|
|
* @pf: The PF pointer to search in
|
|
|
|
* @on: bool value for whether timestamps are enabled or disabled
|
|
|
|
*/
|
|
|
|
static void ice_set_rx_tstamp(struct ice_pf *pf, bool on)
|
|
|
|
{
|
|
|
|
struct ice_vsi *vsi;
|
|
|
|
u16 i;
|
|
|
|
|
|
|
|
vsi = ice_get_main_vsi(pf);
|
|
|
|
if (!vsi)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Set the timestamp flag for all the Rx rings */
|
|
|
|
ice_for_each_rxq(vsi, i) {
|
|
|
|
if (!vsi->rx_rings[i])
|
|
|
|
continue;
|
|
|
|
vsi->rx_rings[i]->ptp_rx = on;
|
|
|
|
}
|
2021-10-13 08:48:13 -07:00
|
|
|
|
|
|
|
pf->ptp.tstamp_config.rx_filter = on ? HWTSTAMP_FILTER_ALL :
|
|
|
|
HWTSTAMP_FILTER_NONE;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_cfg_timestamp - Configure timestamp for init/deinit
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ena: bool value to enable or disable time stamp
|
|
|
|
*
|
|
|
|
* This function will configure timestamping during PTP initialization
|
|
|
|
* and deinitialization
|
|
|
|
*/
|
2021-12-20 08:58:27 -08:00
|
|
|
void ice_ptp_cfg_timestamp(struct ice_pf *pf, bool ena)
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
{
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
ice_set_tx_tstamp(pf, ena);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
ice_set_rx_tstamp(pf, ena);
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:51 -07:00
|
|
|
/**
|
|
|
|
* ice_get_ptp_clock_index - Get the PTP clock index
|
|
|
|
* @pf: the PF pointer
|
|
|
|
*
|
|
|
|
* Determine the clock index of the PTP clock associated with this device. If
|
|
|
|
* this is the PF controlling the clock, just use the local access to the
|
|
|
|
* clock device pointer.
|
|
|
|
*
|
|
|
|
* Otherwise, read from the driver shared parameters to determine the clock
|
|
|
|
* index value.
|
|
|
|
*
|
|
|
|
* Returns: the index of the PTP clock associated with this device, or -1 if
|
|
|
|
* there is no associated clock.
|
|
|
|
*/
|
|
|
|
int ice_get_ptp_clock_index(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
enum ice_aqc_driver_params param_idx;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 tmr_idx;
|
|
|
|
u32 value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Use the ptp_clock structure if we're the main PF */
|
|
|
|
if (pf->ptp.clock)
|
|
|
|
return ptp_clock_index(pf->ptp.clock);
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_assoc;
|
|
|
|
if (!tmr_idx)
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR0;
|
|
|
|
else
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR1;
|
|
|
|
|
|
|
|
err = ice_aq_get_driver_param(hw, param_idx, &value, NULL);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to read PTP clock index parameter, err %d aq_err %s\n",
|
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The PTP clock index is an integer, and will be between 0 and
|
|
|
|
* INT_MAX. The highest bit of the driver shared parameter is used to
|
|
|
|
* indicate whether or not the currently stored clock index is valid.
|
|
|
|
*/
|
|
|
|
if (!(value & PTP_SHARED_CLK_IDX_VALID))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return value & ~PTP_SHARED_CLK_IDX_VALID;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_set_ptp_clock_index - Set the PTP clock index
|
|
|
|
* @pf: the PF pointer
|
|
|
|
*
|
|
|
|
* Set the PTP clock index for this device into the shared driver parameters,
|
|
|
|
* so that other PFs associated with this device can read it.
|
|
|
|
*
|
|
|
|
* If the PF is unable to store the clock index, it will log an error, but
|
|
|
|
* will continue operating PTP.
|
|
|
|
*/
|
|
|
|
static void ice_set_ptp_clock_index(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
enum ice_aqc_driver_params param_idx;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 tmr_idx;
|
|
|
|
u32 value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!pf->ptp.clock)
|
|
|
|
return;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_assoc;
|
|
|
|
if (!tmr_idx)
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR0;
|
|
|
|
else
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR1;
|
|
|
|
|
|
|
|
value = (u32)ptp_clock_index(pf->ptp.clock);
|
|
|
|
if (value > INT_MAX) {
|
|
|
|
dev_err(dev, "PTP Clock index is too large to store\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
value |= PTP_SHARED_CLK_IDX_VALID;
|
|
|
|
|
|
|
|
err = ice_aq_set_driver_param(hw, param_idx, value, NULL);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to set PTP clock index parameter, err %d aq_err %s\n",
|
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_clear_ptp_clock_index - Clear the PTP clock index
|
|
|
|
* @pf: the PF pointer
|
|
|
|
*
|
|
|
|
* Clear the PTP clock index for this device. Must be called when
|
|
|
|
* unregistering the PTP clock, in order to ensure other PFs stop reporting
|
|
|
|
* a clock object that no longer exists.
|
|
|
|
*/
|
|
|
|
static void ice_clear_ptp_clock_index(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
enum ice_aqc_driver_params param_idx;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 tmr_idx;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Do not clear the index if we don't own the timer */
|
2023-09-08 14:37:14 -07:00
|
|
|
if (!ice_pf_src_tmr_owned(pf))
|
2021-06-09 09:39:51 -07:00
|
|
|
return;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_assoc;
|
|
|
|
if (!tmr_idx)
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR0;
|
|
|
|
else
|
|
|
|
param_idx = ICE_AQC_DRIVER_PARAM_CLK_IDX_TMR1;
|
|
|
|
|
|
|
|
err = ice_aq_set_driver_param(hw, param_idx, 0, NULL);
|
|
|
|
if (err) {
|
|
|
|
dev_dbg(dev, "Failed to clear PTP clock index parameter, err %d aq_err %s\n",
|
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_read_src_clk_reg - Read the source clock register
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @sts: Optional parameter for holding a pair of system timestamps from
|
|
|
|
* the system clock. Will be ignored if NULL is given.
|
|
|
|
*/
|
|
|
|
static u64
|
|
|
|
ice_ptp_read_src_clk_reg(struct ice_pf *pf, struct ptp_system_timestamp *sts)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u32 hi, lo, lo2;
|
|
|
|
u8 tmr_idx;
|
|
|
|
|
|
|
|
tmr_idx = ice_get_ptp_src_clock_index(hw);
|
|
|
|
/* Read the system timestamp pre PHC read */
|
2021-06-14 09:59:16 -07:00
|
|
|
ptp_read_system_prets(sts);
|
2021-06-09 09:39:50 -07:00
|
|
|
|
|
|
|
lo = rd32(hw, GLTSYN_TIME_L(tmr_idx));
|
|
|
|
|
|
|
|
/* Read the system timestamp post PHC read */
|
2021-06-14 09:59:16 -07:00
|
|
|
ptp_read_system_postts(sts);
|
2021-06-09 09:39:50 -07:00
|
|
|
|
|
|
|
hi = rd32(hw, GLTSYN_TIME_H(tmr_idx));
|
|
|
|
lo2 = rd32(hw, GLTSYN_TIME_L(tmr_idx));
|
|
|
|
|
|
|
|
if (lo2 < lo) {
|
|
|
|
/* if TIME_L rolled over read TIME_L again and update
|
|
|
|
* system timestamps
|
|
|
|
*/
|
2021-06-14 09:59:16 -07:00
|
|
|
ptp_read_system_prets(sts);
|
2021-06-09 09:39:50 -07:00
|
|
|
lo = rd32(hw, GLTSYN_TIME_L(tmr_idx));
|
2021-06-14 09:59:16 -07:00
|
|
|
ptp_read_system_postts(sts);
|
2021-06-09 09:39:50 -07:00
|
|
|
hi = rd32(hw, GLTSYN_TIME_H(tmr_idx));
|
|
|
|
}
|
|
|
|
|
|
|
|
return ((u64)hi << 32) | lo;
|
|
|
|
}
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_extend_32b_ts - Convert a 32b nanoseconds timestamp to 64b
|
|
|
|
* @cached_phc_time: recently cached copy of PHC time
|
|
|
|
* @in_tstamp: Ingress/egress 32b nanoseconds timestamp value
|
|
|
|
*
|
|
|
|
* Hardware captures timestamps which contain only 32 bits of nominal
|
|
|
|
* nanoseconds, as opposed to the 64bit timestamps that the stack expects.
|
|
|
|
* Note that the captured timestamp values may be 40 bits, but the lower
|
|
|
|
* 8 bits are sub-nanoseconds and generally discarded.
|
|
|
|
*
|
|
|
|
* Extend the 32bit nanosecond timestamp using the following algorithm and
|
|
|
|
* assumptions:
|
|
|
|
*
|
|
|
|
* 1) have a recently cached copy of the PHC time
|
|
|
|
* 2) assume that the in_tstamp was captured 2^31 nanoseconds (~2.1
|
|
|
|
* seconds) before or after the PHC time was captured.
|
|
|
|
* 3) calculate the delta between the cached time and the timestamp
|
|
|
|
* 4) if the delta is smaller than 2^31 nanoseconds, then the timestamp was
|
|
|
|
* captured after the PHC time. In this case, the full timestamp is just
|
|
|
|
* the cached PHC time plus the delta.
|
|
|
|
* 5) otherwise, if the delta is larger than 2^31 nanoseconds, then the
|
|
|
|
* timestamp was captured *before* the PHC time, i.e. because the PHC
|
|
|
|
* cache was updated after the timestamp was captured by hardware. In this
|
|
|
|
* case, the full timestamp is the cached time minus the inverse delta.
|
|
|
|
*
|
|
|
|
* This algorithm works even if the PHC time was updated after a Tx timestamp
|
|
|
|
* was requested, but before the Tx timestamp event was reported from
|
|
|
|
* hardware.
|
|
|
|
*
|
|
|
|
* This calculation primarily relies on keeping the cached PHC time up to
|
|
|
|
* date. If the timestamp was captured more than 2^31 nanoseconds after the
|
|
|
|
* PHC time, it is possible that the lower 32bits of PHC time have
|
|
|
|
* overflowed more than once, and we might generate an incorrect timestamp.
|
|
|
|
*
|
|
|
|
* This is prevented by (a) periodically updating the cached PHC time once
|
|
|
|
* a second, and (b) discarding any Tx timestamp packet if it has waited for
|
|
|
|
* a timestamp for more than one second.
|
|
|
|
*/
|
|
|
|
static u64 ice_ptp_extend_32b_ts(u64 cached_phc_time, u32 in_tstamp)
|
|
|
|
{
|
|
|
|
u32 delta, phc_time_lo;
|
|
|
|
u64 ns;
|
|
|
|
|
|
|
|
/* Extract the lower 32 bits of the PHC time */
|
|
|
|
phc_time_lo = (u32)cached_phc_time;
|
|
|
|
|
|
|
|
/* Calculate the delta between the lower 32bits of the cached PHC
|
|
|
|
* time and the in_tstamp value
|
|
|
|
*/
|
|
|
|
delta = (in_tstamp - phc_time_lo);
|
|
|
|
|
|
|
|
/* Do not assume that the in_tstamp is always more recent than the
|
|
|
|
* cached PHC time. If the delta is large, it indicates that the
|
|
|
|
* in_tstamp was taken in the past, and should be converted
|
|
|
|
* forward.
|
|
|
|
*/
|
|
|
|
if (delta > (U32_MAX / 2)) {
|
|
|
|
/* reverse the delta calculation here */
|
|
|
|
delta = (phc_time_lo - in_tstamp);
|
|
|
|
ns = cached_phc_time - delta;
|
|
|
|
} else {
|
|
|
|
ns = cached_phc_time + delta;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ns;
|
|
|
|
}
|
|
|
|
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_extend_40b_ts - Convert a 40b timestamp to 64b nanoseconds
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @in_tstamp: Ingress/egress 40b timestamp value
|
|
|
|
*
|
|
|
|
* The Tx and Rx timestamps are 40 bits wide, including 32 bits of nominal
|
|
|
|
* nanoseconds, 7 bits of sub-nanoseconds, and a valid bit.
|
|
|
|
*
|
|
|
|
* *--------------------------------------------------------------*
|
|
|
|
* | 32 bits of nanoseconds | 7 high bits of sub ns underflow | v |
|
|
|
|
* *--------------------------------------------------------------*
|
|
|
|
*
|
|
|
|
* The low bit is an indicator of whether the timestamp is valid. The next
|
|
|
|
* 7 bits are a capture of the upper 7 bits of the sub-nanosecond underflow,
|
|
|
|
* and the remaining 32 bits are the lower 32 bits of the PHC timer.
|
|
|
|
*
|
|
|
|
* It is assumed that the caller verifies the timestamp is valid prior to
|
|
|
|
* calling this function.
|
|
|
|
*
|
|
|
|
* Extract the 32bit nominal nanoseconds and extend them. Use the cached PHC
|
|
|
|
* time stored in the device private PTP structure as the basis for timestamp
|
|
|
|
* extension.
|
|
|
|
*
|
|
|
|
* See ice_ptp_extend_32b_ts for a detailed explanation of the extension
|
|
|
|
* algorithm.
|
|
|
|
*/
|
|
|
|
static u64 ice_ptp_extend_40b_ts(struct ice_pf *pf, u64 in_tstamp)
|
|
|
|
{
|
|
|
|
const u64 mask = GENMASK_ULL(31, 0);
|
2022-07-27 16:16:00 -07:00
|
|
|
unsigned long discard_time;
|
|
|
|
|
|
|
|
/* Discard the hardware timestamp if the cached PHC time is too old */
|
|
|
|
discard_time = pf->ptp.cached_phc_jiffies + msecs_to_jiffies(2000);
|
|
|
|
if (time_is_before_jiffies(discard_time)) {
|
|
|
|
pf->ptp.tx_hwtstamp_discarded++;
|
|
|
|
return 0;
|
|
|
|
}
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
|
|
|
|
return ice_ptp_extend_32b_ts(pf->ptp.cached_phc_time,
|
|
|
|
(in_tstamp >> 8) & mask);
|
|
|
|
}
|
|
|
|
|
2022-12-05 11:52:47 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_is_tx_tracker_up - Check if Tx tracker is ready for new timestamps
|
|
|
|
* @tx: the PTP Tx timestamp tracker to check
|
|
|
|
*
|
|
|
|
* Check that a given PTP Tx timestamp tracker is up, i.e. that it is ready
|
|
|
|
* to accept new timestamp requests.
|
|
|
|
*
|
|
|
|
* Assumes the tx->lock spinlock is already held.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ice_ptp_is_tx_tracker_up(struct ice_ptp_tx *tx)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&tx->lock);
|
|
|
|
|
|
|
|
return tx->init && !tx->calibrating;
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
2023-06-01 14:15:05 -07:00
|
|
|
* ice_ptp_process_tx_tstamp - Process Tx timestamps for a port
|
2022-09-16 13:17:28 -07:00
|
|
|
* @tx: the PTP Tx timestamp tracker
|
2021-06-09 09:39:50 -07:00
|
|
|
*
|
2022-07-27 16:16:01 -07:00
|
|
|
* Process timestamps captured by the PHY associated with this port. To do
|
|
|
|
* this, loop over each index with a waiting skb.
|
|
|
|
*
|
|
|
|
* If a given index has a valid timestamp, perform the following steps:
|
|
|
|
*
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
* 1) check that the timestamp request is not stale
|
|
|
|
* 2) check that a timestamp is ready and available in the PHY memory bank
|
|
|
|
* 3) read and copy the timestamp out of the PHY register
|
|
|
|
* 4) unlock the index by clearing the associated in_use bit
|
|
|
|
* 5) check if the timestamp is stale, and discard if so
|
|
|
|
* 6) extend the 40 bit timestamp value to get a 64 bit timestamp value
|
|
|
|
* 7) send this 64 bit timestamp to the stack
|
2022-07-27 16:16:01 -07:00
|
|
|
*
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
* Note that we do not hold the tracking lock while reading the Tx timestamp.
|
|
|
|
* This is because reading the timestamp requires taking a mutex that might
|
|
|
|
* sleep.
|
2022-12-05 11:52:44 -08:00
|
|
|
*
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
* The only place where we set in_use is when a new timestamp is initiated
|
|
|
|
* with a slot index. This is only called in the hard xmit routine where an
|
|
|
|
* SKB has a request flag set. The only places where we clear this bit is this
|
|
|
|
* function, or during teardown when the Tx timestamp tracker is being
|
|
|
|
* removed. A timestamp index will never be re-used until the in_use bit for
|
|
|
|
* that index is cleared.
|
2022-12-05 11:52:44 -08:00
|
|
|
*
|
|
|
|
* If a Tx thread starts a new timestamp, we might not begin processing it
|
|
|
|
* right away but we will notice it at the end when we re-queue the task.
|
|
|
|
*
|
|
|
|
* If a Tx thread starts a new timestamp just after this function exits, the
|
|
|
|
* interrupt for that timestamp should re-trigger this function once
|
|
|
|
* a timestamp is ready.
|
|
|
|
*
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
* In cases where the PTP hardware clock was directly adjusted, some
|
|
|
|
* timestamps may not be able to safely use the timestamp extension math. In
|
|
|
|
* this case, software will set the stale bit for any outstanding Tx
|
|
|
|
* timestamps when the clock is adjusted. Then this function will discard
|
|
|
|
* those captured timestamps instead of sending them to the stack.
|
2022-12-05 11:52:44 -08:00
|
|
|
*
|
|
|
|
* If a Tx packet has been waiting for more than 2 seconds, it is not possible
|
|
|
|
* to correctly extend the timestamp using the cached PHC time. It is
|
|
|
|
* extremely unlikely that a packet will ever take this long to timestamp. If
|
|
|
|
* we detect a Tx timestamp request that has waited for this long we assume
|
|
|
|
* the packet will never be sent by hardware and discard it without reading
|
|
|
|
* the timestamp register.
|
2021-06-09 09:39:50 -07:00
|
|
|
*/
|
2023-06-01 14:15:05 -07:00
|
|
|
static void ice_ptp_process_tx_tstamp(struct ice_ptp_tx *tx)
|
2021-06-09 09:39:50 -07:00
|
|
|
{
|
2022-07-27 16:16:01 -07:00
|
|
|
struct ice_ptp_port *ptp_port;
|
|
|
|
struct ice_pf *pf;
|
2022-12-05 11:52:45 -08:00
|
|
|
struct ice_hw *hw;
|
|
|
|
u64 tstamp_ready;
|
2023-01-19 21:23:16 +01:00
|
|
|
bool link_up;
|
2022-12-05 11:52:45 -08:00
|
|
|
int err;
|
2022-07-27 16:16:01 -07:00
|
|
|
u8 idx;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
ptp_port = container_of(tx, struct ice_ptp_port, tx);
|
|
|
|
pf = ptp_port_to_pf(ptp_port);
|
2022-12-05 11:52:45 -08:00
|
|
|
hw = &pf->hw;
|
|
|
|
|
|
|
|
/* Read the Tx ready status first */
|
|
|
|
err = ice_get_phy_tx_tstamp_ready(hw, tx->block, &tstamp_ready);
|
|
|
|
if (err)
|
2023-06-01 14:15:05 -07:00
|
|
|
return;
|
2022-07-27 16:16:01 -07:00
|
|
|
|
2023-01-19 21:23:16 +01:00
|
|
|
/* Drop packets if the link went down */
|
|
|
|
link_up = ptp_port->link_up;
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
for_each_set_bit(idx, tx->in_use, tx->len) {
|
|
|
|
struct skb_shared_hwtstamps shhwtstamps = {};
|
2022-12-05 11:52:39 -08:00
|
|
|
u8 phy_idx = idx + tx->offset;
|
2022-12-05 11:52:44 -08:00
|
|
|
u64 raw_tstamp = 0, tstamp;
|
2023-01-19 21:23:16 +01:00
|
|
|
bool drop_ts = !link_up;
|
2022-07-27 16:16:01 -07:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
2022-12-05 11:52:44 -08:00
|
|
|
/* Drop packets which have waited for more than 2 seconds */
|
|
|
|
if (time_is_before_jiffies(tx->tstamps[idx].start + 2 * HZ)) {
|
|
|
|
drop_ts = true;
|
|
|
|
|
|
|
|
/* Count the number of Tx timestamps that timed out */
|
|
|
|
pf->ptp.tx_hwtstamp_timeouts++;
|
2022-12-05 11:52:45 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Only read a timestamp from the PHY if its marked as ready
|
|
|
|
* by the tstamp_ready register. This avoids unnecessary
|
|
|
|
* reading of timestamps which are not yet valid. This is
|
|
|
|
* important as we must read all timestamps which are valid
|
|
|
|
* and only timestamps which are valid during each interrupt.
|
|
|
|
* If we do not, the hardware logic for generating a new
|
|
|
|
* interrupt can get stuck on some devices.
|
|
|
|
*/
|
|
|
|
if (!(tstamp_ready & BIT_ULL(phy_idx))) {
|
|
|
|
if (drop_ts)
|
|
|
|
goto skip_ts_read;
|
2022-12-05 11:52:44 -08:00
|
|
|
|
2022-12-05 11:52:45 -08:00
|
|
|
continue;
|
2022-12-05 11:52:44 -08:00
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
ice_trace(tx_tstamp_fw_req, tx->tstamps[idx].skb, idx);
|
|
|
|
|
2022-12-05 11:52:45 -08:00
|
|
|
err = ice_read_phy_tstamp(hw, tx->block, phy_idx, &raw_tstamp);
|
2023-01-19 21:23:16 +01:00
|
|
|
if (err && !drop_ts)
|
2022-07-27 16:16:01 -07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
ice_trace(tx_tstamp_fw_done, tx->tstamps[idx].skb, idx);
|
|
|
|
|
2022-12-05 11:52:45 -08:00
|
|
|
/* For PHYs which don't implement a proper timestamp ready
|
|
|
|
* bitmap, verify that the timestamp value is different
|
|
|
|
* from the last cached timestamp. If it is not, skip this for
|
|
|
|
* now assuming it hasn't yet been captured by hardware.
|
|
|
|
*/
|
|
|
|
if (!drop_ts && tx->verify_cached &&
|
2022-07-27 16:16:01 -07:00
|
|
|
raw_tstamp == tx->tstamps[idx].cached_tstamp)
|
|
|
|
continue;
|
|
|
|
|
2022-12-05 11:52:45 -08:00
|
|
|
/* Discard any timestamp value without the valid bit set */
|
|
|
|
if (!(raw_tstamp & ICE_PTP_TS_VALID))
|
|
|
|
drop_ts = true;
|
|
|
|
|
2022-12-05 11:52:44 -08:00
|
|
|
skip_ts_read:
|
2022-07-27 16:16:01 -07:00
|
|
|
spin_lock(&tx->lock);
|
2022-12-05 11:52:45 -08:00
|
|
|
if (tx->verify_cached && raw_tstamp)
|
2022-12-05 11:52:44 -08:00
|
|
|
tx->tstamps[idx].cached_tstamp = raw_tstamp;
|
2022-07-27 16:16:01 -07:00
|
|
|
clear_bit(idx, tx->in_use);
|
|
|
|
skb = tx->tstamps[idx].skb;
|
|
|
|
tx->tstamps[idx].skb = NULL;
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
if (test_and_clear_bit(idx, tx->stale))
|
|
|
|
drop_ts = true;
|
2022-07-27 16:16:01 -07:00
|
|
|
spin_unlock(&tx->lock);
|
|
|
|
|
2022-12-05 11:52:44 -08:00
|
|
|
/* It is unlikely but possible that the SKB will have been
|
|
|
|
* flushed at this point due to link change or teardown.
|
2022-07-27 16:16:01 -07:00
|
|
|
*/
|
|
|
|
if (!skb)
|
|
|
|
continue;
|
|
|
|
|
2022-12-05 11:52:44 -08:00
|
|
|
if (drop_ts) {
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
/* Extend the timestamp using cached PHC time */
|
|
|
|
tstamp = ice_ptp_extend_40b_ts(pf, raw_tstamp);
|
|
|
|
if (tstamp) {
|
|
|
|
shhwtstamps.hwtstamp = ns_to_ktime(tstamp);
|
|
|
|
ice_trace(tx_tstamp_complete, skb, idx);
|
|
|
|
}
|
|
|
|
|
|
|
|
skb_tstamp_tx(skb, &shhwtstamps);
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
}
|
2023-06-01 14:15:05 -07:00
|
|
|
}
|
2022-07-27 16:16:01 -07:00
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_tx_tstamp_owner - Process Tx timestamps for all ports on the device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static enum ice_tx_tstamp_work ice_ptp_tx_tstamp_owner(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_ptp_port *port;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
mutex_lock(&pf->ptp.ports_owner.lock);
|
|
|
|
list_for_each_entry(port, &pf->ptp.ports_owner.ports, list_member) {
|
|
|
|
struct ice_ptp_tx *tx = &port->tx;
|
|
|
|
|
|
|
|
if (!tx || !tx->init)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ice_ptp_process_tx_tstamp(tx);
|
|
|
|
}
|
|
|
|
mutex_unlock(&pf->ptp.ports_owner.lock);
|
|
|
|
|
|
|
|
for (i = 0; i < ICE_MAX_QUAD; i++) {
|
|
|
|
u64 tstamp_ready;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Read the Tx ready status first */
|
|
|
|
err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);
|
|
|
|
if (err || tstamp_ready)
|
|
|
|
return ICE_TX_TSTAMP_WORK_PENDING;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ICE_TX_TSTAMP_WORK_DONE;
|
|
|
|
}
|
|
|
|
|
2023-06-01 14:15:05 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_tx_tstamp - Process Tx timestamps for this function.
|
|
|
|
* @tx: Tx tracking structure to initialize
|
|
|
|
*
|
|
|
|
* Returns: ICE_TX_TSTAMP_WORK_PENDING if there are any outstanding incomplete
|
|
|
|
* Tx timestamps, or ICE_TX_TSTAMP_WORK_DONE otherwise.
|
|
|
|
*/
|
|
|
|
static enum ice_tx_tstamp_work ice_ptp_tx_tstamp(struct ice_ptp_tx *tx)
|
|
|
|
{
|
|
|
|
bool more_timestamps;
|
|
|
|
|
|
|
|
if (!tx->init)
|
|
|
|
return ICE_TX_TSTAMP_WORK_DONE;
|
|
|
|
|
|
|
|
/* Process the Tx timestamp tracker */
|
|
|
|
ice_ptp_process_tx_tstamp(tx);
|
|
|
|
|
|
|
|
/* Check if there are outstanding Tx timestamps */
|
2022-07-27 16:16:01 -07:00
|
|
|
spin_lock(&tx->lock);
|
2022-12-05 11:52:46 -08:00
|
|
|
more_timestamps = tx->init && !bitmap_empty(tx->in_use, tx->len);
|
2022-07-27 16:16:01 -07:00
|
|
|
spin_unlock(&tx->lock);
|
2022-09-16 13:17:28 -07:00
|
|
|
|
2023-06-01 14:15:05 -07:00
|
|
|
if (more_timestamps)
|
|
|
|
return ICE_TX_TSTAMP_WORK_PENDING;
|
|
|
|
|
|
|
|
return ICE_TX_TSTAMP_WORK_DONE;
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-07-27 16:16:01 -07:00
|
|
|
* ice_ptp_alloc_tx_tracker - Initialize tracking for Tx timestamps
|
|
|
|
* @tx: Tx tracking structure to initialize
|
2021-06-09 09:39:50 -07:00
|
|
|
*
|
2022-07-27 16:16:01 -07:00
|
|
|
* Assumes that the length has already been initialized. Do not call directly,
|
2022-12-05 11:52:39 -08:00
|
|
|
* use the ice_ptp_init_tx_* instead.
|
2021-06-09 09:39:50 -07:00
|
|
|
*/
|
2022-07-27 16:16:01 -07:00
|
|
|
static int
|
|
|
|
ice_ptp_alloc_tx_tracker(struct ice_ptp_tx *tx)
|
2021-06-09 09:39:50 -07:00
|
|
|
{
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
unsigned long *in_use, *stale;
|
2022-12-05 11:52:49 -08:00
|
|
|
struct ice_tx_tstamp *tstamps;
|
|
|
|
|
|
|
|
tstamps = kcalloc(tx->len, sizeof(*tstamps), GFP_KERNEL);
|
|
|
|
in_use = bitmap_zalloc(tx->len, GFP_KERNEL);
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
stale = bitmap_zalloc(tx->len, GFP_KERNEL);
|
2022-12-05 11:52:49 -08:00
|
|
|
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
if (!tstamps || !in_use || !stale) {
|
2022-12-05 11:52:49 -08:00
|
|
|
kfree(tstamps);
|
|
|
|
bitmap_free(in_use);
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
bitmap_free(stale);
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2022-12-05 11:52:49 -08:00
|
|
|
tx->tstamps = tstamps;
|
|
|
|
tx->in_use = in_use;
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
tx->stale = stale;
|
2022-07-27 16:16:01 -07:00
|
|
|
tx->init = 1;
|
|
|
|
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_lock_init(&tx->lock);
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
return 0;
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-07-27 16:16:01 -07:00
|
|
|
* ice_ptp_flush_tx_tracker - Flush any remaining timestamps from the tracker
|
2021-06-09 09:39:50 -07:00
|
|
|
* @pf: Board private structure
|
2022-07-27 16:16:01 -07:00
|
|
|
* @tx: the tracker to flush
|
2022-12-05 11:52:51 -08:00
|
|
|
*
|
|
|
|
* Called during teardown when a Tx tracker is being removed.
|
2021-06-09 09:39:50 -07:00
|
|
|
*/
|
2022-07-27 16:16:01 -07:00
|
|
|
static void
|
|
|
|
ice_ptp_flush_tx_tracker(struct ice_pf *pf, struct ice_ptp_tx *tx)
|
2021-06-09 09:39:50 -07:00
|
|
|
{
|
2022-12-05 11:52:51 -08:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u64 tstamp_ready;
|
|
|
|
int err;
|
2022-07-27 16:16:01 -07:00
|
|
|
u8 idx;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2022-12-05 11:52:51 -08:00
|
|
|
err = ice_get_phy_tx_tstamp_ready(hw, tx->block, &tstamp_ready);
|
|
|
|
if (err) {
|
|
|
|
dev_dbg(ice_pf_to_dev(pf), "Failed to get the Tx tstamp ready bitmap for block %u, err %d\n",
|
|
|
|
tx->block, err);
|
|
|
|
|
|
|
|
/* If we fail to read the Tx timestamp ready bitmap just
|
|
|
|
* skip clearing the PHY timestamps.
|
|
|
|
*/
|
|
|
|
tstamp_ready = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for_each_set_bit(idx, tx->in_use, tx->len) {
|
2022-12-05 11:52:39 -08:00
|
|
|
u8 phy_idx = idx + tx->offset;
|
2022-12-05 11:52:51 -08:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
/* In case this timestamp is ready, we need to clear it. */
|
|
|
|
if (!hw->reset_ongoing && (tstamp_ready & BIT_ULL(phy_idx)))
|
|
|
|
ice_clear_phy_tstamp(hw, tx->block, phy_idx);
|
2022-07-27 16:16:01 -07:00
|
|
|
|
|
|
|
spin_lock(&tx->lock);
|
2022-12-05 11:52:51 -08:00
|
|
|
skb = tx->tstamps[idx].skb;
|
|
|
|
tx->tstamps[idx].skb = NULL;
|
2022-07-27 16:16:01 -07:00
|
|
|
clear_bit(idx, tx->in_use);
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
clear_bit(idx, tx->stale);
|
2022-07-27 16:16:01 -07:00
|
|
|
spin_unlock(&tx->lock);
|
|
|
|
|
2022-12-05 11:52:51 -08:00
|
|
|
/* Count the number of Tx timestamps flushed */
|
|
|
|
pf->ptp.tx_hwtstamp_flushed++;
|
|
|
|
|
|
|
|
/* Free the SKB after we've cleared the bit */
|
|
|
|
dev_kfree_skb_any(skb);
|
2022-07-27 16:16:01 -07:00
|
|
|
}
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_mark_tx_tracker_stale - Mark unfinished timestamps as stale
|
|
|
|
* @tx: the tracker to mark
|
|
|
|
*
|
|
|
|
* Mark currently outstanding Tx timestamps as stale. This prevents sending
|
|
|
|
* their timestamp value to the stack. This is required to prevent extending
|
|
|
|
* the 40bit hardware timestamp incorrectly.
|
|
|
|
*
|
|
|
|
* This should be called when the PTP clock is modified such as after a set
|
|
|
|
* time request.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_mark_tx_tracker_stale(struct ice_ptp_tx *tx)
|
|
|
|
{
|
|
|
|
spin_lock(&tx->lock);
|
|
|
|
bitmap_or(tx->stale, tx->stale, tx->in_use, tx->len);
|
|
|
|
spin_unlock(&tx->lock);
|
|
|
|
}
|
|
|
|
|
2021-10-13 08:47:20 -07:00
|
|
|
/**
|
2022-07-27 16:16:01 -07:00
|
|
|
* ice_ptp_release_tx_tracker - Release allocated memory for Tx tracker
|
2021-10-13 08:47:20 -07:00
|
|
|
* @pf: Board private structure
|
2022-07-27 16:16:01 -07:00
|
|
|
* @tx: Tx tracking structure to release
|
2021-10-13 08:47:20 -07:00
|
|
|
*
|
2022-07-27 16:16:01 -07:00
|
|
|
* Free memory associated with the Tx timestamp tracker.
|
2021-10-13 08:47:20 -07:00
|
|
|
*/
|
2022-07-27 16:16:01 -07:00
|
|
|
static void
|
|
|
|
ice_ptp_release_tx_tracker(struct ice_pf *pf, struct ice_ptp_tx *tx)
|
2021-10-13 08:47:20 -07:00
|
|
|
{
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_lock(&tx->lock);
|
2022-07-27 16:16:01 -07:00
|
|
|
tx->init = 0;
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_unlock(&tx->lock);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2022-12-05 11:52:46 -08:00
|
|
|
/* wait for potentially outstanding interrupt to complete */
|
2023-05-15 21:03:17 +02:00
|
|
|
synchronize_irq(pf->oicr_irq.virq);
|
2022-12-05 11:52:46 -08:00
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
ice_ptp_flush_tx_tracker(pf, tx);
|
|
|
|
|
|
|
|
kfree(tx->tstamps);
|
|
|
|
tx->tstamps = NULL;
|
|
|
|
|
|
|
|
bitmap_free(tx->in_use);
|
|
|
|
tx->in_use = NULL;
|
|
|
|
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
bitmap_free(tx->stale);
|
|
|
|
tx->stale = NULL;
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
tx->len = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_init_tx_e822 - Initialize tracking for Tx timestamps
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @tx: the Tx tracking structure to initialize
|
|
|
|
* @port: the port this structure tracks
|
|
|
|
*
|
|
|
|
* Initialize the Tx timestamp tracker for this port. For generic MAC devices,
|
|
|
|
* the timestamp block is shared for all ports in the same quad. To avoid
|
|
|
|
* ports using the same timestamp index, logically break the block of
|
|
|
|
* registers into chunks based on the port number.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_init_tx_e822(struct ice_pf *pf, struct ice_ptp_tx *tx, u8 port)
|
|
|
|
{
|
2022-12-05 11:52:39 -08:00
|
|
|
tx->block = port / ICE_PORTS_PER_QUAD;
|
|
|
|
tx->offset = (port % ICE_PORTS_PER_QUAD) * INDEX_PER_PORT_E822;
|
|
|
|
tx->len = INDEX_PER_PORT_E822;
|
2022-12-05 11:52:45 -08:00
|
|
|
tx->verify_cached = 0;
|
2022-07-27 16:16:01 -07:00
|
|
|
|
|
|
|
return ice_ptp_alloc_tx_tracker(tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_init_tx_e810 - Initialize tracking for Tx timestamps
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @tx: the Tx tracking structure to initialize
|
|
|
|
*
|
|
|
|
* Initialize the Tx timestamp tracker for this PF. For E810 devices, each
|
|
|
|
* port has its own block of timestamps, independent of the other ports.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_init_tx_e810(struct ice_pf *pf, struct ice_ptp_tx *tx)
|
|
|
|
{
|
2022-12-05 11:52:39 -08:00
|
|
|
tx->block = pf->hw.port_info->lport;
|
|
|
|
tx->offset = 0;
|
|
|
|
tx->len = INDEX_PER_PORT_E810;
|
2022-12-05 11:52:45 -08:00
|
|
|
/* The E810 PHY does not provide a timestamp ready bitmap. Instead,
|
|
|
|
* verify new timestamps against cached copy of the last read
|
|
|
|
* timestamp.
|
|
|
|
*/
|
|
|
|
tx->verify_cached = 1;
|
2022-07-27 16:16:01 -07:00
|
|
|
|
|
|
|
return ice_ptp_alloc_tx_tracker(tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_update_cached_phctime - Update the cached PHC time values
|
|
|
|
* @pf: Board specific private structure
|
|
|
|
*
|
|
|
|
* This function updates the system time values which are cached in the PF
|
|
|
|
* structure and the Rx rings.
|
|
|
|
*
|
|
|
|
* This function must be called periodically to ensure that the cached value
|
2022-07-27 16:16:02 -07:00
|
|
|
* is never more than 2 seconds old.
|
|
|
|
*
|
|
|
|
* Note that the cached copy in the PF PTP structure is always updated, even
|
|
|
|
* if we can't update the copy in the Rx rings.
|
2022-07-27 16:16:01 -07:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* * 0 - OK, successfully updated
|
|
|
|
* * -EAGAIN - PF was busy, need to reschedule the update
|
|
|
|
*/
|
|
|
|
static int ice_ptp_update_cached_phctime(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
unsigned long update_before;
|
|
|
|
u64 systime;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
update_before = pf->ptp.cached_phc_jiffies + msecs_to_jiffies(2000);
|
|
|
|
if (pf->ptp.cached_phc_time &&
|
|
|
|
time_is_before_jiffies(update_before)) {
|
|
|
|
unsigned long time_taken = jiffies - pf->ptp.cached_phc_jiffies;
|
|
|
|
|
|
|
|
dev_warn(dev, "%u msecs passed between update to cached PHC time\n",
|
|
|
|
jiffies_to_msecs(time_taken));
|
|
|
|
pf->ptp.late_cached_phc_updates++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the current PHC time */
|
|
|
|
systime = ice_ptp_read_src_clk_reg(pf, NULL);
|
|
|
|
|
|
|
|
/* Update the cached PHC time stored in the PF structure */
|
|
|
|
WRITE_ONCE(pf->ptp.cached_phc_time, systime);
|
|
|
|
WRITE_ONCE(pf->ptp.cached_phc_jiffies, jiffies);
|
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
if (test_and_set_bit(ICE_CFG_BUSY, pf->state))
|
|
|
|
return -EAGAIN;
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
ice_for_each_vsi(pf, i) {
|
|
|
|
struct ice_vsi *vsi = pf->vsi[i];
|
|
|
|
int j;
|
|
|
|
|
|
|
|
if (!vsi)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (vsi->type != ICE_VSI_PF)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ice_for_each_rxq(vsi, j) {
|
|
|
|
if (!vsi->rx_rings[j])
|
|
|
|
continue;
|
|
|
|
WRITE_ONCE(vsi->rx_rings[j]->cached_phctime, systime);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
clear_bit(ICE_CFG_BUSY, pf->state);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_reset_cached_phctime - Reset cached PHC time after an update
|
|
|
|
* @pf: Board specific private structure
|
|
|
|
*
|
|
|
|
* This function must be called when the cached PHC time is no longer valid,
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
* such as after a time adjustment. It marks any currently outstanding Tx
|
|
|
|
* timestamps as stale and updates the cached PHC time for both the PF and Rx
|
|
|
|
* rings.
|
|
|
|
*
|
|
|
|
* If updating the PHC time cannot be done immediately, a warning message is
|
|
|
|
* logged and the work item is scheduled immediately to minimize the window
|
|
|
|
* with a wrong cached timestamp.
|
2022-07-27 16:16:02 -07:00
|
|
|
*/
|
|
|
|
static void ice_ptp_reset_cached_phctime(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Update the cached PHC time immediately if possible, otherwise
|
|
|
|
* schedule the work item to execute soon.
|
|
|
|
*/
|
|
|
|
err = ice_ptp_update_cached_phctime(pf);
|
|
|
|
if (err) {
|
|
|
|
/* If another thread is updating the Rx rings, we won't
|
|
|
|
* properly reset them here. This could lead to reporting of
|
|
|
|
* invalid timestamps, but there isn't much we can do.
|
|
|
|
*/
|
|
|
|
dev_warn(dev, "%s: ICE_CFG_BUSY, unable to immediately update cached PHC time\n",
|
|
|
|
__func__);
|
|
|
|
|
|
|
|
/* Queue the work item to update the Rx rings when possible */
|
|
|
|
kthread_queue_delayed_work(pf->ptp.kworker, &pf->ptp.work,
|
|
|
|
msecs_to_jiffies(10));
|
|
|
|
}
|
|
|
|
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
/* Mark any outstanding timestamps as stale, since they might have
|
|
|
|
* been captured in hardware before the time update. This could lead
|
|
|
|
* to us extending them with the wrong cached value resulting in
|
|
|
|
* incorrect timestamp values.
|
|
|
|
*/
|
|
|
|
ice_ptp_mark_tx_tracker_stale(&pf->ptp.port.tx);
|
2022-07-27 16:16:02 -07:00
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_read_time - Read the time from the device
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ts: timespec structure to hold the current time value
|
|
|
|
* @sts: Optional parameter for holding a pair of system timestamps from
|
|
|
|
* the system clock. Will be ignored if NULL is given.
|
|
|
|
*
|
|
|
|
* This function reads the source clock registers and stores them in a timespec.
|
|
|
|
* However, since the registers are 64 bits of nanoseconds, we must convert the
|
|
|
|
* result to a timespec before we can return.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_read_time(struct ice_pf *pf, struct timespec64 *ts,
|
|
|
|
struct ptp_system_timestamp *sts)
|
|
|
|
{
|
|
|
|
u64 time_ns = ice_ptp_read_src_clk_reg(pf, sts);
|
|
|
|
|
|
|
|
*ts = ns_to_timespec64(time_ns);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_write_init - Set PHC time to provided value
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ts: timespec structure that holds the new time value
|
|
|
|
*
|
|
|
|
* Set the PHC time to the specified time provided in the timespec.
|
|
|
|
*/
|
|
|
|
static int ice_ptp_write_init(struct ice_pf *pf, struct timespec64 *ts)
|
|
|
|
{
|
|
|
|
u64 ns = timespec64_to_ns(ts);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
|
|
|
return ice_ptp_init_time(hw, ns);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_write_adj - Adjust PHC clock time atomically
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @adj: Adjustment in nanoseconds
|
|
|
|
*
|
|
|
|
* Perform an atomic adjustment of the PHC time by the specified number of
|
|
|
|
* nanoseconds.
|
|
|
|
*/
|
|
|
|
static int ice_ptp_write_adj(struct ice_pf *pf, s32 adj)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
|
|
|
return ice_ptp_adj_clock(hw, adj);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_base_incval - Get base timer increment value
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Look up the base timer increment value for this device. The base increment
|
|
|
|
* value is used to define the nominal clock tick rate. This increment value
|
|
|
|
* is programmed during device initialization. It is also used as the basis
|
|
|
|
* for calculating adjustments using scaled_ppm.
|
|
|
|
*/
|
|
|
|
static u64 ice_base_incval(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u64 incval;
|
|
|
|
|
|
|
|
if (ice_is_e810(hw))
|
|
|
|
incval = ICE_PTP_NOMINAL_INCVAL_E810;
|
|
|
|
else if (ice_e822_time_ref(hw) < NUM_ICE_TIME_REF_FREQ)
|
|
|
|
incval = ice_e822_nominal_incval(ice_e822_time_ref(hw));
|
|
|
|
else
|
|
|
|
incval = UNKNOWN_INCVAL_E822;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
|
|
|
dev_dbg(ice_pf_to_dev(pf), "PTP: using base increment value of 0x%016llx\n",
|
|
|
|
incval);
|
|
|
|
|
|
|
|
return incval;
|
|
|
|
}
|
|
|
|
|
2021-10-13 08:56:58 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_check_tx_fifo - Check whether Tx FIFO is in an OK state
|
|
|
|
* @port: PTP port for which Tx FIFO is checked
|
|
|
|
*/
|
|
|
|
static int ice_ptp_check_tx_fifo(struct ice_ptp_port *port)
|
|
|
|
{
|
|
|
|
int quad = port->port_num / ICE_PORTS_PER_QUAD;
|
|
|
|
int offs = port->port_num % ICE_PORTS_PER_QUAD;
|
|
|
|
struct ice_pf *pf;
|
|
|
|
struct ice_hw *hw;
|
|
|
|
u32 val, phy_sts;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
pf = ptp_port_to_pf(port);
|
|
|
|
hw = &pf->hw;
|
|
|
|
|
|
|
|
if (port->tx_fifo_busy_cnt == FIFO_OK)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* need to read FIFO state */
|
|
|
|
if (offs == 0 || offs == 1)
|
|
|
|
err = ice_read_quad_reg_e822(hw, quad, Q_REG_FIFO01_STATUS,
|
|
|
|
&val);
|
|
|
|
else
|
|
|
|
err = ice_read_quad_reg_e822(hw, quad, Q_REG_FIFO23_STATUS,
|
|
|
|
&val);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to check port %d Tx FIFO, err %d\n",
|
|
|
|
port->port_num, err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (offs & 0x1)
|
|
|
|
phy_sts = (val & Q_REG_FIFO13_M) >> Q_REG_FIFO13_S;
|
|
|
|
else
|
|
|
|
phy_sts = (val & Q_REG_FIFO02_M) >> Q_REG_FIFO02_S;
|
|
|
|
|
|
|
|
if (phy_sts & FIFO_EMPTY) {
|
|
|
|
port->tx_fifo_busy_cnt = FIFO_OK;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
port->tx_fifo_busy_cnt++;
|
|
|
|
|
|
|
|
dev_dbg(ice_pf_to_dev(pf), "Try %d, port %d FIFO not empty\n",
|
|
|
|
port->tx_fifo_busy_cnt, port->port_num);
|
|
|
|
|
|
|
|
if (port->tx_fifo_busy_cnt == ICE_PTP_FIFO_NUM_CHECKS) {
|
|
|
|
dev_dbg(ice_pf_to_dev(pf),
|
|
|
|
"Port %d Tx FIFO still not empty; resetting quad %d\n",
|
|
|
|
port->port_num, quad);
|
2022-12-05 11:52:41 -08:00
|
|
|
ice_ptp_reset_ts_memory_quad_e822(hw, quad);
|
2021-10-13 08:56:58 -07:00
|
|
|
port->tx_fifo_busy_cnt = FIFO_OK;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
* ice_ptp_wait_for_offsets - Check for valid Tx and Rx offsets
|
2021-10-13 08:56:58 -07:00
|
|
|
* @work: Pointer to the kthread_work structure for this task
|
|
|
|
*
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
* Check whether hardware has completed measuring the Tx and Rx offset values
|
|
|
|
* used to configure and enable vernier timestamp calibration.
|
|
|
|
*
|
|
|
|
* Once the offset in either direction is measured, configure the associated
|
|
|
|
* registers with the calibrated offset values and enable timestamping. The Tx
|
|
|
|
* and Rx directions are configured independently as soon as their associated
|
|
|
|
* offsets are known.
|
2021-10-13 08:56:58 -07:00
|
|
|
*
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
* This function reschedules itself until both Tx and Rx calibration have
|
|
|
|
* completed.
|
2021-10-13 08:56:58 -07:00
|
|
|
*/
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
static void ice_ptp_wait_for_offsets(struct kthread_work *work)
|
2021-10-13 08:56:58 -07:00
|
|
|
{
|
|
|
|
struct ice_ptp_port *port;
|
|
|
|
struct ice_pf *pf;
|
|
|
|
struct ice_hw *hw;
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
int tx_err;
|
|
|
|
int rx_err;
|
2021-10-13 08:56:58 -07:00
|
|
|
|
|
|
|
port = container_of(work, struct ice_ptp_port, ov_work.work);
|
|
|
|
pf = ptp_port_to_pf(port);
|
|
|
|
hw = &pf->hw;
|
|
|
|
|
2022-12-05 11:52:53 -08:00
|
|
|
if (ice_is_reset_in_progress(pf->state)) {
|
|
|
|
/* wait for device driver to complete reset */
|
|
|
|
kthread_queue_delayed_work(pf->ptp.kworker,
|
|
|
|
&port->ov_work,
|
|
|
|
msecs_to_jiffies(100));
|
2022-08-23 13:56:26 +02:00
|
|
|
return;
|
2022-12-05 11:52:53 -08:00
|
|
|
}
|
2022-08-23 13:56:26 +02:00
|
|
|
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
tx_err = ice_ptp_check_tx_fifo(port);
|
|
|
|
if (!tx_err)
|
|
|
|
tx_err = ice_phy_cfg_tx_offset_e822(hw, port->port_num);
|
|
|
|
rx_err = ice_phy_cfg_rx_offset_e822(hw, port->port_num);
|
|
|
|
if (tx_err || rx_err) {
|
|
|
|
/* Tx and/or Rx offset not yet configured, try again later */
|
2021-10-13 08:56:58 -07:00
|
|
|
kthread_queue_delayed_work(pf->ptp.kworker,
|
|
|
|
&port->ov_work,
|
|
|
|
msecs_to_jiffies(100));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_port_phy_stop - Stop timestamping for a PHY port
|
|
|
|
* @ptp_port: PTP port to stop
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_port_phy_stop(struct ice_ptp_port *ptp_port)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_port_to_pf(ptp_port);
|
|
|
|
u8 port = ptp_port->port_num;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (ice_is_e810(hw))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mutex_lock(&ptp_port->ps_lock);
|
|
|
|
|
2021-10-13 08:56:58 -07:00
|
|
|
kthread_cancel_delayed_work_sync(&ptp_port->ov_work);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
err = ice_stop_phy_timer_e822(hw, port, true);
|
|
|
|
if (err)
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to set PHY port %d down, err %d\n",
|
|
|
|
port, err);
|
|
|
|
|
|
|
|
mutex_unlock(&ptp_port->ps_lock);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_port_phy_restart - (Re)start and calibrate PHY timestamping
|
|
|
|
* @ptp_port: PTP port for which the PHY start is set
|
|
|
|
*
|
|
|
|
* Start the PHY timestamping block, and initiate Vernier timestamping
|
|
|
|
* calibration. If timestamping cannot be calibrated (such as if link is down)
|
|
|
|
* then disable the timestamping block instead.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_port_phy_restart(struct ice_ptp_port *ptp_port)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_port_to_pf(ptp_port);
|
|
|
|
u8 port = ptp_port->port_num;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (ice_is_e810(hw))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!ptp_port->link_up)
|
|
|
|
return ice_ptp_port_phy_stop(ptp_port);
|
|
|
|
|
|
|
|
mutex_lock(&ptp_port->ps_lock);
|
|
|
|
|
2021-10-13 08:56:58 -07:00
|
|
|
kthread_cancel_delayed_work_sync(&ptp_port->ov_work);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/* temporarily disable Tx timestamps while calibrating PHY offset */
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_lock(&ptp_port->tx.lock);
|
2021-10-13 08:54:51 -07:00
|
|
|
ptp_port->tx.calibrating = true;
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_unlock(&ptp_port->tx.lock);
|
2021-10-13 08:56:58 -07:00
|
|
|
ptp_port->tx_fifo_busy_cnt = 0;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2022-12-05 11:52:40 -08:00
|
|
|
/* Start the PHY timer in Vernier mode */
|
|
|
|
err = ice_start_phy_timer_e822(hw, port);
|
2021-10-13 08:54:51 -07:00
|
|
|
if (err)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
/* Enable Tx timestamps right away */
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_lock(&ptp_port->tx.lock);
|
2021-10-13 08:54:51 -07:00
|
|
|
ptp_port->tx.calibrating = false;
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_unlock(&ptp_port->tx.lock);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2021-10-13 08:56:58 -07:00
|
|
|
kthread_queue_delayed_work(pf->ptp.kworker, &ptp_port->ov_work, 0);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
out_unlock:
|
|
|
|
if (err)
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to set PHY port %d up, err %d\n",
|
|
|
|
port, err);
|
|
|
|
|
|
|
|
mutex_unlock(&ptp_port->ps_lock);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-12-05 11:52:43 -08:00
|
|
|
* ice_ptp_link_change - Reconfigure PTP after link status change
|
2021-10-13 08:54:51 -07:00
|
|
|
* @pf: Board private structure
|
|
|
|
* @port: Port for which the PHY start is set
|
|
|
|
* @linkup: Link is up or down
|
|
|
|
*/
|
2022-12-05 11:52:43 -08:00
|
|
|
void ice_ptp_link_change(struct ice_pf *pf, u8 port, bool linkup)
|
2021-10-13 08:54:51 -07:00
|
|
|
{
|
|
|
|
struct ice_ptp_port *ptp_port;
|
2023-07-17 15:17:13 -07:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2022-12-05 11:52:43 -08:00
|
|
|
if (!test_bit(ICE_FLAG_PTP, pf->flags))
|
|
|
|
return;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2022-12-05 11:52:43 -08:00
|
|
|
if (WARN_ON_ONCE(port >= ICE_NUM_EXTERNAL_PORTS))
|
|
|
|
return;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
|
|
|
ptp_port = &pf->ptp.port;
|
2022-12-05 11:52:43 -08:00
|
|
|
if (WARN_ON_ONCE(ptp_port->port_num != port))
|
|
|
|
return;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2022-12-05 11:52:42 -08:00
|
|
|
/* Update cached link status for this port immediately */
|
2021-10-13 08:54:51 -07:00
|
|
|
ptp_port->link_up = linkup;
|
|
|
|
|
2023-07-17 15:17:13 -07:00
|
|
|
switch (hw->phy_model) {
|
|
|
|
case ICE_PHY_E810:
|
|
|
|
/* Do not reconfigure E810 PHY */
|
2022-12-05 11:52:43 -08:00
|
|
|
return;
|
2023-07-17 15:17:13 -07:00
|
|
|
case ICE_PHY_E822:
|
|
|
|
ice_ptp_port_phy_restart(ptp_port);
|
|
|
|
return;
|
|
|
|
default:
|
|
|
|
dev_warn(ice_pf_to_dev(pf), "%s: Unknown PHY type\n", __func__);
|
|
|
|
}
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_tx_ena_intr - Enable or disable the Tx timestamp interrupt
|
|
|
|
* @pf: PF private structure
|
|
|
|
* @ena: bool value to enable or disable interrupt
|
|
|
|
* @threshold: Minimum number of packets at which intr is triggered
|
|
|
|
*
|
|
|
|
* Utility function to enable or disable Tx timestamp interrupt and threshold
|
|
|
|
*/
|
|
|
|
static int ice_ptp_tx_ena_intr(struct ice_pf *pf, bool ena, u32 threshold)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err = 0;
|
|
|
|
int quad;
|
|
|
|
u32 val;
|
|
|
|
|
2022-12-05 11:52:41 -08:00
|
|
|
ice_ptp_reset_ts_memory(hw);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
|
|
|
for (quad = 0; quad < ICE_MAX_QUAD; quad++) {
|
|
|
|
err = ice_read_quad_reg_e822(hw, quad, Q_REG_TX_MEM_GBL_CFG,
|
|
|
|
&val);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (ena) {
|
|
|
|
val |= Q_REG_TX_MEM_GBL_CFG_INTR_ENA_M;
|
|
|
|
val &= ~Q_REG_TX_MEM_GBL_CFG_INTR_THR_M;
|
|
|
|
val |= ((threshold << Q_REG_TX_MEM_GBL_CFG_INTR_THR_S) &
|
|
|
|
Q_REG_TX_MEM_GBL_CFG_INTR_THR_M);
|
|
|
|
} else {
|
|
|
|
val &= ~Q_REG_TX_MEM_GBL_CFG_INTR_ENA_M;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = ice_write_quad_reg_e822(hw, quad, Q_REG_TX_MEM_GBL_CFG,
|
|
|
|
val);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed in intr ena, err %d\n",
|
|
|
|
err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_reset_phy_timestamping - Reset PHY timestamping block
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_reset_phy_timestamping(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
ice_ptp_port_phy_restart(&pf->ptp.port);
|
2021-10-13 08:47:20 -07:00
|
|
|
}
|
|
|
|
|
2023-07-27 15:50:35 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_restart_all_phy - Restart all PHYs to recalibrate timestamping
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_restart_all_phy(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct list_head *entry;
|
|
|
|
|
|
|
|
list_for_each(entry, &pf->ptp.ports_owner.ports) {
|
|
|
|
struct ice_ptp_port *port = list_entry(entry,
|
|
|
|
struct ice_ptp_port,
|
|
|
|
list_member);
|
|
|
|
|
|
|
|
if (port->link_up)
|
|
|
|
ice_ptp_port_phy_restart(port);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_adjfine - Adjust clock increment rate
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @scaled_ppm: Parts per million with 16-bit fractional field
|
|
|
|
*
|
|
|
|
* Adjust the frequency of the clock by the indicated scaled ppm from the
|
|
|
|
* base frequency.
|
|
|
|
*/
|
|
|
|
static int ice_ptp_adjfine(struct ptp_clock_info *info, long scaled_ppm)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
2022-10-28 04:04:13 -07:00
|
|
|
u64 incval;
|
2021-06-09 09:39:50 -07:00
|
|
|
int err;
|
|
|
|
|
2022-10-28 04:04:13 -07:00
|
|
|
incval = adjust_by_scaled_ppm(ice_base_incval(pf), scaled_ppm);
|
2021-06-09 09:39:50 -07:00
|
|
|
err = ice_ptp_write_incval_locked(hw, incval);
|
|
|
|
if (err) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to set incval, err %d\n",
|
|
|
|
err);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
/**
|
2023-06-01 14:15:03 -07:00
|
|
|
* ice_ptp_extts_event - Process PTP external clock event
|
|
|
|
* @pf: Board private structure
|
2021-06-16 09:35:22 -07:00
|
|
|
*/
|
2023-06-01 14:15:03 -07:00
|
|
|
void ice_ptp_extts_event(struct ice_pf *pf)
|
2021-06-16 09:35:22 -07:00
|
|
|
{
|
|
|
|
struct ptp_clock_event event;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 chan, tmr_idx;
|
|
|
|
u32 hi, lo;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_owned;
|
|
|
|
/* Event time is captured by one of the two matched registers
|
|
|
|
* GLTSYN_EVNT_L: 32 LSB of sampled time event
|
|
|
|
* GLTSYN_EVNT_H: 32 MSB of sampled time event
|
|
|
|
* Event is defined in GLTSYN_EVNT_0 register
|
|
|
|
*/
|
|
|
|
for (chan = 0; chan < GLTSYN_EVNT_H_IDX_MAX; chan++) {
|
|
|
|
/* Check if channel is enabled */
|
|
|
|
if (pf->ptp.ext_ts_irq & (1 << chan)) {
|
|
|
|
lo = rd32(hw, GLTSYN_EVNT_L(chan, tmr_idx));
|
|
|
|
hi = rd32(hw, GLTSYN_EVNT_H(chan, tmr_idx));
|
|
|
|
event.timestamp = (((u64)hi) << 32) | lo;
|
|
|
|
event.type = PTP_CLOCK_EXTTS;
|
|
|
|
event.index = chan;
|
|
|
|
|
|
|
|
/* Fire event */
|
|
|
|
ptp_clock_event(pf->ptp.clock, &event);
|
|
|
|
pf->ptp.ext_ts_irq &= ~(1 << chan);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_cfg_extts - Configure EXTTS pin and channel
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ena: true to enable; false to disable
|
|
|
|
* @chan: GPIO channel (0-3)
|
|
|
|
* @gpio_pin: GPIO pin
|
|
|
|
* @extts_flags: request flags from the ptp_extts_request.flags
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_cfg_extts(struct ice_pf *pf, bool ena, unsigned int chan, u32 gpio_pin,
|
|
|
|
unsigned int extts_flags)
|
|
|
|
{
|
|
|
|
u32 func, aux_reg, gpio_reg, irq_reg;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 tmr_idx;
|
|
|
|
|
|
|
|
if (chan > (unsigned int)pf->ptp.info.n_ext_ts)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_owned;
|
|
|
|
|
|
|
|
irq_reg = rd32(hw, PFINT_OICR_ENA);
|
|
|
|
|
|
|
|
if (ena) {
|
|
|
|
/* Enable the interrupt */
|
|
|
|
irq_reg |= PFINT_OICR_TSYN_EVNT_M;
|
|
|
|
aux_reg = GLTSYN_AUX_IN_0_INT_ENA_M;
|
|
|
|
|
|
|
|
#define GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE BIT(0)
|
|
|
|
#define GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE BIT(1)
|
|
|
|
|
|
|
|
/* set event level to requested edge */
|
|
|
|
if (extts_flags & PTP_FALLING_EDGE)
|
|
|
|
aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE;
|
|
|
|
if (extts_flags & PTP_RISING_EDGE)
|
|
|
|
aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE;
|
|
|
|
|
|
|
|
/* Write GPIO CTL reg.
|
|
|
|
* 0x1 is input sampled by EVENT register(channel)
|
|
|
|
* + num_in_channels * tmr_idx
|
|
|
|
*/
|
|
|
|
func = 1 + chan + (tmr_idx * 3);
|
|
|
|
gpio_reg = ((func << GLGEN_GPIO_CTL_PIN_FUNC_S) &
|
|
|
|
GLGEN_GPIO_CTL_PIN_FUNC_M);
|
|
|
|
pf->ptp.ext_ts_chan |= (1 << chan);
|
|
|
|
} else {
|
|
|
|
/* clear the values we set to reset defaults */
|
|
|
|
aux_reg = 0;
|
|
|
|
gpio_reg = 0;
|
|
|
|
pf->ptp.ext_ts_chan &= ~(1 << chan);
|
|
|
|
if (!pf->ptp.ext_ts_chan)
|
|
|
|
irq_reg &= ~PFINT_OICR_TSYN_EVNT_M;
|
|
|
|
}
|
|
|
|
|
|
|
|
wr32(hw, PFINT_OICR_ENA, irq_reg);
|
|
|
|
wr32(hw, GLTSYN_AUX_IN(chan, tmr_idx), aux_reg);
|
|
|
|
wr32(hw, GLGEN_GPIO_CTL(gpio_pin), gpio_reg);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_cfg_clkout - Configure clock to generate periodic wave
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @chan: GPIO channel (0-3)
|
|
|
|
* @config: desired periodic clk configuration. NULL will disable channel
|
|
|
|
* @store: If set to true the values will be stored
|
|
|
|
*
|
|
|
|
* Configure the internal clock generator modules to generate the clock wave of
|
|
|
|
* specified period.
|
|
|
|
*/
|
|
|
|
static int ice_ptp_cfg_clkout(struct ice_pf *pf, unsigned int chan,
|
|
|
|
struct ice_perout_channel *config, bool store)
|
|
|
|
{
|
|
|
|
u64 current_time, period, start_time, phase;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u32 func, val, gpio_pin;
|
|
|
|
u8 tmr_idx;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_owned;
|
|
|
|
|
|
|
|
/* 0. Reset mode & out_en in AUX_OUT */
|
|
|
|
wr32(hw, GLTSYN_AUX_OUT(chan, tmr_idx), 0);
|
|
|
|
|
|
|
|
/* If we're disabling the output, clear out CLKO and TGT and keep
|
|
|
|
* output level low
|
|
|
|
*/
|
|
|
|
if (!config || !config->ena) {
|
|
|
|
wr32(hw, GLTSYN_CLKO(chan, tmr_idx), 0);
|
|
|
|
wr32(hw, GLTSYN_TGT_L(chan, tmr_idx), 0);
|
|
|
|
wr32(hw, GLTSYN_TGT_H(chan, tmr_idx), 0);
|
|
|
|
|
|
|
|
val = GLGEN_GPIO_CTL_PIN_DIR_M;
|
|
|
|
gpio_pin = pf->ptp.perout_channels[chan].gpio_pin;
|
|
|
|
wr32(hw, GLGEN_GPIO_CTL(gpio_pin), val);
|
|
|
|
|
|
|
|
/* Store the value if requested */
|
|
|
|
if (store)
|
|
|
|
memset(&pf->ptp.perout_channels[chan], 0,
|
|
|
|
sizeof(struct ice_perout_channel));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
period = config->period;
|
|
|
|
start_time = config->start_time;
|
|
|
|
div64_u64_rem(start_time, period, &phase);
|
|
|
|
gpio_pin = config->gpio_pin;
|
|
|
|
|
|
|
|
/* 1. Write clkout with half of required period value */
|
|
|
|
if (period & 0x1) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "CLK Period must be an even value\n");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
period >>= 1;
|
|
|
|
|
|
|
|
/* For proper operation, the GLTSYN_CLKO must be larger than clock tick
|
|
|
|
*/
|
|
|
|
#define MIN_PULSE 3
|
|
|
|
if (period <= MIN_PULSE || period > U32_MAX) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "CLK Period must be > %d && < 2^33",
|
|
|
|
MIN_PULSE * 2);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
wr32(hw, GLTSYN_CLKO(chan, tmr_idx), lower_32_bits(period));
|
|
|
|
|
|
|
|
/* Allow time for programming before start_time is hit */
|
|
|
|
current_time = ice_ptp_read_src_clk_reg(pf, NULL);
|
|
|
|
|
|
|
|
/* if start time is in the past start the timer at the nearest second
|
|
|
|
* maintaining phase
|
|
|
|
*/
|
|
|
|
if (start_time < current_time)
|
2021-08-13 09:50:18 -07:00
|
|
|
start_time = div64_u64(current_time + NSEC_PER_SEC - 1,
|
2021-06-16 09:35:22 -07:00
|
|
|
NSEC_PER_SEC) * NSEC_PER_SEC + phase;
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
if (ice_is_e810(hw))
|
|
|
|
start_time -= E810_OUT_PROP_DELAY_NS;
|
|
|
|
else
|
|
|
|
start_time -= ice_e822_pps_delay(ice_e822_time_ref(hw));
|
2021-06-16 09:35:22 -07:00
|
|
|
|
|
|
|
/* 2. Write TARGET time */
|
|
|
|
wr32(hw, GLTSYN_TGT_L(chan, tmr_idx), lower_32_bits(start_time));
|
|
|
|
wr32(hw, GLTSYN_TGT_H(chan, tmr_idx), upper_32_bits(start_time));
|
|
|
|
|
|
|
|
/* 3. Write AUX_OUT register */
|
|
|
|
val = GLTSYN_AUX_OUT_0_OUT_ENA_M | GLTSYN_AUX_OUT_0_OUTMOD_M;
|
|
|
|
wr32(hw, GLTSYN_AUX_OUT(chan, tmr_idx), val);
|
|
|
|
|
|
|
|
/* 4. write GPIO CTL reg */
|
|
|
|
func = 8 + chan + (tmr_idx * 4);
|
|
|
|
val = GLGEN_GPIO_CTL_PIN_DIR_M |
|
|
|
|
((func << GLGEN_GPIO_CTL_PIN_FUNC_S) & GLGEN_GPIO_CTL_PIN_FUNC_M);
|
|
|
|
wr32(hw, GLGEN_GPIO_CTL(gpio_pin), val);
|
|
|
|
|
|
|
|
/* Store the value if requested */
|
|
|
|
if (store) {
|
|
|
|
memcpy(&pf->ptp.perout_channels[chan], config,
|
|
|
|
sizeof(struct ice_perout_channel));
|
|
|
|
pf->ptp.perout_channels[chan].start_time = phase;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
err:
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to cfg per_clk\n");
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_disable_all_clkout - Disable all currently configured outputs
|
|
|
|
* @pf: pointer to the PF structure
|
|
|
|
*
|
|
|
|
* Disable all currently configured clock outputs. This is necessary before
|
|
|
|
* certain changes to the PTP hardware clock. Use ice_ptp_enable_all_clkout to
|
|
|
|
* re-enable the clocks again.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_disable_all_clkout(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
uint i;
|
|
|
|
|
|
|
|
for (i = 0; i < pf->ptp.info.n_per_out; i++)
|
|
|
|
if (pf->ptp.perout_channels[i].ena)
|
|
|
|
ice_ptp_cfg_clkout(pf, i, NULL, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_enable_all_clkout - Enable all configured periodic clock outputs
|
|
|
|
* @pf: pointer to the PF structure
|
|
|
|
*
|
|
|
|
* Enable all currently configured clock outputs. Use this after
|
|
|
|
* ice_ptp_disable_all_clkout to reconfigure the output signals according to
|
|
|
|
* their configuration.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_enable_all_clkout(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
uint i;
|
|
|
|
|
|
|
|
for (i = 0; i < pf->ptp.info.n_per_out; i++)
|
|
|
|
if (pf->ptp.perout_channels[i].ena)
|
|
|
|
ice_ptp_cfg_clkout(pf, i, &pf->ptp.perout_channels[i],
|
|
|
|
false);
|
|
|
|
}
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_gpio_enable_e810 - Enable/disable ancillary features of PHC
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @rq: The requested feature to change
|
|
|
|
* @on: Enable/disable flag
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_gpio_enable_e810(struct ptp_clock_info *info,
|
|
|
|
struct ptp_clock_request *rq, int on)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_perout_channel clk_cfg = {0};
|
2021-08-17 13:09:18 +02:00
|
|
|
bool sma_pres = false;
|
2021-06-16 09:35:22 -07:00
|
|
|
unsigned int chan;
|
|
|
|
u32 gpio_pin;
|
|
|
|
int err;
|
|
|
|
|
2021-08-17 13:09:18 +02:00
|
|
|
if (ice_is_feature_supported(pf, ICE_F_SMA_CTRL))
|
|
|
|
sma_pres = true;
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
switch (rq->type) {
|
|
|
|
case PTP_CLK_REQ_PEROUT:
|
|
|
|
chan = rq->perout.index;
|
2021-08-17 13:09:18 +02:00
|
|
|
if (sma_pres) {
|
|
|
|
if (chan == ice_pin_desc_e810t[SMA1].chan)
|
|
|
|
clk_cfg.gpio_pin = GPIO_20;
|
|
|
|
else if (chan == ice_pin_desc_e810t[SMA2].chan)
|
|
|
|
clk_cfg.gpio_pin = GPIO_22;
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
} else if (ice_is_e810t(&pf->hw)) {
|
|
|
|
if (chan == 0)
|
|
|
|
clk_cfg.gpio_pin = GPIO_20;
|
|
|
|
else
|
|
|
|
clk_cfg.gpio_pin = GPIO_22;
|
|
|
|
} else if (chan == PPS_CLK_GEN_CHAN) {
|
2021-06-16 09:35:22 -07:00
|
|
|
clk_cfg.gpio_pin = PPS_PIN_INDEX;
|
2021-08-17 13:09:18 +02:00
|
|
|
} else {
|
2021-06-16 09:35:22 -07:00
|
|
|
clk_cfg.gpio_pin = chan;
|
2021-08-17 13:09:18 +02:00
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
|
|
|
|
clk_cfg.period = ((rq->perout.period.sec * NSEC_PER_SEC) +
|
|
|
|
rq->perout.period.nsec);
|
|
|
|
clk_cfg.start_time = ((rq->perout.start.sec * NSEC_PER_SEC) +
|
|
|
|
rq->perout.start.nsec);
|
|
|
|
clk_cfg.ena = !!on;
|
|
|
|
|
|
|
|
err = ice_ptp_cfg_clkout(pf, chan, &clk_cfg, true);
|
|
|
|
break;
|
|
|
|
case PTP_CLK_REQ_EXTTS:
|
|
|
|
chan = rq->extts.index;
|
2021-08-17 13:09:18 +02:00
|
|
|
if (sma_pres) {
|
|
|
|
if (chan < ice_pin_desc_e810t[SMA2].chan)
|
|
|
|
gpio_pin = GPIO_21;
|
|
|
|
else
|
|
|
|
gpio_pin = GPIO_23;
|
|
|
|
} else if (ice_is_e810t(&pf->hw)) {
|
|
|
|
if (chan == 0)
|
|
|
|
gpio_pin = GPIO_21;
|
|
|
|
else
|
|
|
|
gpio_pin = GPIO_23;
|
|
|
|
} else {
|
|
|
|
gpio_pin = chan;
|
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
|
|
|
|
err = ice_ptp_cfg_extts(pf, !!on, chan, gpio_pin,
|
|
|
|
rq->extts.flags);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2022-09-14 12:04:29 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_gpio_enable_e823 - Enable/disable ancillary features of PHC
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @rq: The requested feature to change
|
|
|
|
* @on: Enable/disable flag
|
|
|
|
*/
|
|
|
|
static int ice_ptp_gpio_enable_e823(struct ptp_clock_info *info,
|
|
|
|
struct ptp_clock_request *rq, int on)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_perout_channel clk_cfg = {0};
|
|
|
|
int err;
|
|
|
|
|
|
|
|
switch (rq->type) {
|
|
|
|
case PTP_CLK_REQ_PPS:
|
|
|
|
clk_cfg.gpio_pin = PPS_PIN_INDEX;
|
|
|
|
clk_cfg.period = NSEC_PER_SEC;
|
|
|
|
clk_cfg.ena = !!on;
|
|
|
|
|
|
|
|
err = ice_ptp_cfg_clkout(pf, PPS_CLK_GEN_CHAN, &clk_cfg, true);
|
|
|
|
break;
|
|
|
|
case PTP_CLK_REQ_EXTTS:
|
|
|
|
err = ice_ptp_cfg_extts(pf, !!on, rq->extts.index,
|
|
|
|
TIME_SYNC_PIN_INDEX, rq->extts.flags);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_gettimex64 - Get the time of the clock
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @ts: timespec64 structure to hold the current time value
|
|
|
|
* @sts: Optional parameter for holding a pair of system timestamps from
|
|
|
|
* the system clock. Will be ignored if NULL is given.
|
|
|
|
*
|
|
|
|
* Read the device clock and return the correct value on ns, after converting it
|
|
|
|
* into a timespec struct.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_gettimex64(struct ptp_clock_info *info, struct timespec64 *ts,
|
|
|
|
struct ptp_system_timestamp *sts)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to get time\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
ice_ptp_read_time(pf, ts, sts);
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_settime64 - Set the time of the clock
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @ts: timespec64 structure that holds the new time value
|
|
|
|
*
|
|
|
|
* Set the device clock to the user input value. The conversion from timespec
|
|
|
|
* to ns happens in the write function.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_settime64(struct ptp_clock_info *info, const struct timespec64 *ts)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct timespec64 ts64 = *ts;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err;
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/* For Vernier mode, we need to recalibrate after new settime
|
|
|
|
* Start with disabling timestamp block
|
|
|
|
*/
|
|
|
|
if (pf->ptp.port.link_up)
|
|
|
|
ice_ptp_port_phy_stop(&pf->ptp.port);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
err = -EBUSY;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/* Disable periodic outputs */
|
|
|
|
ice_ptp_disable_all_clkout(pf);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
err = ice_ptp_write_init(pf, &ts64);
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
if (!err)
|
2022-07-27 16:16:02 -07:00
|
|
|
ice_ptp_reset_cached_phctime(pf);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/* Reenable periodic outputs */
|
|
|
|
ice_ptp_enable_all_clkout(pf);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2023-07-27 15:50:35 +02:00
|
|
|
/* Recalibrate and re-enable timestamp blocks for E822/E823 */
|
|
|
|
if (hw->phy_model == ICE_PHY_E822)
|
|
|
|
ice_ptp_restart_all_phy(pf);
|
2021-06-09 09:39:50 -07:00
|
|
|
exit:
|
|
|
|
if (err) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to set time %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_adjtime_nonatomic - Do a non-atomic clock adjustment
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @delta: Offset in nanoseconds to adjust the time by
|
|
|
|
*/
|
|
|
|
static int ice_ptp_adjtime_nonatomic(struct ptp_clock_info *info, s64 delta)
|
|
|
|
{
|
|
|
|
struct timespec64 now, then;
|
2022-02-14 06:33:27 -08:00
|
|
|
int ret;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
|
|
|
then = ns_to_timespec64(delta);
|
2022-02-14 06:33:27 -08:00
|
|
|
ret = ice_ptp_gettimex64(info, &now, NULL);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2021-06-09 09:39:50 -07:00
|
|
|
now = timespec64_add(now, then);
|
|
|
|
|
|
|
|
return ice_ptp_settime64(info, (const struct timespec64 *)&now);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_adjtime - Adjust the time of the clock by the indicated delta
|
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @delta: Offset in nanoseconds to adjust the time by
|
|
|
|
*/
|
|
|
|
static int ice_ptp_adjtime(struct ptp_clock_info *info, s64 delta)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
struct device *dev;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
dev = ice_pf_to_dev(pf);
|
|
|
|
|
|
|
|
/* Hardware only supports atomic adjustments using signed 32-bit
|
|
|
|
* integers. For any adjustment outside this range, perform
|
|
|
|
* a non-atomic get->adjust->set flow.
|
|
|
|
*/
|
|
|
|
if (delta > S32_MAX || delta < S32_MIN) {
|
|
|
|
dev_dbg(dev, "delta = %lld, adjtime non-atomic\n", delta);
|
|
|
|
return ice_ptp_adjtime_nonatomic(info, delta);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
dev_err(dev, "PTP failed to acquire semaphore in adjtime\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/* Disable periodic outputs */
|
|
|
|
ice_ptp_disable_all_clkout(pf);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
err = ice_ptp_write_adj(pf, delta);
|
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/* Reenable periodic outputs */
|
|
|
|
ice_ptp_enable_all_clkout(pf);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "PTP failed to adjust time, err %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
ice_ptp_reset_cached_phctime(pf);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-13 09:00:08 -07:00
|
|
|
#ifdef CONFIG_ICE_HWTS
|
|
|
|
/**
|
|
|
|
* ice_ptp_get_syncdevicetime - Get the cross time stamp info
|
|
|
|
* @device: Current device time
|
|
|
|
* @system: System counter value read synchronously with device time
|
|
|
|
* @ctx: Context provided by timekeeping code
|
|
|
|
*
|
|
|
|
* Read device and system (ART) clock simultaneously and return the corrected
|
|
|
|
* clock values in ns.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_get_syncdevicetime(ktime_t *device,
|
|
|
|
struct system_counterval_t *system,
|
|
|
|
void *ctx)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = (struct ice_pf *)ctx;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u32 hh_lock, hh_art_ctl;
|
|
|
|
int i;
|
|
|
|
|
2023-07-25 14:50:47 -07:00
|
|
|
#define MAX_HH_HW_LOCK_TRIES 5
|
|
|
|
#define MAX_HH_CTL_LOCK_TRIES 100
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_HH_HW_LOCK_TRIES; i++) {
|
|
|
|
/* Get the HW lock */
|
|
|
|
hh_lock = rd32(hw, PFHH_SEM + (PFTSYN_SEM_BYTES * hw->pf_id));
|
|
|
|
if (hh_lock & PFHH_SEM_BUSY_M) {
|
|
|
|
usleep_range(10000, 15000);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2021-10-13 09:00:08 -07:00
|
|
|
if (hh_lock & PFHH_SEM_BUSY_M) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed to get hh lock\n");
|
2023-07-25 14:50:47 -07:00
|
|
|
return -EBUSY;
|
2021-10-13 09:00:08 -07:00
|
|
|
}
|
|
|
|
|
2023-07-25 14:50:48 -07:00
|
|
|
/* Program cmd to master timer */
|
|
|
|
ice_ptp_src_cmd(hw, ICE_PTP_READ_TIME);
|
|
|
|
|
2021-10-13 09:00:08 -07:00
|
|
|
/* Start the ART and device clock sync sequence */
|
|
|
|
hh_art_ctl = rd32(hw, GLHH_ART_CTL);
|
|
|
|
hh_art_ctl = hh_art_ctl | GLHH_ART_CTL_ACTIVE_M;
|
|
|
|
wr32(hw, GLHH_ART_CTL, hh_art_ctl);
|
|
|
|
|
2023-07-25 14:50:47 -07:00
|
|
|
for (i = 0; i < MAX_HH_CTL_LOCK_TRIES; i++) {
|
2021-10-13 09:00:08 -07:00
|
|
|
/* Wait for sync to complete */
|
|
|
|
hh_art_ctl = rd32(hw, GLHH_ART_CTL);
|
|
|
|
if (hh_art_ctl & GLHH_ART_CTL_ACTIVE_M) {
|
|
|
|
udelay(1);
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
u32 hh_ts_lo, hh_ts_hi, tmr_idx;
|
|
|
|
u64 hh_ts;
|
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_assoc;
|
|
|
|
/* Read ART time */
|
|
|
|
hh_ts_lo = rd32(hw, GLHH_ART_TIME_L);
|
|
|
|
hh_ts_hi = rd32(hw, GLHH_ART_TIME_H);
|
|
|
|
hh_ts = ((u64)hh_ts_hi << 32) | hh_ts_lo;
|
|
|
|
*system = convert_art_ns_to_tsc(hh_ts);
|
|
|
|
/* Read Device source clock time */
|
|
|
|
hh_ts_lo = rd32(hw, GLTSYN_HHTIME_L(tmr_idx));
|
|
|
|
hh_ts_hi = rd32(hw, GLTSYN_HHTIME_H(tmr_idx));
|
|
|
|
hh_ts = ((u64)hh_ts_hi << 32) | hh_ts_lo;
|
|
|
|
*device = ns_to_ktime(hh_ts);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2023-07-25 14:50:48 -07:00
|
|
|
|
|
|
|
/* Clear the master timer */
|
|
|
|
ice_ptp_src_cmd(hw, ICE_PTP_NOP);
|
|
|
|
|
2021-10-13 09:00:08 -07:00
|
|
|
/* Release HW lock */
|
|
|
|
hh_lock = rd32(hw, PFHH_SEM + (PFTSYN_SEM_BYTES * hw->pf_id));
|
|
|
|
hh_lock = hh_lock & ~PFHH_SEM_BUSY_M;
|
|
|
|
wr32(hw, PFHH_SEM + (PFTSYN_SEM_BYTES * hw->pf_id), hh_lock);
|
|
|
|
|
2023-07-25 14:50:47 -07:00
|
|
|
if (i == MAX_HH_CTL_LOCK_TRIES)
|
2021-10-13 09:00:08 -07:00
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-07-25 14:50:48 -07:00
|
|
|
* ice_ptp_getcrosststamp_e82x - Capture a device cross timestamp
|
2021-10-13 09:00:08 -07:00
|
|
|
* @info: the driver's PTP info structure
|
|
|
|
* @cts: The memory to fill the cross timestamp info
|
|
|
|
*
|
|
|
|
* Capture a cross timestamp between the ART and the device PTP hardware
|
|
|
|
* clock. Fill the cross timestamp information and report it back to the
|
|
|
|
* caller.
|
|
|
|
*
|
2023-07-25 14:50:48 -07:00
|
|
|
* This is only valid for E822 and E823 devices which have support for
|
|
|
|
* generating the cross timestamp via PCIe PTM.
|
2021-10-13 09:00:08 -07:00
|
|
|
*
|
|
|
|
* In order to correctly correlate the ART timestamp back to the TSC time, the
|
|
|
|
* CPU must have X86_FEATURE_TSC_KNOWN_FREQ.
|
|
|
|
*/
|
|
|
|
static int
|
2023-07-25 14:50:48 -07:00
|
|
|
ice_ptp_getcrosststamp_e82x(struct ptp_clock_info *info,
|
2021-10-13 09:00:08 -07:00
|
|
|
struct system_device_crosststamp *cts)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = ptp_info_to_pf(info);
|
|
|
|
|
|
|
|
return get_device_system_crosststamp(ice_ptp_get_syncdevicetime,
|
|
|
|
pf, NULL, cts);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_ICE_HWTS */
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_get_ts_config - ioctl interface to read the timestamping config
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ifr: ioctl data
|
|
|
|
*
|
|
|
|
* Copy the timestamping config to user buffer
|
|
|
|
*/
|
|
|
|
int ice_ptp_get_ts_config(struct ice_pf *pf, struct ifreq *ifr)
|
|
|
|
{
|
|
|
|
struct hwtstamp_config *config;
|
|
|
|
|
|
|
|
if (!test_bit(ICE_FLAG_PTP, pf->flags))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
config = &pf->ptp.tstamp_config;
|
|
|
|
|
|
|
|
return copy_to_user(ifr->ifr_data, config, sizeof(*config)) ?
|
|
|
|
-EFAULT : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_set_timestamp_mode - Setup driver for requested timestamp mode
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @config: hwtstamp settings requested or saved
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_set_timestamp_mode(struct ice_pf *pf, struct hwtstamp_config *config)
|
|
|
|
{
|
|
|
|
switch (config->tx_type) {
|
|
|
|
case HWTSTAMP_TX_OFF:
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
ice_set_tx_tstamp(pf, false);
|
|
|
|
break;
|
|
|
|
case HWTSTAMP_TX_ON:
|
|
|
|
ice_set_tx_tstamp(pf, true);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -ERANGE;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (config->rx_filter) {
|
|
|
|
case HWTSTAMP_FILTER_NONE:
|
|
|
|
ice_set_rx_tstamp(pf, false);
|
|
|
|
break;
|
|
|
|
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
|
|
|
|
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_NTP_ALL:
|
|
|
|
case HWTSTAMP_FILTER_ALL:
|
|
|
|
ice_set_rx_tstamp(pf, true);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -ERANGE;
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_set_ts_config - ioctl interface to control the timestamping
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ifr: ioctl data
|
|
|
|
*
|
|
|
|
* Get the user config and store it
|
|
|
|
*/
|
|
|
|
int ice_ptp_set_ts_config(struct ice_pf *pf, struct ifreq *ifr)
|
|
|
|
{
|
|
|
|
struct hwtstamp_config config;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!test_bit(ICE_FLAG_PTP, pf->flags))
|
|
|
|
return -EAGAIN;
|
|
|
|
|
|
|
|
if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
err = ice_ptp_set_timestamp_mode(pf, &config);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2021-10-13 08:48:13 -07:00
|
|
|
/* Return the actual configuration set */
|
|
|
|
config = pf->ptp.tstamp_config;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
|
|
|
return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
|
|
|
|
-EFAULT : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_rx_hwtstamp - Check for an Rx timestamp
|
|
|
|
* @rx_ring: Ring to get the VSI info
|
|
|
|
* @rx_desc: Receive descriptor
|
|
|
|
* @skb: Particular skb to send timestamp with
|
|
|
|
*
|
|
|
|
* The driver receives a notification in the receive descriptor with timestamp.
|
|
|
|
* The timestamp is in ns, so we must convert the result first.
|
|
|
|
*/
|
|
|
|
void
|
2021-08-19 13:59:58 +02:00
|
|
|
ice_ptp_rx_hwtstamp(struct ice_rx_ring *rx_ring,
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
union ice_32b_rx_flex_desc *rx_desc, struct sk_buff *skb)
|
|
|
|
{
|
2022-07-27 16:16:02 -07:00
|
|
|
struct skb_shared_hwtstamps *hwtstamps;
|
|
|
|
u64 ts_ns, cached_time;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
u32 ts_high;
|
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
if (!(rx_desc->wb.time_stamp_low & ICE_PTP_TS_VALID))
|
|
|
|
return;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
cached_time = READ_ONCE(rx_ring->cached_phctime);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
2022-07-27 16:16:02 -07:00
|
|
|
/* Do not report a timestamp if we don't have a cached PHC time */
|
|
|
|
if (!cached_time)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Use ice_ptp_extend_32b_ts directly, using the ring-specific cached
|
|
|
|
* PHC value, rather than accessing the PF. This also allows us to
|
|
|
|
* simply pass the upper 32bits of nanoseconds directly. Calling
|
|
|
|
* ice_ptp_extend_40b_ts is unnecessary as it would just discard these
|
|
|
|
* bits itself.
|
|
|
|
*/
|
|
|
|
ts_high = le32_to_cpu(rx_desc->wb.flex_ts.ts_high);
|
|
|
|
ts_ns = ice_ptp_extend_32b_ts(cached_time, ts_high);
|
|
|
|
|
|
|
|
hwtstamps = skb_hwtstamps(skb);
|
|
|
|
memset(hwtstamps, 0, sizeof(*hwtstamps));
|
|
|
|
hwtstamps->hwtstamp = ns_to_ktime(ts_ns);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
}
|
|
|
|
|
2021-08-17 13:09:18 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_disable_sma_pins_e810t - Disable E810-T SMA pins
|
|
|
|
* @pf: pointer to the PF structure
|
|
|
|
* @info: PTP clock info structure
|
|
|
|
*
|
|
|
|
* Disable the OS access to the SMA pins. Called to clear out the OS
|
|
|
|
* indications of pin support when we fail to setup the E810-T SMA control
|
|
|
|
* register.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_disable_sma_pins_e810t(struct ice_pf *pf, struct ptp_clock_info *info)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
|
|
|
|
dev_warn(dev, "Failed to configure E810-T SMA pin control\n");
|
|
|
|
|
|
|
|
info->enable = NULL;
|
|
|
|
info->verify = NULL;
|
|
|
|
info->n_pins = 0;
|
|
|
|
info->n_ext_ts = 0;
|
|
|
|
info->n_per_out = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_setup_sma_pins_e810t - Setup the SMA pins
|
|
|
|
* @pf: pointer to the PF structure
|
|
|
|
* @info: PTP clock info structure
|
|
|
|
*
|
|
|
|
* Finish setting up the SMA pins by allocating pin_config, and setting it up
|
|
|
|
* according to the current status of the SMA. On failure, disable all of the
|
|
|
|
* extended SMA pin support.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_setup_sma_pins_e810t(struct ice_pf *pf, struct ptp_clock_info *info)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Allocate memory for kernel pins interface */
|
|
|
|
info->pin_config = devm_kcalloc(dev, info->n_pins,
|
|
|
|
sizeof(*info->pin_config), GFP_KERNEL);
|
|
|
|
if (!info->pin_config) {
|
|
|
|
ice_ptp_disable_sma_pins_e810t(pf, info);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read current SMA status */
|
|
|
|
err = ice_get_sma_config_e810t(&pf->hw, info->pin_config);
|
|
|
|
if (err)
|
|
|
|
ice_ptp_disable_sma_pins_e810t(pf, info);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-09-08 11:58:52 +02:00
|
|
|
* ice_ptp_setup_pins_e810 - Setup PTP pins in sysfs
|
2021-08-17 13:09:18 +02:00
|
|
|
* @pf: pointer to the PF instance
|
|
|
|
* @info: PTP clock capabilities
|
|
|
|
*/
|
|
|
|
static void
|
2022-09-08 11:58:52 +02:00
|
|
|
ice_ptp_setup_pins_e810(struct ice_pf *pf, struct ptp_clock_info *info)
|
2021-08-17 13:09:18 +02:00
|
|
|
{
|
2022-09-08 11:58:52 +02:00
|
|
|
if (ice_is_feature_supported(pf, ICE_F_SMA_CTRL)) {
|
2022-06-28 12:36:57 +02:00
|
|
|
info->n_ext_ts = N_EXT_TS_E810;
|
2023-08-16 17:00:55 -07:00
|
|
|
info->n_per_out = N_PER_OUT_E810T;
|
2022-06-28 12:36:57 +02:00
|
|
|
info->n_pins = NUM_PTP_PINS_E810T;
|
|
|
|
info->verify = ice_verify_pin_e810t;
|
2021-08-17 13:09:18 +02:00
|
|
|
|
2022-09-08 11:58:52 +02:00
|
|
|
/* Complete setup of the SMA pins */
|
|
|
|
ice_ptp_setup_sma_pins_e810t(pf, info);
|
2023-08-16 17:00:55 -07:00
|
|
|
} else if (ice_is_e810t(&pf->hw)) {
|
|
|
|
info->n_ext_ts = N_EXT_TS_NO_SMA_E810T;
|
|
|
|
info->n_per_out = N_PER_OUT_NO_SMA_E810T;
|
|
|
|
} else {
|
|
|
|
info->n_per_out = N_PER_OUT_E810;
|
|
|
|
info->n_ext_ts = N_EXT_TS_E810;
|
2022-09-08 11:58:52 +02:00
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
}
|
|
|
|
|
2022-09-14 12:04:29 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_setup_pins_e823 - Setup PTP pins in sysfs
|
|
|
|
* @pf: pointer to the PF instance
|
|
|
|
* @info: PTP clock capabilities
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_setup_pins_e823(struct ice_pf *pf, struct ptp_clock_info *info)
|
|
|
|
{
|
|
|
|
info->pps = 1;
|
|
|
|
info->n_per_out = 0;
|
|
|
|
info->n_ext_ts = 1;
|
|
|
|
}
|
|
|
|
|
2021-10-13 09:00:08 -07:00
|
|
|
/**
|
2023-07-25 14:50:48 -07:00
|
|
|
* ice_ptp_set_funcs_e82x - Set specialized functions for E82x support
|
2021-10-13 09:00:08 -07:00
|
|
|
* @pf: Board private structure
|
|
|
|
* @info: PTP info to fill
|
|
|
|
*
|
2023-07-25 14:50:48 -07:00
|
|
|
* Assign functions to the PTP capabiltiies structure for E82x devices.
|
2021-10-13 09:00:08 -07:00
|
|
|
* Functions which operate across all device families should be set directly
|
2023-07-25 14:50:48 -07:00
|
|
|
* in ice_ptp_set_caps. Only add functions here which are distinct for E82x
|
2021-10-13 09:00:08 -07:00
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static void
|
2023-07-25 14:50:48 -07:00
|
|
|
ice_ptp_set_funcs_e82x(struct ice_pf *pf, struct ptp_clock_info *info)
|
2021-10-13 09:00:08 -07:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ICE_HWTS
|
|
|
|
if (boot_cpu_has(X86_FEATURE_ART) &&
|
|
|
|
boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ))
|
2023-07-25 14:50:48 -07:00
|
|
|
info->getcrosststamp = ice_ptp_getcrosststamp_e82x;
|
2021-10-13 09:00:08 -07:00
|
|
|
#endif /* CONFIG_ICE_HWTS */
|
|
|
|
}
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_set_funcs_e810 - Set specialized functions for E810 support
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @info: PTP info to fill
|
|
|
|
*
|
|
|
|
* Assign functions to the PTP capabiltiies structure for E810 devices.
|
|
|
|
* Functions which operate across all device families should be set directly
|
|
|
|
* in ice_ptp_set_caps. Only add functions here which are distinct for e810
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_set_funcs_e810(struct ice_pf *pf, struct ptp_clock_info *info)
|
|
|
|
{
|
|
|
|
info->enable = ice_ptp_gpio_enable_e810;
|
2022-09-08 11:58:52 +02:00
|
|
|
ice_ptp_setup_pins_e810(pf, info);
|
2021-06-16 09:35:22 -07:00
|
|
|
}
|
|
|
|
|
2022-09-14 12:04:29 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_set_funcs_e823 - Set specialized functions for E823 support
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @info: PTP info to fill
|
|
|
|
*
|
|
|
|
* Assign functions to the PTP capabiltiies structure for E823 devices.
|
|
|
|
* Functions which operate across all device families should be set directly
|
|
|
|
* in ice_ptp_set_caps. Only add functions here which are distinct for e823
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_set_funcs_e823(struct ice_pf *pf, struct ptp_clock_info *info)
|
|
|
|
{
|
2023-07-25 14:50:48 -07:00
|
|
|
ice_ptp_set_funcs_e82x(pf, info);
|
|
|
|
|
2022-09-14 12:04:29 +02:00
|
|
|
info->enable = ice_ptp_gpio_enable_e823;
|
|
|
|
ice_ptp_setup_pins_e823(pf, info);
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_set_caps - Set PTP capabilities
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_set_caps(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ptp_clock_info *info = &pf->ptp.info;
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
|
|
|
|
snprintf(info->name, sizeof(info->name) - 1, "%s-%s-clk",
|
|
|
|
dev_driver_string(dev), dev_name(dev));
|
|
|
|
info->owner = THIS_MODULE;
|
ice: restrict PTP HW clock freq adjustments to 100, 000, 000 PPB
The PHY provides only 39b timestamp. With current timing
implementation, we discard lower 7b, leaving 32b timestamp.
The driver reconstructs the full 64b timestamp by correlating the
32b timestamp with cached_time for performance. The reconstruction
algorithm does both forward & backward interpolation.
The 32b timeval has overflow duration of 2^32 counts ~= 4.23 second.
Due to interpolation in both direction, its now ~= 2.125 second
IIRC, going with at least half a duration, the cached_time is updated
with periodic thread of 1 second (worst-case) periodicity.
But the 1 second periodicity is based on System-timer.
With PPB adjustments, if the 1588 timers increments at say
double the rate, (2s in-place of 1s), the Nyquist rate/half duration
sampling/update of cached_time with 1 second periodic thread will
lead to incorrect interpolations.
Hence we should restrict the PPB adjustments to at least half duration
of cached_time update which translates to 500,000,000 PPB.
Since the periodicity of the cached-time system thread can vary,
it is good to have some buffer time and considering practicality of
PPB adjustments, limiting the max_adj to 100,000,000.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-11-15 15:11:35 +05:30
|
|
|
info->max_adj = 100000000;
|
2021-06-09 09:39:50 -07:00
|
|
|
info->adjtime = ice_ptp_adjtime;
|
|
|
|
info->adjfine = ice_ptp_adjfine;
|
|
|
|
info->gettimex64 = ice_ptp_gettimex64;
|
|
|
|
info->settime64 = ice_ptp_settime64;
|
2021-06-16 09:35:22 -07:00
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
if (ice_is_e810(&pf->hw))
|
|
|
|
ice_ptp_set_funcs_e810(pf, info);
|
2022-09-14 12:04:29 +02:00
|
|
|
else if (ice_is_e823(&pf->hw))
|
|
|
|
ice_ptp_set_funcs_e823(pf, info);
|
2021-10-13 09:00:08 -07:00
|
|
|
else
|
2023-07-25 14:50:48 -07:00
|
|
|
ice_ptp_set_funcs_e82x(pf, info);
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_create_clock - Create PTP clock device for userspace
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* This function creates a new PTP clock device. It only creates one if we
|
|
|
|
* don't already have one. Will return error if it can't create one, but success
|
|
|
|
* if we already have a device. Should be used by ice_ptp_init to create clock
|
|
|
|
* initially, and prevent global resets from creating new clock devices.
|
|
|
|
*/
|
|
|
|
static long ice_ptp_create_clock(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ptp_clock_info *info;
|
|
|
|
struct ptp_clock *clock;
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
/* No need to create a clock device if we already have one */
|
|
|
|
if (pf->ptp.clock)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ice_ptp_set_caps(pf);
|
|
|
|
|
|
|
|
info = &pf->ptp.info;
|
|
|
|
dev = ice_pf_to_dev(pf);
|
|
|
|
|
|
|
|
/* Attempt to register the clock before enabling the hardware. */
|
|
|
|
clock = ptp_clock_register(info, dev);
|
|
|
|
if (IS_ERR(clock))
|
|
|
|
return PTR_ERR(clock);
|
|
|
|
|
|
|
|
pf->ptp.clock = clock;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_request_ts - Request an available Tx timestamp index
|
|
|
|
* @tx: the PTP Tx timestamp tracker to request from
|
|
|
|
* @skb: the SKB to associate with this timestamp request
|
|
|
|
*/
|
|
|
|
s8 ice_ptp_request_ts(struct ice_ptp_tx *tx, struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
u8 idx;
|
|
|
|
|
2022-12-05 11:52:47 -08:00
|
|
|
spin_lock(&tx->lock);
|
|
|
|
|
|
|
|
/* Check that this tracker is accepting new timestamp requests */
|
|
|
|
if (!ice_ptp_is_tx_tracker_up(tx)) {
|
|
|
|
spin_unlock(&tx->lock);
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
return -1;
|
2022-12-05 11:52:47 -08:00
|
|
|
}
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
|
|
|
|
/* Find and set the first available index */
|
|
|
|
idx = find_first_zero_bit(tx->in_use, tx->len);
|
|
|
|
if (idx < tx->len) {
|
|
|
|
/* We got a valid index that no other thread could have set. Store
|
|
|
|
* a reference to the skb and the start time to allow discarding old
|
|
|
|
* requests.
|
|
|
|
*/
|
|
|
|
set_bit(idx, tx->in_use);
|
ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp
In the event of a PTP clock time change due to .adjtime or .settime, the
ice driver needs to update the cached copy of the PHC time and also discard
any outstanding Tx timestamps.
This is required because otherwise the wrong copy of the PHC time will be
used when extending the Tx timestamp. This could result in reporting
incorrect timestamps to the stack.
The current approach taken to handle this is to call
ice_ptp_flush_tx_tracker, which will discard any timestamps which are not
yet complete.
This is problematic for two reasons:
1) it could lead to a potential race condition where the wrong timestamp is
associated with a future packet.
This can occur with the following flow:
1. Thread A gets request to transmit a timestamped packet, and picks an
index and transmits the packet
2. Thread B calls ice_ptp_flush_tx_tracker and sees the index in use,
marking is as disarded. No timestamp read occurs because the status
bit is not set, but the index is released for re-use
3. Thread A gets a new request to transmit another timestamped packet,
picks the same (now unused) index and transmits that packet.
4. The PHY transmits the first packet and updates the timestamp slot and
generates an interrupt.
5. The ice_ptp_tx_tstamp thread executes and sees the interrupt and a
valid timestamp but associates it with the new Tx SKB and not the one
that actual timestamp for the packet as expected.
This could result in the previous timestamp being assigned to a new
packet producing incorrect timestamps and leading to incorrect behavior
in PTP applications.
This is most likely to occur when the packet rate for Tx timestamp
requests is very high.
2) on E822 hardware, we must avoid reading a timestamp index more than once
each time its status bit is set and an interrupt is generated by
hardware.
We do have some extensive checks for the unread flag to ensure that only
one of either the ice_ptp_flush_tx_tracker or ice_ptp_tx_tstamp threads
read the timestamp. However, even with this we can still have cases
where we "flush" a timestamp that was actually completed in hardware.
This can lead to cases where we don't read the timestamp index as
appropriate.
To fix both of these issues, we must avoid calling ice_ptp_flush_tx_tracker
outside of the teardown path.
Rather than using ice_ptp_flush_tx_tracker, introduce a new state bitmap,
the stale bitmap. Start this as cleared when we begin a new timestamp
request. When we're about to extend a timestamp and send it up to the
stack, first check to see if that stale bit was set. If so, drop the
timestamp without sending it to the stack.
When we need to update the cached PHC timestamp out of band, just mark all
currently outstanding timestamps as stale. This will ensure that once
hardware completes the timestamp we'll ignore it correctly and avoid
reporting bogus timestamps to userspace.
With this change, we fix potential issues caused by calling
ice_ptp_flush_tx_tracker during normal operation.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:50 -08:00
|
|
|
clear_bit(idx, tx->stale);
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
tx->tstamps[idx].start = jiffies;
|
|
|
|
tx->tstamps[idx].skb = skb_get(skb);
|
|
|
|
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
|
ice: add trace events for tx timestamps
We've previously run into many issues related to the latency of a Tx
timestamp completion with the ice hardware. It can be difficult to
determine the root cause of a slow Tx timestamp. To aid in this,
introduce new trace events which capture timing data about when the
driver reaches certain points while processing a transmit timestamp
* ice_tx_tstamp_request: Trace when the stack initiates a new timestamp
request.
* ice_tx_tstamp_fw_req: Trace when the driver begins a read of the
timestamp register in the work thread.
* ice_tx_tstamp_fw_done: Trace when the driver finishes reading a
timestamp register in the work thread.
* ice_tx_tstamp_complete: Trace when the driver submits the skb back to
the stack with a completed Tx timestamp.
These trace events can be enabled using the standard trace event
subsystem exposed by the ice driver. If they are disabled, they become
no-ops with no run time cost.
The following is a simple GNU AWK script which can highlight one
potential way to use the trace events to capture latency data from the
trace buffer about how long the driver takes to process a timestamp:
-----
BEGIN {
PREC=256
}
# Detect requests
/tx_tstamp_request/ {
time=strtonum($4)
skb=$7
# Store the time of request for this skb
requests[skb] = time
printf("skb %s: idx %d at %.6f\n", skb, idx, time)
}
# Detect completions
/tx_tstamp_complete/ {
time=strtonum($4)
skb=$7
idx=$9
if (skb in requests) {
latency = (time - requests[skb]) * 1000
printf("skb %s: %.3f to complete\n", skb, latency)
if (latency > 4) {
printf(">>> HIGH LATENCY <<<\n")
}
printf("\n")
} else {
printf("!!! skb %s (idx %d) at %.6f\n", skb, idx, time)
}
}
-----
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-01 15:02:28 -08:00
|
|
|
ice_trace(tx_tstamp_request, skb, idx);
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&tx->lock);
|
|
|
|
|
|
|
|
/* return the appropriate PHY timestamp register index, -1 if no
|
|
|
|
* indexes were available.
|
|
|
|
*/
|
|
|
|
if (idx >= tx->len)
|
|
|
|
return -1;
|
|
|
|
else
|
2022-12-05 11:52:39 -08:00
|
|
|
return idx + tx->offset;
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-09-16 13:17:28 -07:00
|
|
|
* ice_ptp_process_ts - Process the PTP Tx timestamps
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
2023-06-01 14:15:05 -07:00
|
|
|
* Returns: ICE_TX_TSTAMP_WORK_PENDING if there are any outstanding Tx
|
|
|
|
* timestamps that need processing, and ICE_TX_TSTAMP_WORK_DONE otherwise.
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
*/
|
2023-06-01 14:15:05 -07:00
|
|
|
enum ice_tx_tstamp_work ice_ptp_process_ts(struct ice_pf *pf)
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
{
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
switch (pf->ptp.tx_interrupt_mode) {
|
|
|
|
case ICE_PTP_TX_INTERRUPT_NONE:
|
|
|
|
/* This device has the clock owner handle timestamps for it */
|
|
|
|
return ICE_TX_TSTAMP_WORK_DONE;
|
|
|
|
case ICE_PTP_TX_INTERRUPT_SELF:
|
|
|
|
/* This device handles its own timestamps */
|
|
|
|
return ice_ptp_tx_tstamp(&pf->ptp.port.tx);
|
|
|
|
case ICE_PTP_TX_INTERRUPT_ALL:
|
|
|
|
/* This device handles timestamps for all ports */
|
|
|
|
return ice_ptp_tx_tstamp_owner(pf);
|
|
|
|
default:
|
|
|
|
WARN_ONCE(1, "Unexpected Tx timestamp interrupt mode %u\n",
|
|
|
|
pf->ptp.tx_interrupt_mode);
|
|
|
|
return ICE_TX_TSTAMP_WORK_DONE;
|
|
|
|
}
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
}
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
static void ice_ptp_periodic_work(struct kthread_work *work)
|
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = container_of(work, struct ice_ptp, work.work);
|
|
|
|
struct ice_pf *pf = container_of(ptp, struct ice_pf, ptp);
|
2022-04-28 10:33:50 +02:00
|
|
|
int err;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
|
|
|
if (!test_bit(ICE_FLAG_PTP, pf->flags))
|
|
|
|
return;
|
|
|
|
|
2022-04-28 10:33:50 +02:00
|
|
|
err = ice_ptp_update_cached_phctime(pf);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
2022-04-28 10:33:50 +02:00
|
|
|
/* Run twice a second or reschedule if phc update failed */
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
kthread_queue_delayed_work(ptp->kworker, &ptp->work,
|
2022-04-28 10:33:50 +02:00
|
|
|
msecs_to_jiffies(err ? 10 : 500));
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
}
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_reset - Initialize PTP hardware clock support after reset
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
void ice_ptp_reset(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
struct timespec64 ts;
|
2021-10-13 08:54:51 -07:00
|
|
|
int err, itr = 1;
|
2021-12-20 08:58:27 -08:00
|
|
|
u64 time_diff;
|
|
|
|
|
|
|
|
if (test_bit(ICE_PFR_REQ, pf->state))
|
|
|
|
goto pfr;
|
|
|
|
|
2023-09-08 14:37:14 -07:00
|
|
|
if (!ice_pf_src_tmr_owned(pf))
|
2021-10-13 08:54:51 -07:00
|
|
|
goto reset_ts;
|
2021-12-20 08:58:27 -08:00
|
|
|
|
2021-10-13 08:52:29 -07:00
|
|
|
err = ice_ptp_init_phc(hw);
|
2021-12-20 08:58:27 -08:00
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/* Acquire the global hardware lock */
|
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
err = -EBUSY;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write the increment time value to PHY and LAN */
|
2021-10-13 08:47:20 -07:00
|
|
|
err = ice_ptp_write_incval(hw, ice_base_incval(pf));
|
2021-12-20 08:58:27 -08:00
|
|
|
if (err) {
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write the initial Time value to PHY and LAN using the cached PHC
|
|
|
|
* time before the reset and time difference between stopping and
|
|
|
|
* starting the clock.
|
|
|
|
*/
|
|
|
|
if (ptp->cached_phc_time) {
|
|
|
|
time_diff = ktime_get_real_ns() - ptp->reset_time;
|
|
|
|
ts = ns_to_timespec64(ptp->cached_phc_time + time_diff);
|
|
|
|
} else {
|
|
|
|
ts = ktime_to_timespec64(ktime_get_real());
|
|
|
|
}
|
|
|
|
err = ice_ptp_write_init(pf, &ts);
|
|
|
|
if (err) {
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release the global hardware lock */
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
if (!ice_is_e810(hw)) {
|
|
|
|
/* Enable quad interrupts */
|
|
|
|
err = ice_ptp_tx_ena_intr(pf, true, itr);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
reset_ts:
|
|
|
|
/* Restart the PHY timestamping block */
|
|
|
|
ice_ptp_reset_phy_timestamping(pf);
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
pfr:
|
|
|
|
/* Init Tx structures */
|
2021-10-13 08:56:58 -07:00
|
|
|
if (ice_is_e810(&pf->hw)) {
|
2021-12-20 08:58:27 -08:00
|
|
|
err = ice_ptp_init_tx_e810(pf, &ptp->port.tx);
|
2021-10-13 08:56:58 -07:00
|
|
|
} else {
|
|
|
|
kthread_init_delayed_work(&ptp->port.ov_work,
|
ice: make Tx and Rx vernier offset calibration independent
The Tx and Rx calibration and timestamp generation blocks are independent.
However, the ice driver waits until both blocks are ready before
configuring either block.
This can result in delay of configuring one block because we have not yet
received a packet in the other block.
There is no reason to wait to finish programming Tx just because we haven't
received a packet. Similarly there is no reason to wait to program Rx just
because we haven't transmitted a packet.
Instead of checking both offset status before programming either block,
refactor the ice_phy_cfg_tx_offset_e822 and ice_phy_cfg_rx_offset_e822
functions so that they perform their own offset status checks.
Additionally, make them also check the offset ready bit to determine if
the offset values have already been programmed.
Call the individual configure functions directly in
ice_ptp_wait_for_offset_valid. The functions will now correctly check
status, and program the offsets if ready. Once the offset is programmed,
the functions will exit quickly after just checking the offset ready
register.
Remove the ice_phy_calc_vernier_e822 in ice_ptp_hw.c, as well as the offset
valid check functions in ice_ptp.c entirely as they are no longer
necessary.
With this change, the Tx and Rx blocks will each be enabled as soon as
possible without waiting for the other block to complete calibration. This
can enable timestamps faster in setups which have a low rate of transmitted
or received packets. In particular, it can stop a situation where one port
never receives traffic, and thus never finishes calibration of the Tx
block, resulting in continuous faults reported by the ptp4l daemon
application.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-12-05 11:52:52 -08:00
|
|
|
ice_ptp_wait_for_offsets);
|
2021-10-13 08:54:51 -07:00
|
|
|
err = ice_ptp_init_tx_e822(pf, &ptp->port.tx,
|
|
|
|
ptp->port.port_num);
|
2021-10-13 08:56:58 -07:00
|
|
|
}
|
2021-12-20 08:58:27 -08:00
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
set_bit(ICE_FLAG_PTP, pf->flags);
|
|
|
|
|
|
|
|
/* Start periodic work going */
|
|
|
|
kthread_queue_delayed_work(ptp->kworker, &ptp->work, 0);
|
|
|
|
|
|
|
|
dev_info(ice_pf_to_dev(pf), "PTP reset successful\n");
|
|
|
|
return;
|
|
|
|
|
|
|
|
err:
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP reset failed %d\n", err);
|
|
|
|
}
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_aux_dev_to_aux_pf - Get auxiliary PF handle for the auxiliary device
|
|
|
|
* @aux_dev: auxiliary device to get the auxiliary PF for
|
|
|
|
*/
|
|
|
|
static struct ice_pf *
|
|
|
|
ice_ptp_aux_dev_to_aux_pf(struct auxiliary_device *aux_dev)
|
|
|
|
{
|
|
|
|
struct ice_ptp_port *aux_port;
|
|
|
|
struct ice_ptp *aux_ptp;
|
|
|
|
|
|
|
|
aux_port = container_of(aux_dev, struct ice_ptp_port, aux_dev);
|
|
|
|
aux_ptp = container_of(aux_port, struct ice_ptp, port);
|
|
|
|
|
|
|
|
return container_of(aux_ptp, struct ice_pf, ptp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_aux_dev_to_owner_pf - Get PF handle for the auxiliary device
|
|
|
|
* @aux_dev: auxiliary device to get the PF for
|
|
|
|
*/
|
|
|
|
static struct ice_pf *
|
|
|
|
ice_ptp_aux_dev_to_owner_pf(struct auxiliary_device *aux_dev)
|
|
|
|
{
|
|
|
|
struct ice_ptp_port_owner *ports_owner;
|
|
|
|
struct auxiliary_driver *aux_drv;
|
|
|
|
struct ice_ptp *owner_ptp;
|
|
|
|
|
|
|
|
if (!aux_dev->dev.driver)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
aux_drv = to_auxiliary_drv(aux_dev->dev.driver);
|
|
|
|
ports_owner = container_of(aux_drv, struct ice_ptp_port_owner,
|
|
|
|
aux_driver);
|
|
|
|
owner_ptp = container_of(ports_owner, struct ice_ptp, ports_owner);
|
|
|
|
return container_of(owner_ptp, struct ice_pf, ptp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_probe - Probe auxiliary devices
|
|
|
|
* @aux_dev: PF's auxiliary device
|
|
|
|
* @id: Auxiliary device ID
|
|
|
|
*/
|
|
|
|
static int ice_ptp_auxbus_probe(struct auxiliary_device *aux_dev,
|
|
|
|
const struct auxiliary_device_id *id)
|
|
|
|
{
|
|
|
|
struct ice_pf *owner_pf = ice_ptp_aux_dev_to_owner_pf(aux_dev);
|
|
|
|
struct ice_pf *aux_pf = ice_ptp_aux_dev_to_aux_pf(aux_dev);
|
|
|
|
|
|
|
|
if (WARN_ON(!owner_pf))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&aux_pf->ptp.port.list_member);
|
|
|
|
mutex_lock(&owner_pf->ptp.ports_owner.lock);
|
|
|
|
list_add(&aux_pf->ptp.port.list_member,
|
|
|
|
&owner_pf->ptp.ports_owner.ports);
|
|
|
|
mutex_unlock(&owner_pf->ptp.ports_owner.lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_remove - Remove auxiliary devices from the bus
|
|
|
|
* @aux_dev: PF's auxiliary device
|
|
|
|
*/
|
|
|
|
static void ice_ptp_auxbus_remove(struct auxiliary_device *aux_dev)
|
|
|
|
{
|
|
|
|
struct ice_pf *owner_pf = ice_ptp_aux_dev_to_owner_pf(aux_dev);
|
|
|
|
struct ice_pf *aux_pf = ice_ptp_aux_dev_to_aux_pf(aux_dev);
|
|
|
|
|
|
|
|
mutex_lock(&owner_pf->ptp.ports_owner.lock);
|
|
|
|
list_del(&aux_pf->ptp.port.list_member);
|
|
|
|
mutex_unlock(&owner_pf->ptp.ports_owner.lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_shutdown
|
|
|
|
* @aux_dev: PF's auxiliary device
|
|
|
|
*/
|
|
|
|
static void ice_ptp_auxbus_shutdown(struct auxiliary_device *aux_dev)
|
|
|
|
{
|
|
|
|
/* Doing nothing here, but handle to auxbus driver must be satisfied */
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_suspend
|
|
|
|
* @aux_dev: PF's auxiliary device
|
|
|
|
* @state: power management state indicator
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_ptp_auxbus_suspend(struct auxiliary_device *aux_dev, pm_message_t state)
|
|
|
|
{
|
|
|
|
/* Doing nothing here, but handle to auxbus driver must be satisfied */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_resume
|
|
|
|
* @aux_dev: PF's auxiliary device
|
|
|
|
*/
|
|
|
|
static int ice_ptp_auxbus_resume(struct auxiliary_device *aux_dev)
|
|
|
|
{
|
|
|
|
/* Doing nothing here, but handle to auxbus driver must be satisfied */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_auxbus_create_id_table - Create auxiliary device ID table
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @name: auxiliary bus driver name
|
|
|
|
*/
|
|
|
|
static struct auxiliary_device_id *
|
|
|
|
ice_ptp_auxbus_create_id_table(struct ice_pf *pf, const char *name)
|
|
|
|
{
|
|
|
|
struct auxiliary_device_id *ids;
|
|
|
|
|
|
|
|
/* Second id left empty to terminate the array */
|
|
|
|
ids = devm_kcalloc(ice_pf_to_dev(pf), 2,
|
|
|
|
sizeof(struct auxiliary_device_id), GFP_KERNEL);
|
|
|
|
if (!ids)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
snprintf(ids[0].name, sizeof(ids[0].name), "ice.%s", name);
|
|
|
|
|
|
|
|
return ids;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_register_auxbus_driver - Register PTP auxiliary bus driver
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static int ice_ptp_register_auxbus_driver(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct auxiliary_driver *aux_driver;
|
|
|
|
struct ice_ptp *ptp;
|
|
|
|
struct device *dev;
|
|
|
|
char *name;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
ptp = &pf->ptp;
|
|
|
|
dev = ice_pf_to_dev(pf);
|
|
|
|
aux_driver = &ptp->ports_owner.aux_driver;
|
|
|
|
INIT_LIST_HEAD(&ptp->ports_owner.ports);
|
|
|
|
mutex_init(&ptp->ports_owner.lock);
|
|
|
|
name = devm_kasprintf(dev, GFP_KERNEL, "ptp_aux_dev_%u_%u_clk%u",
|
|
|
|
pf->pdev->bus->number, PCI_SLOT(pf->pdev->devfn),
|
|
|
|
ice_get_ptp_src_clock_index(&pf->hw));
|
|
|
|
|
|
|
|
aux_driver->name = name;
|
|
|
|
aux_driver->shutdown = ice_ptp_auxbus_shutdown;
|
|
|
|
aux_driver->suspend = ice_ptp_auxbus_suspend;
|
|
|
|
aux_driver->remove = ice_ptp_auxbus_remove;
|
|
|
|
aux_driver->resume = ice_ptp_auxbus_resume;
|
|
|
|
aux_driver->probe = ice_ptp_auxbus_probe;
|
|
|
|
aux_driver->id_table = ice_ptp_auxbus_create_id_table(pf, name);
|
|
|
|
if (!aux_driver->id_table)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
err = auxiliary_driver_register(aux_driver);
|
|
|
|
if (err) {
|
|
|
|
devm_kfree(dev, aux_driver->id_table);
|
|
|
|
dev_err(dev, "Failed registering aux_driver, name <%s>\n",
|
|
|
|
name);
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_unregister_auxbus_driver - Unregister PTP auxiliary bus driver
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_unregister_auxbus_driver(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct auxiliary_driver *aux_driver = &pf->ptp.ports_owner.aux_driver;
|
|
|
|
|
|
|
|
auxiliary_driver_unregister(aux_driver);
|
|
|
|
devm_kfree(ice_pf_to_dev(pf), aux_driver->id_table);
|
|
|
|
|
|
|
|
mutex_destroy(&pf->ptp.ports_owner.lock);
|
|
|
|
}
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_prepare_for_reset - Prepare PTP for reset
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
void ice_ptp_prepare_for_reset(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
|
|
|
u8 src_tmr;
|
|
|
|
|
|
|
|
clear_bit(ICE_FLAG_PTP, pf->flags);
|
|
|
|
|
|
|
|
/* Disable timestamping for both Tx and Rx */
|
|
|
|
ice_ptp_cfg_timestamp(pf, false);
|
|
|
|
|
|
|
|
kthread_cancel_delayed_work_sync(&ptp->work);
|
|
|
|
|
|
|
|
if (test_bit(ICE_PFR_REQ, pf->state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ice_ptp_release_tx_tracker(pf, &pf->ptp.port.tx);
|
|
|
|
|
|
|
|
/* Disable periodic outputs */
|
|
|
|
ice_ptp_disable_all_clkout(pf);
|
|
|
|
|
|
|
|
src_tmr = ice_get_ptp_src_clock_index(&pf->hw);
|
|
|
|
|
|
|
|
/* Disable source clock */
|
|
|
|
wr32(&pf->hw, GLTSYN_ENA(src_tmr), (u32)~GLTSYN_ENA_TSYN_ENA_M);
|
|
|
|
|
|
|
|
/* Acquire PHC and system timer to restore after reset */
|
|
|
|
ptp->reset_time = ktime_get_real_ns();
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_init_owner - Initialize PTP_1588_CLOCK device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Setup and initialize a PTP clock device that represents the device hardware
|
|
|
|
* clock. Save the clock index for other functions connected to the same
|
|
|
|
* hardware resource.
|
|
|
|
*/
|
|
|
|
static int ice_ptp_init_owner(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
struct timespec64 ts;
|
2021-10-13 08:54:51 -07:00
|
|
|
int err, itr = 1;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2021-10-13 08:52:29 -07:00
|
|
|
err = ice_ptp_init_phc(hw);
|
|
|
|
if (err) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "Failed to initialize PHC, err %d\n",
|
|
|
|
err);
|
|
|
|
return err;
|
|
|
|
}
|
2021-06-09 09:39:50 -07:00
|
|
|
|
|
|
|
/* Acquire the global hardware lock */
|
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
err = -EBUSY;
|
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write the increment time value to PHY and LAN */
|
2021-10-13 08:47:20 -07:00
|
|
|
err = ice_ptp_write_incval(hw, ice_base_incval(pf));
|
2021-06-09 09:39:50 -07:00
|
|
|
if (err) {
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
ts = ktime_to_timespec64(ktime_get_real());
|
|
|
|
/* Write the initial Time value to PHY and LAN */
|
|
|
|
err = ice_ptp_write_init(pf, &ts);
|
|
|
|
if (err) {
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release the global hardware lock */
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
if (pf->ptp.tx_interrupt_mode == ICE_PTP_TX_INTERRUPT_ALL) {
|
|
|
|
/* The clock owner for this device type handles the timestamp
|
|
|
|
* interrupt for all ports.
|
|
|
|
*/
|
|
|
|
ice_ptp_configure_tx_tstamp(pf, true);
|
|
|
|
|
|
|
|
/* React on all quads interrupts for E82x */
|
|
|
|
wr32(hw, PFINT_TSYN_MSK + (0x4 * hw->pf_id), (u32)0x1f);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/* Enable quad interrupts */
|
|
|
|
err = ice_ptp_tx_ena_intr(pf, true, itr);
|
|
|
|
if (err)
|
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/* Ensure we have a clock device */
|
|
|
|
err = ice_ptp_create_clock(pf);
|
|
|
|
if (err)
|
|
|
|
goto err_clk;
|
|
|
|
|
2021-06-09 09:39:51 -07:00
|
|
|
/* Store the PTP clock index for other PFs */
|
|
|
|
ice_set_ptp_clock_index(pf);
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
err = ice_ptp_register_auxbus_driver(pf);
|
|
|
|
if (err) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "Failed to register PTP auxbus driver");
|
|
|
|
goto err_aux;
|
|
|
|
}
|
2021-06-09 09:39:50 -07:00
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
return 0;
|
|
|
|
err_aux:
|
|
|
|
ice_clear_ptp_clock_index(pf);
|
|
|
|
ptp_clock_unregister(pf->ptp.clock);
|
2021-06-09 09:39:50 -07:00
|
|
|
err_clk:
|
|
|
|
pf->ptp.clock = NULL;
|
|
|
|
err_exit:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_init_work - Initialize PTP work threads
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ptp: PF PTP structure
|
|
|
|
*/
|
|
|
|
static int ice_ptp_init_work(struct ice_pf *pf, struct ice_ptp *ptp)
|
|
|
|
{
|
|
|
|
struct kthread_worker *kworker;
|
|
|
|
|
|
|
|
/* Initialize work functions */
|
|
|
|
kthread_init_delayed_work(&ptp->work, ice_ptp_periodic_work);
|
|
|
|
|
|
|
|
/* Allocate a kworker for handling work required for the ports
|
|
|
|
* connected to the PTP hardware clock.
|
|
|
|
*/
|
|
|
|
kworker = kthread_create_worker(0, "ice-ptp-%s",
|
|
|
|
dev_name(ice_pf_to_dev(pf)));
|
|
|
|
if (IS_ERR(kworker))
|
|
|
|
return PTR_ERR(kworker);
|
|
|
|
|
|
|
|
ptp->kworker = kworker;
|
|
|
|
|
|
|
|
/* Start periodic work going */
|
|
|
|
kthread_queue_delayed_work(ptp->kworker, &ptp->work, 0);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_init_port - Initialize PTP port structure
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @ptp_port: PTP port structure
|
|
|
|
*/
|
|
|
|
static int ice_ptp_init_port(struct ice_pf *pf, struct ice_ptp_port *ptp_port)
|
|
|
|
{
|
2023-07-17 15:17:13 -07:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
mutex_init(&ptp_port->ps_lock);
|
|
|
|
|
2023-07-17 15:17:13 -07:00
|
|
|
switch (hw->phy_model) {
|
|
|
|
case ICE_PHY_E810:
|
2021-10-13 08:54:51 -07:00
|
|
|
return ice_ptp_init_tx_e810(pf, &ptp_port->tx);
|
2023-07-17 15:17:13 -07:00
|
|
|
case ICE_PHY_E822:
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
/* Non-owner PFs don't react to any interrupts on E82x,
|
|
|
|
* neither on own quad nor on others
|
|
|
|
*/
|
|
|
|
if (!ice_ptp_pf_handles_tx_interrupt(pf)) {
|
|
|
|
ice_ptp_configure_tx_tstamp(pf, false);
|
|
|
|
wr32(hw, PFINT_TSYN_MSK + (0x4 * hw->pf_id), (u32)0x0);
|
|
|
|
}
|
2023-07-17 15:17:13 -07:00
|
|
|
kthread_init_delayed_work(&ptp_port->ov_work,
|
|
|
|
ice_ptp_wait_for_offsets);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2023-07-17 15:17:13 -07:00
|
|
|
return ice_ptp_init_tx_e822(pf, &ptp_port->tx,
|
|
|
|
ptp_port->port_num);
|
|
|
|
default:
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_release_auxbus_device
|
|
|
|
* @dev: device that utilizes the auxbus
|
|
|
|
*/
|
|
|
|
static void ice_ptp_release_auxbus_device(struct device *dev)
|
|
|
|
{
|
|
|
|
/* Doing nothing here, but handle to auxbux device must be satisfied */
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_create_auxbus_device - Create PTP auxiliary bus device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static int ice_ptp_create_auxbus_device(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct auxiliary_device *aux_dev;
|
|
|
|
struct ice_ptp *ptp;
|
|
|
|
struct device *dev;
|
|
|
|
char *name;
|
|
|
|
int err;
|
|
|
|
u32 id;
|
|
|
|
|
|
|
|
ptp = &pf->ptp;
|
|
|
|
id = ptp->port.port_num;
|
|
|
|
dev = ice_pf_to_dev(pf);
|
|
|
|
|
|
|
|
aux_dev = &ptp->port.aux_dev;
|
|
|
|
|
|
|
|
name = devm_kasprintf(dev, GFP_KERNEL, "ptp_aux_dev_%u_%u_clk%u",
|
|
|
|
pf->pdev->bus->number, PCI_SLOT(pf->pdev->devfn),
|
|
|
|
ice_get_ptp_src_clock_index(&pf->hw));
|
|
|
|
|
|
|
|
aux_dev->name = name;
|
|
|
|
aux_dev->id = id;
|
|
|
|
aux_dev->dev.release = ice_ptp_release_auxbus_device;
|
|
|
|
aux_dev->dev.parent = dev;
|
|
|
|
|
|
|
|
err = auxiliary_device_init(aux_dev);
|
|
|
|
if (err)
|
|
|
|
goto aux_err;
|
|
|
|
|
|
|
|
err = auxiliary_device_add(aux_dev);
|
|
|
|
if (err) {
|
|
|
|
auxiliary_device_uninit(aux_dev);
|
|
|
|
goto aux_err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
aux_err:
|
|
|
|
dev_err(dev, "Failed to create PTP auxiliary bus device <%s>\n", name);
|
|
|
|
devm_kfree(dev, name);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_remove_auxbus_device - Remove PTP auxiliary bus device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_remove_auxbus_device(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct auxiliary_device *aux_dev = &pf->ptp.port.aux_dev;
|
|
|
|
|
|
|
|
auxiliary_device_delete(aux_dev);
|
|
|
|
auxiliary_device_uninit(aux_dev);
|
|
|
|
|
|
|
|
memset(aux_dev, 0, sizeof(*aux_dev));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_init_tx_interrupt_mode - Initialize device Tx interrupt mode
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Initialize the Tx timestamp interrupt mode for this device. For most device
|
|
|
|
* types, each PF processes the interrupt and manages its own timestamps. For
|
|
|
|
* E822-based devices, only the clock owner processes the timestamps. Other
|
|
|
|
* PFs disable the interrupt and do not process their own timestamps.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_init_tx_interrupt_mode(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
switch (pf->hw.phy_model) {
|
|
|
|
case ICE_PHY_E822:
|
|
|
|
/* E822 based PHY has the clock owner process the interrupt
|
|
|
|
* for all ports.
|
|
|
|
*/
|
|
|
|
if (ice_pf_src_tmr_owned(pf))
|
|
|
|
pf->ptp.tx_interrupt_mode = ICE_PTP_TX_INTERRUPT_ALL;
|
|
|
|
else
|
|
|
|
pf->ptp.tx_interrupt_mode = ICE_PTP_TX_INTERRUPT_NONE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* other PHY types handle their own Tx interrupt */
|
|
|
|
pf->ptp.tx_interrupt_mode = ICE_PTP_TX_INTERRUPT_SELF;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
/**
|
2021-10-13 08:52:29 -07:00
|
|
|
* ice_ptp_init - Initialize PTP hardware clock support
|
2021-06-09 09:39:50 -07:00
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
2021-10-13 08:52:29 -07:00
|
|
|
* Set up the device for interacting with the PTP hardware clock for all
|
|
|
|
* functions, both the function that owns the clock hardware, and the
|
|
|
|
* functions connected to the clock hardware.
|
|
|
|
*
|
|
|
|
* The clock owner will allocate and register a ptp_clock with the
|
|
|
|
* PTP_1588_CLOCK infrastructure. All functions allocate a kthread and work
|
|
|
|
* items used for asynchronous work such as Tx timestamps and periodic work.
|
2021-06-09 09:39:50 -07:00
|
|
|
*/
|
|
|
|
void ice_ptp_init(struct ice_pf *pf)
|
|
|
|
{
|
2021-12-20 08:58:27 -08:00
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
2021-06-09 09:39:50 -07:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
int err;
|
|
|
|
|
2023-07-17 15:17:13 -07:00
|
|
|
ice_ptp_init_phy_model(hw);
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
ice_ptp_init_tx_interrupt_mode(pf);
|
|
|
|
|
2021-10-13 08:52:29 -07:00
|
|
|
/* If this function owns the clock hardware, it must allocate and
|
|
|
|
* configure the PTP clock device to represent it.
|
|
|
|
*/
|
2023-09-08 14:37:14 -07:00
|
|
|
if (ice_pf_src_tmr_owned(pf)) {
|
2021-06-09 09:39:50 -07:00
|
|
|
err = ice_ptp_init_owner(pf);
|
|
|
|
if (err)
|
2021-12-20 08:58:27 -08:00
|
|
|
goto err;
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
ptp->port.port_num = hw->pf_id;
|
|
|
|
err = ice_ptp_init_port(pf, &ptp->port);
|
2021-12-20 08:58:27 -08:00
|
|
|
if (err)
|
|
|
|
goto err;
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
/* Start the PHY timestamping block */
|
|
|
|
ice_ptp_reset_phy_timestamping(pf);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
set_bit(ICE_FLAG_PTP, pf->flags);
|
2021-12-20 08:58:27 -08:00
|
|
|
err = ice_ptp_init_work(pf, ptp);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
err = ice_ptp_create_auxbus_device(pf);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
dev_info(ice_pf_to_dev(pf), "PTP init successful\n");
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
return;
|
|
|
|
|
2021-12-20 08:58:27 -08:00
|
|
|
err:
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/* If we registered a PTP clock, release it */
|
|
|
|
if (pf->ptp.clock) {
|
2021-12-20 08:58:27 -08:00
|
|
|
ptp_clock_unregister(ptp->clock);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
pf->ptp.clock = NULL;
|
|
|
|
}
|
2021-12-20 08:58:27 -08:00
|
|
|
clear_bit(ICE_FLAG_PTP, pf->flags);
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP failed %d\n", err);
|
2021-06-09 09:39:50 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_release - Disable the driver/HW support and unregister the clock
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* This function handles the cleanup work required from the initialization by
|
|
|
|
* clearing out the important information and unregistering the clock
|
|
|
|
*/
|
|
|
|
void ice_ptp_release(struct ice_pf *pf)
|
|
|
|
{
|
2021-10-11 15:02:16 +08:00
|
|
|
if (!test_bit(ICE_FLAG_PTP, pf->flags))
|
|
|
|
return;
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
/* Disable timestamping for both Tx and Rx */
|
|
|
|
ice_ptp_cfg_timestamp(pf, false);
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
ice_ptp_remove_auxbus_device(pf);
|
|
|
|
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
ice_ptp_release_tx_tracker(pf, &pf->ptp.port.tx);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
clear_bit(ICE_FLAG_PTP, pf->flags);
|
|
|
|
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
kthread_cancel_delayed_work_sync(&pf->ptp.work);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
ice_ptp_port_phy_stop(&pf->ptp.port);
|
|
|
|
mutex_destroy(&pf->ptp.port.ps_lock);
|
ice: enable receive hardware timestamping
Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
requests to enable timestamping support. If the request is for enabling
Rx timestamps, set a bit in the Rx descriptors to indicate that receive
timestamps should be reported.
Hardware captures receive timestamps in the PHY which only captures part
of the timer, and reports only 40 bits into the Rx descriptor. The upper
32 bits represent the contents of GLTSYN_TIME_L at the point of packet
reception, while the lower 8 bits represent the upper 8 bits of
GLTSYN_TIME_0.
The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
support this, implement some logic to extend the timestamps by using the
full PHC time.
If the Rx timestamp was captured prior to the PHC time, then the real
timestamp is
PHC - (lower_32_bits(PHC) - timestamp)
If the Rx timestamp was captured after the PHC time, then the real
timestamp is
PHC + (timestamp - lower_32_bits(PHC))
These calculations are correct as long as neither the PHC timestamp nor
the Rx timestamps are more than 2^32-1 nanseconds old. Further, we can
detect when the Rx timestamp is before or after the PHC as long as the
PHC timestamp is no more than 2^31-1 nanoseconds old.
In that case, we calculate the delta between the lower 32 bits of the
PHC and the Rx timestamp. If it's larger than 2^31-1 then the Rx
timestamp must have been captured in the past. If it's smaller, then the
Rx timestamp must have been captured after PHC time.
Add an ice_ptp_extend_32b_ts function that relies on a cached copy of
the PHC time and implements this algorithm to calculate the proper upper
32bits of the Rx timestamps.
Cache the PHC time periodically in all of the Rx rings. This enables
each Rx ring to simply call the extension function with a recent copy of
the PHC time. By ensuring that the PHC time is kept up to date
periodically, we ensure this algorithm doesn't use stale data and
produce incorrect results.
To cache the time, introduce a kworker and a kwork item to periodically
store the Rx time. It might seem like we should use the .do_aux_work
interface of the PTP clock. This doesn't work because all PFs must cache
this time, but only one PF owns the PTP clock device.
Thus, the ice driver will manage its own kthread instead of relying on
the PTP do_aux_work handler.
With this change, the driver can now report Rx timestamps on all
incoming packets.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:52 -07:00
|
|
|
if (pf->ptp.kworker) {
|
|
|
|
kthread_destroy_worker(pf->ptp.kworker);
|
|
|
|
pf->ptp.kworker = NULL;
|
|
|
|
}
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
if (!pf->ptp.clock)
|
|
|
|
return;
|
|
|
|
|
2021-08-23 17:01:49 -07:00
|
|
|
/* Disable periodic outputs */
|
|
|
|
ice_ptp_disable_all_clkout(pf);
|
|
|
|
|
2021-06-09 09:39:51 -07:00
|
|
|
ice_clear_ptp_clock_index(pf);
|
2021-06-09 09:39:50 -07:00
|
|
|
ptp_clock_unregister(pf->ptp.clock);
|
|
|
|
pf->ptp.clock = NULL;
|
|
|
|
|
ice: Auxbus devices & driver for E822 TS
There is a problem in HW in E822-based devices leading to race
condition.
It might happen that, in order:
- PF0 (which owns the PHC) requests few timestamps,
- PF1 requests a timestamp,
- interrupt is being triggered and both PF0 and PF1 threads are woken
up,
- PF0 got one timestamp, still waiting for others so not going to sleep,
- PF1 gets it's timestamp, process it and go to sleep,
- PF1 requests a timestamp again,
- just before PF0 goes to sleep timestamp of PF1 appear,
- PF0 finishes all it's timestamps and go to sleep (PF1 also sleeping).
That leaves PF1 timestamp memory not read, which lead to blocking the
next interrupt from arriving.
Fix it by adding auxiliary devices and only one driver to handle all the
timestamps for all PF's by PHC owner. In the past each PF requested it's
own timestamps and process it from the start till the end which causes
problem described above. Currently each PF requests the timestamps as
before, but the actual reading of the completed timestamps is being done
by the PTP auxiliary driver, which is registered by the PF which owns PHC.
Additionally, the newly introduced auxiliary driver/devices for PTP clock
owner will be used for other features in all products (including E810).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Signed-off-by: Michal Michalik <michal.michalik@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-07-27 15:50:34 +02:00
|
|
|
ice_ptp_unregister_auxbus_driver(pf);
|
|
|
|
|
2021-06-09 09:39:50 -07:00
|
|
|
dev_info(ice_pf_to_dev(pf), "Removed PTP clock\n");
|
|
|
|
}
|