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-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++) {
|
2023-10-17 12:04:03 -07:00
|
|
|
strscpy(ptp_pins[i].name, ice_pin_desc_e810t[i].name,
|
|
|
|
sizeof(ptp_pins[i].name));
|
2021-08-17 13:09:18 +02:00
|
|
|
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
|
|
|
/**
|
2023-11-21 13:12:56 -08:00
|
|
|
* ice_ptp_cfg_tx_interrupt - Configure Tx timestamp interrupt for the device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Program the device to respond appropriately to the Tx timestamp interrupt
|
|
|
|
* cause.
|
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
|
|
|
*/
|
2023-11-21 13:12:56 -08:00
|
|
|
static void ice_ptp_cfg_tx_interrupt(struct ice_pf *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
|
|
|
{
|
2023-11-21 13:12:56 -08:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
bool enable;
|
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
|
|
|
u32 val;
|
|
|
|
|
2023-11-21 13:12:56 -08:00
|
|
|
switch (pf->ptp.tx_interrupt_mode) {
|
|
|
|
case ICE_PTP_TX_INTERRUPT_ALL:
|
|
|
|
/* React to interrupts across all quads. */
|
|
|
|
wr32(hw, PFINT_TSYN_MSK + (0x4 * hw->pf_id), (u32)0x1f);
|
|
|
|
enable = true;
|
|
|
|
break;
|
|
|
|
case ICE_PTP_TX_INTERRUPT_NONE:
|
|
|
|
/* Do not react to interrupts on any quad. */
|
|
|
|
wr32(hw, PFINT_TSYN_MSK + (0x4 * hw->pf_id), (u32)0x0);
|
|
|
|
enable = false;
|
|
|
|
break;
|
|
|
|
case ICE_PTP_TX_INTERRUPT_SELF:
|
|
|
|
default:
|
|
|
|
enable = pf->ptp.tstamp_config.tx_type == HWTSTAMP_TX_ON;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* Configure the Tx timestamp interrupt */
|
2023-11-21 13:12:56 -08:00
|
|
|
val = rd32(hw, PFINT_OICR_ENA);
|
|
|
|
if (enable)
|
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
|
|
|
val |= PFINT_OICR_TSYN_TX_M;
|
|
|
|
else
|
|
|
|
val &= ~PFINT_OICR_TSYN_TX_M;
|
2023-11-21 13:12:56 -08:00
|
|
|
wr32(hw, PFINT_OICR_ENA, val);
|
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: 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);
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
if (!vsi || !vsi->rx_rings)
|
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;
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_disable_timestamp_mode - Disable current timestamp mode
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Called during preparation for reset to temporarily disable timestamping on
|
|
|
|
* the device. Called during remove to disable timestamping while cleaning up
|
|
|
|
* driver resources.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_disable_timestamp_mode(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
val = rd32(hw, PFINT_OICR_ENA);
|
|
|
|
val &= ~PFINT_OICR_TSYN_TX_M;
|
|
|
|
wr32(hw, PFINT_OICR_ENA, val);
|
2021-10-13 08:48:13 -07:00
|
|
|
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
ice_set_rx_tstamp(pf, false);
|
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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
* ice_ptp_restore_timestamp_mode - Restore timestamp configuration
|
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: Board private structure
|
|
|
|
*
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
* Called at the end of rebuild to restore timestamp configuration after
|
|
|
|
* a device reset.
|
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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
void ice_ptp_restore_timestamp_mode(struct ice_pf *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
|
|
|
{
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
bool enable_rx;
|
|
|
|
|
|
|
|
ice_ptp_cfg_tx_interrupt(pf);
|
|
|
|
|
|
|
|
enable_rx = pf->ptp.tstamp_config.rx_filter == HWTSTAMP_FILTER_ALL;
|
|
|
|
ice_set_rx_tstamp(pf, enable_rx);
|
|
|
|
|
|
|
|
/* Trigger an immediate software interrupt to ensure that timestamps
|
|
|
|
* which occurred during reset are handled now.
|
|
|
|
*/
|
|
|
|
wr32(hw, PFINT_OICR, PFINT_OICR_TSYN_TX_M);
|
|
|
|
ice_flush(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
|
|
|
}
|
|
|
|
|
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);
|
ice: avoid the PTP hardware semaphore in gettimex64 path
The PTP hardware semaphore (PFTSYN_SEM) is used to synchronize
operations that program the PTP timers. The operations involve issuing
commands to the sideband queue. The E810 does not have a hardware
sideband queue, so the admin queue is used. The admin queue is slow.
I have observed delays in hundreds of milliseconds waiting for
ice_sq_done.
When phc2sys reads the time from the ice PTP clock and PFTSYN_SEM is
held by a task performing one of the slow operations, ice_ptp_lock can
easily time out. phc2sys gets -EBUSY and the kernel prints:
ice 0000:XX:YY.0: PTP failed to get time
These messages appear once every few seconds, causing log spam.
The E810 datasheet recommends an algorithm for reading the upper 64 bits
of the GLTSYN_TIME register. It matches what's implemented in
ice_ptp_read_src_clk_reg. It is robust against wrap-around, but not
necessarily against the concurrent setting of the register (with
GLTSYN_CMD_{INIT,ADJ}_TIME commands). Perhaps that's why
ice_ptp_gettimex64 also takes PFTSYN_SEM.
The race with time setters can be prevented without relying on the PTP
hardware semaphore. Using the "ice_adapter" from the previous patch,
we can have a common spinlock for the PFs that share the clock hardware.
It will protect the reading and writing to the GLTSYN_TIME register.
The writing is performed indirectly, by the hardware, as a result of
the driver writing GLTSYN_CMD_SYNC in ice_ptp_exec_tmr_cmd. I wasn't
sure if the ice_flush there is enough to make sure GLTSYN_TIME has been
updated, but it works well in my testing.
My test code can be seen here:
https://gitlab.com/mschmidt2/linux/-/commits/ice-ptp-host-side-lock-10
It consists of:
- kernel threads reading the time in a busy loop and looking at the
deltas between consecutive values, reporting new maxima.
- a shell script that sets the time repeatedly;
- a bpftrace probe to produce a histogram of the measured deltas.
Without the spinlock ptp_gltsyn_time_lock, it is easy to see tearing.
Deltas in the [2G, 4G) range appear in the histograms.
With the spinlock added, there is no tearing and the biggest delta I saw
was in the range [1M, 2M), that is under 2 ms.
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.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>
2024-03-26 00:20:38 +01:00
|
|
|
guard(spinlock)(&pf->adapter->ptp_gltsyn_time_lock);
|
2021-06-09 09:39:50 -07:00
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
2023-11-29 13:40:23 +01:00
|
|
|
/**
|
|
|
|
* ice_ptp_req_tx_single_tstamp - Request Tx timestamp for a port from FW
|
|
|
|
* @tx: the PTP Tx timestamp tracker
|
|
|
|
* @idx: index of the timestamp to request
|
|
|
|
*/
|
|
|
|
void ice_ptp_req_tx_single_tstamp(struct ice_ptp_tx *tx, u8 idx)
|
|
|
|
{
|
|
|
|
struct ice_ptp_port *ptp_port;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
struct ice_pf *pf;
|
|
|
|
|
|
|
|
if (!tx->init)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ptp_port = container_of(tx, struct ice_ptp_port, tx);
|
|
|
|
pf = ptp_port_to_pf(ptp_port);
|
|
|
|
|
|
|
|
/* Drop packets which have waited for more than 2 seconds */
|
|
|
|
if (time_is_before_jiffies(tx->tstamps[idx].start + 2 * HZ)) {
|
|
|
|
/* Count the number of Tx timestamps that timed out */
|
|
|
|
pf->ptp.tx_hwtstamp_timeouts++;
|
|
|
|
|
|
|
|
skb = tx->tstamps[idx].skb;
|
|
|
|
tx->tstamps[idx].skb = NULL;
|
|
|
|
clear_bit(idx, tx->in_use);
|
|
|
|
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ice_trace(tx_tstamp_fw_req, tx->tstamps[idx].skb, idx);
|
|
|
|
|
|
|
|
/* Write TS index to read to the PF register so the FW can read it */
|
|
|
|
wr32(&pf->hw, PF_SB_ATQBAL,
|
|
|
|
TS_LL_READ_TS_INTR | FIELD_PREP(TS_LL_READ_TS_IDX, idx) |
|
|
|
|
TS_LL_READ_TS);
|
|
|
|
tx->last_ll_ts_idx_read = idx;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_complete_tx_single_tstamp - Complete Tx timestamp for a port
|
|
|
|
* @tx: the PTP Tx timestamp tracker
|
|
|
|
*/
|
|
|
|
void ice_ptp_complete_tx_single_tstamp(struct ice_ptp_tx *tx)
|
|
|
|
{
|
|
|
|
struct skb_shared_hwtstamps shhwtstamps = {};
|
|
|
|
u8 idx = tx->last_ll_ts_idx_read;
|
|
|
|
struct ice_ptp_port *ptp_port;
|
|
|
|
u64 raw_tstamp, tstamp;
|
|
|
|
bool drop_ts = false;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
struct ice_pf *pf;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
if (!tx->init || tx->last_ll_ts_idx_read < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ptp_port = container_of(tx, struct ice_ptp_port, tx);
|
|
|
|
pf = ptp_port_to_pf(ptp_port);
|
|
|
|
|
|
|
|
ice_trace(tx_tstamp_fw_done, tx->tstamps[idx].skb, idx);
|
|
|
|
|
|
|
|
val = rd32(&pf->hw, PF_SB_ATQBAL);
|
|
|
|
|
|
|
|
/* When the bit is cleared, the TS is ready in the register */
|
|
|
|
if (val & TS_LL_READ_TS) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "Failed to get the Tx tstamp - FW not ready");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* High 8 bit value of the TS is on the bits 16:23 */
|
|
|
|
raw_tstamp = FIELD_GET(TS_LL_READ_TS_HIGH, val);
|
|
|
|
raw_tstamp <<= 32;
|
|
|
|
|
|
|
|
/* Read the low 32 bit value */
|
|
|
|
raw_tstamp |= (u64)rd32(&pf->hw, PF_SB_ATQBAH);
|
|
|
|
|
2024-01-25 13:57:52 -08:00
|
|
|
/* Devices using this interface always verify the timestamp differs
|
|
|
|
* relative to the last cached timestamp value.
|
2023-11-29 13:40:23 +01:00
|
|
|
*/
|
2024-01-25 13:57:52 -08:00
|
|
|
if (raw_tstamp == tx->tstamps[idx].cached_tstamp)
|
2023-11-29 13:40:23 +01:00
|
|
|
return;
|
|
|
|
|
2024-01-25 13:57:52 -08:00
|
|
|
tx->tstamps[idx].cached_tstamp = raw_tstamp;
|
2023-11-29 13:40:23 +01:00
|
|
|
clear_bit(idx, tx->in_use);
|
|
|
|
skb = tx->tstamps[idx].skb;
|
|
|
|
tx->tstamps[idx].skb = NULL;
|
|
|
|
if (test_and_clear_bit(idx, tx->stale))
|
|
|
|
drop_ts = true;
|
|
|
|
|
|
|
|
if (!skb)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (drop_ts) {
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
}
|
|
|
|
|
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;
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
2022-07-27 16:16:01 -07:00
|
|
|
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 */
|
2024-01-25 13:57:52 -08:00
|
|
|
if (tx->has_ready_bitmap) {
|
|
|
|
err = ice_get_phy_tx_tstamp_ready(hw, tx->block, &tstamp_ready);
|
|
|
|
if (err)
|
|
|
|
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.
|
|
|
|
*/
|
2024-01-25 13:57:52 -08:00
|
|
|
if (tx->has_ready_bitmap &&
|
|
|
|
!(tstamp_ready & BIT_ULL(phy_idx))) {
|
2022-12-05 11:52:45 -08:00
|
|
|
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.
|
|
|
|
*/
|
2024-01-25 13:57:51 -08:00
|
|
|
if (!drop_ts && !tx->has_ready_bitmap &&
|
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:
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
2024-01-25 13:57:51 -08:00
|
|
|
if (!tx->has_ready_bitmap && 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;
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
2022-07-27 16:16:01 -07:00
|
|
|
|
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);
|
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
for (i = 0; i < ICE_GET_QUAD_NUM(pf->hw.ptp.num_lports); i++) {
|
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
|
|
|
u64 tstamp_ready;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Read the Tx ready status first */
|
|
|
|
err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);
|
2023-12-01 10:08:42 -08:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
else if (tstamp_ready)
|
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 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;
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
2023-06-01 14:15:05 -07:00
|
|
|
|
|
|
|
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 */
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
2022-12-05 11:52:46 -08:00
|
|
|
more_timestamps = tx->init && !bitmap_empty(tx->in_use, tx->len);
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
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;
|
2023-11-29 13:40:23 +01:00
|
|
|
tx->last_ll_ts_idx_read = -1;
|
2022-07-27 16:16:01 -07:00
|
|
|
|
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;
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
2022-12-05 11:52:51 -08:00
|
|
|
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
|
|
|
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
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);
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
2022-07-27 16:16:01 -07:00
|
|
|
|
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)
|
|
|
|
{
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
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_or(tx->stale, tx->stale, tx->in_use, tx->len);
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
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
|
|
|
}
|
|
|
|
|
2024-01-25 13:57:55 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_flush_all_tx_tracker - Flush all timestamp trackers on this clock
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Called by the clock owner to flush all the Tx timestamp trackers associated
|
|
|
|
* with the clock.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ice_ptp_flush_all_tx_tracker(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_ptp_port *port;
|
|
|
|
|
|
|
|
list_for_each_entry(port, &pf->ptp.ports_owner.ports, list_member)
|
|
|
|
ice_ptp_flush_tx_tracker(ptp_port_to_pf(port), &port->tx);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
2022-07-27 16:16:01 -07:00
|
|
|
tx->init = 0;
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
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;
|
|
|
|
}
|
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_init_tx_eth56g - 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. ETH56G PHYs
|
|
|
|
* have independent memory blocks for all ports.
|
|
|
|
*
|
|
|
|
* Return: 0 for success, -ENOMEM when failed to allocate Tx tracker
|
|
|
|
*/
|
|
|
|
static int ice_ptp_init_tx_eth56g(struct ice_pf *pf, struct ice_ptp_tx *tx,
|
|
|
|
u8 port)
|
|
|
|
{
|
|
|
|
tx->block = port;
|
|
|
|
tx->offset = 0;
|
|
|
|
tx->len = INDEX_PER_PORT_ETH56G;
|
|
|
|
tx->has_ready_bitmap = 1;
|
|
|
|
|
|
|
|
return ice_ptp_alloc_tx_tracker(tx);
|
|
|
|
}
|
|
|
|
|
2022-07-27 16:16:01 -07:00
|
|
|
/**
|
2023-12-01 10:08:44 -08:00
|
|
|
* ice_ptp_init_tx_e82x - Initialize tracking for Tx timestamps
|
2022-07-27 16:16:01 -07:00
|
|
|
* @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
|
2023-12-01 10:08:44 -08:00
|
|
|
ice_ptp_init_tx_e82x(struct ice_pf *pf, struct ice_ptp_tx *tx, u8 port)
|
2022-07-27 16:16:01 -07:00
|
|
|
{
|
2024-05-28 16:03:51 -07:00
|
|
|
tx->block = ICE_GET_QUAD_NUM(port);
|
2023-12-01 10:08:44 -08:00
|
|
|
tx->offset = (port % ICE_PORTS_PER_QUAD) * INDEX_PER_PORT_E82X;
|
|
|
|
tx->len = INDEX_PER_PORT_E82X;
|
2024-01-25 13:57:51 -08:00
|
|
|
tx->has_ready_bitmap = 1;
|
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.
|
|
|
|
*/
|
2024-01-25 13:57:51 -08:00
|
|
|
tx->has_ready_bitmap = 0;
|
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_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;
|
|
|
|
|
2024-05-28 16:03:56 -07:00
|
|
|
incval = ice_get_base_incval(hw);
|
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 offs = port->port_num % ICE_PORTS_PER_QUAD;
|
2024-05-28 16:03:51 -07:00
|
|
|
int quad = ICE_GET_QUAD_NUM(port->port_num);
|
2021-10-13 08:56:58 -07:00
|
|
|
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)
|
2023-12-01 10:08:44 -08:00
|
|
|
err = ice_read_quad_reg_e82x(hw, quad, Q_REG_FIFO01_STATUS,
|
2021-10-13 08:56:58 -07:00
|
|
|
&val);
|
|
|
|
else
|
2023-12-01 10:08:44 -08:00
|
|
|
err = ice_read_quad_reg_e82x(hw, quad, Q_REG_FIFO23_STATUS,
|
2021-10-13 08:56:58 -07:00
|
|
|
&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)
|
2023-12-05 17:01:12 -08:00
|
|
|
phy_sts = FIELD_GET(Q_REG_FIFO13_M, val);
|
2021-10-13 08:56:58 -07:00
|
|
|
else
|
2023-12-05 17:01:12 -08:00
|
|
|
phy_sts = FIELD_GET(Q_REG_FIFO02_M, val);
|
2021-10-13 08:56:58 -07:00
|
|
|
|
|
|
|
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);
|
2023-12-01 10:08:44 -08:00
|
|
|
ice_ptp_reset_ts_memory_quad_e82x(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)
|
2023-12-01 10:08:44 -08:00
|
|
|
tx_err = ice_phy_cfg_tx_offset_e82x(hw, port->port_num);
|
|
|
|
rx_err = ice_phy_cfg_rx_offset_e82x(hw, port->port_num);
|
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
|
|
|
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);
|
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
switch (hw->ptp.phy_model) {
|
|
|
|
case ICE_PHY_ETH56G:
|
|
|
|
err = ice_stop_phy_timer_eth56g(hw, port, true);
|
|
|
|
break;
|
|
|
|
case ICE_PHY_E82X:
|
|
|
|
kthread_cancel_delayed_work_sync(&ptp_port->ov_work);
|
2021-10-13 08:56:58 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
err = ice_stop_phy_timer_e82x(hw, port, true);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
err = -ENODEV;
|
|
|
|
}
|
|
|
|
if (err && err != -EBUSY)
|
2021-10-13 08:54:51 -07:00
|
|
|
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;
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
2021-10-13 08:54:51 -07:00
|
|
|
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);
|
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
switch (hw->ptp.phy_model) {
|
|
|
|
case ICE_PHY_ETH56G:
|
|
|
|
err = ice_start_phy_timer_eth56g(hw, port);
|
|
|
|
break;
|
|
|
|
case ICE_PHY_E82X:
|
|
|
|
/* Start the PHY timer in Vernier mode */
|
|
|
|
kthread_cancel_delayed_work_sync(&ptp_port->ov_work);
|
2021-10-13 08:56:58 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
/* temporarily disable Tx timestamps while calibrating
|
|
|
|
* PHY offset
|
|
|
|
*/
|
|
|
|
spin_lock_irqsave(&ptp_port->tx.lock, flags);
|
|
|
|
ptp_port->tx.calibrating = true;
|
|
|
|
spin_unlock_irqrestore(&ptp_port->tx.lock, flags);
|
|
|
|
ptp_port->tx_fifo_busy_cnt = 0;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
/* Start the PHY timer in Vernier mode */
|
|
|
|
err = ice_start_phy_timer_e82x(hw, port);
|
|
|
|
if (err)
|
|
|
|
break;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
/* Enable Tx timestamps right away */
|
|
|
|
spin_lock_irqsave(&ptp_port->tx.lock, flags);
|
|
|
|
ptp_port->tx.calibrating = false;
|
|
|
|
spin_unlock_irqrestore(&ptp_port->tx.lock, flags);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
kthread_queue_delayed_work(pf->ptp.kworker, &ptp_port->ov_work,
|
|
|
|
0);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
err = -ENODEV;
|
|
|
|
}
|
2021-10-13 08:56:58 -07:00
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
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
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
2022-12-05 11:52:43 -08:00
|
|
|
return;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
if (WARN_ON_ONCE(port >= hw->ptp.num_lports))
|
2022-12-05 11:52:43 -08:00
|
|
|
return;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
|
|
|
ptp_port = &pf->ptp.port;
|
2024-05-28 16:04:01 -07:00
|
|
|
if (ice_is_e825c(hw) && hw->ptp.is_2x50g_muxed_topo)
|
|
|
|
port *= 2;
|
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;
|
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
switch (hw->ptp.phy_model) {
|
2023-07-17 15:17:13 -07:00
|
|
|
case ICE_PHY_E810:
|
|
|
|
/* Do not reconfigure E810 PHY */
|
2022-12-05 11:52:43 -08:00
|
|
|
return;
|
2024-05-28 16:03:57 -07:00
|
|
|
case ICE_PHY_ETH56G:
|
2023-12-01 10:08:44 -08:00
|
|
|
case ICE_PHY_E82X:
|
2023-07-17 15:17:13 -07:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2024-01-25 13:57:53 -08:00
|
|
|
* ice_ptp_cfg_phy_interrupt - Configure PHY interrupt settings
|
2021-10-13 08:54:51 -07:00
|
|
|
* @pf: PF private structure
|
|
|
|
* @ena: bool value to enable or disable interrupt
|
|
|
|
* @threshold: Minimum number of packets at which intr is triggered
|
|
|
|
*
|
2024-05-28 16:03:53 -07:00
|
|
|
* Utility function to configure all the PHY interrupt settings, including
|
|
|
|
* whether the PHY interrupt is enabled, and what threshold to use. Also
|
|
|
|
* configures The E82X timestamp owner to react to interrupts from all PHYs.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, -EOPNOTSUPP when PHY model incorrect, other error codes
|
|
|
|
* when failed to configure PHY interrupt for E82X
|
2021-10-13 08:54:51 -07:00
|
|
|
*/
|
2024-01-25 13:57:53 -08:00
|
|
|
static int ice_ptp_cfg_phy_interrupt(struct ice_pf *pf, bool ena, u32 threshold)
|
2021-10-13 08:54:51 -07:00
|
|
|
{
|
2024-05-28 16:03:53 -07:00
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
2021-10-13 08:54:51 -07:00
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2022-12-05 11:52:41 -08:00
|
|
|
ice_ptp_reset_ts_memory(hw);
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:53 -07:00
|
|
|
switch (hw->ptp.phy_model) {
|
2024-05-28 16:03:57 -07:00
|
|
|
case ICE_PHY_ETH56G: {
|
|
|
|
int port;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
for (port = 0; port < hw->ptp.num_lports; port++) {
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = ice_phy_cfg_intr_eth56g(hw, port, ena, threshold);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to configure PHY interrupt for port %d, err %d\n",
|
|
|
|
port, err);
|
|
|
|
return err;
|
|
|
|
}
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
|
|
|
|
2024-05-28 16:03:57 -07:00
|
|
|
return 0;
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
2024-05-28 16:03:53 -07:00
|
|
|
case ICE_PHY_E82X: {
|
|
|
|
int quad;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
2024-05-28 16:03:53 -07:00
|
|
|
for (quad = 0; quad < ICE_GET_QUAD_NUM(hw->ptp.num_lports);
|
|
|
|
quad++) {
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = ice_phy_cfg_intr_e82x(hw, quad, ena, threshold);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to configure PHY interrupt for quad %d, err %d\n",
|
|
|
|
quad, err);
|
|
|
|
return err;
|
|
|
|
}
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
|
|
|
|
2024-05-28 16:03:53 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
case ICE_PHY_E810:
|
|
|
|
return 0;
|
|
|
|
case ICE_PHY_UNSUP:
|
|
|
|
default:
|
|
|
|
dev_warn(dev, "%s: Unexpected PHY model %d\n", __func__,
|
|
|
|
hw->ptp.phy_model);
|
|
|
|
return -EOPNOTSUPP;
|
2021-10-13 08:54:51 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
|
2024-07-02 10:14:55 -07:00
|
|
|
/* Don't process timestamp events if PTP is not ready */
|
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
|
|
|
return;
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
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
|
|
|
|
* @chan: GPIO channel (0-3)
|
2024-07-02 10:14:54 -07:00
|
|
|
* @config: desired EXTTS configuration.
|
|
|
|
* @store: If set to true, the values will be stored
|
|
|
|
*
|
|
|
|
* Configure an external timestamp event on the requested channel.
|
2024-07-02 10:14:56 -07:00
|
|
|
*
|
|
|
|
* Return: 0 on success, -EOPNOTUSPP on unsupported flags
|
2021-06-16 09:35:22 -07:00
|
|
|
*/
|
2024-07-02 10:14:56 -07:00
|
|
|
static int ice_ptp_cfg_extts(struct ice_pf *pf, unsigned int chan,
|
|
|
|
struct ice_extts_channel *config, bool store)
|
2021-06-16 09:35:22 -07:00
|
|
|
{
|
|
|
|
u32 func, aux_reg, gpio_reg, irq_reg;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 tmr_idx;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
/* Reject requests with unsupported flags */
|
|
|
|
if (config->flags & ~(PTP_ENABLE_FEATURE |
|
|
|
|
PTP_RISING_EDGE |
|
|
|
|
PTP_FALLING_EDGE |
|
|
|
|
PTP_STRICT_FLAGS))
|
|
|
|
return -EOPNOTSUPP;
|
2021-06-16 09:35:22 -07:00
|
|
|
|
|
|
|
tmr_idx = hw->func_caps.ts_func_info.tmr_index_owned;
|
|
|
|
|
|
|
|
irq_reg = rd32(hw, PFINT_OICR_ENA);
|
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
if (config->ena) {
|
2021-06-16 09:35:22 -07:00
|
|
|
/* 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 */
|
2024-07-02 10:14:54 -07:00
|
|
|
if (config->flags & PTP_FALLING_EDGE)
|
2021-06-16 09:35:22 -07:00
|
|
|
aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE;
|
2024-07-02 10:14:54 -07:00
|
|
|
if (config->flags & PTP_RISING_EDGE)
|
2021-06-16 09:35:22 -07:00
|
|
|
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);
|
2023-12-05 17:01:05 -08:00
|
|
|
gpio_reg = FIELD_PREP(GLGEN_GPIO_CTL_PIN_FUNC_M, func);
|
2021-06-16 09:35:22 -07:00
|
|
|
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);
|
2024-07-02 10:14:54 -07:00
|
|
|
wr32(hw, GLGEN_GPIO_CTL(config->gpio_pin), gpio_reg);
|
2021-06-16 09:35:22 -07:00
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
if (store)
|
|
|
|
memcpy(&pf->ptp.extts_channels[chan], config, sizeof(*config));
|
2021-06-16 09:35:22 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
/**
|
|
|
|
* ice_ptp_disable_all_extts - Disable all EXTTS channels
|
|
|
|
* @pf: Board private structure
|
|
|
|
*/
|
|
|
|
static void ice_ptp_disable_all_extts(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct ice_extts_channel extts_cfg = {};
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < pf->ptp.info.n_ext_ts; i++) {
|
|
|
|
if (pf->ptp.extts_channels[i].ena) {
|
|
|
|
extts_cfg.gpio_pin = pf->ptp.extts_channels[i].gpio_pin;
|
|
|
|
extts_cfg.ena = false;
|
|
|
|
ice_ptp_cfg_extts(pf, i, &extts_cfg, false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
synchronize_irq(pf->oicr_irq.virq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_enable_all_extts - Enable all EXTTS channels
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Called during reset to restore user configuration.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_enable_all_extts(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < pf->ptp.info.n_ext_ts; i++) {
|
|
|
|
if (pf->ptp.extts_channels[i].ena)
|
|
|
|
ice_ptp_cfg_extts(pf, i, &pf->ptp.extts_channels[i],
|
|
|
|
false);
|
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
if (config && config->flags & ~PTP_PEROUT_PHASE)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
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)
|
2024-06-07 14:22:33 -07:00
|
|
|
start_time = roundup_u64(current_time, NSEC_PER_SEC) + phase;
|
2021-06-16 09:35:22 -07:00
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
if (ice_is_e810(hw))
|
|
|
|
start_time -= E810_OUT_PROP_DELAY_NS;
|
|
|
|
else
|
2023-12-01 10:08:44 -08:00
|
|
|
start_time -= ice_e82x_pps_delay(ice_e82x_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 |
|
2023-12-05 17:01:05 -08:00
|
|
|
FIELD_PREP(GLGEN_GPIO_CTL_PIN_FUNC_M, func);
|
2021-06-16 09:35:22 -07:00
|
|
|
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);
|
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;
|
|
|
|
|
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:
|
2024-07-02 10:14:54 -07:00
|
|
|
{
|
|
|
|
struct ice_perout_channel clk_cfg = {};
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
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
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
clk_cfg.flags = rq->perout.flags;
|
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;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
return ice_ptp_cfg_clkout(pf, chan, &clk_cfg, true);
|
2024-07-02 10:14:54 -07:00
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
case PTP_CLK_REQ_EXTTS:
|
2024-07-02 10:14:54 -07:00
|
|
|
{
|
|
|
|
struct ice_extts_channel extts_cfg = {};
|
|
|
|
|
2021-06-16 09:35:22 -07:00
|
|
|
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
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
extts_cfg.flags = rq->extts.flags;
|
|
|
|
extts_cfg.gpio_pin = gpio_pin;
|
|
|
|
extts_cfg.ena = !!on;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
return ice_ptp_cfg_extts(pf, chan, &extts_cfg, true);
|
2024-07-02 10:14:54 -07:00
|
|
|
}
|
2021-06-16 09:35:22 -07:00
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
switch (rq->type) {
|
|
|
|
case PTP_CLK_REQ_PPS:
|
2024-07-02 10:14:54 -07:00
|
|
|
{
|
|
|
|
struct ice_perout_channel clk_cfg = {};
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
clk_cfg.flags = rq->perout.flags;
|
2022-09-14 12:04:29 +02:00
|
|
|
clk_cfg.gpio_pin = PPS_PIN_INDEX;
|
|
|
|
clk_cfg.period = NSEC_PER_SEC;
|
|
|
|
clk_cfg.ena = !!on;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
return ice_ptp_cfg_clkout(pf, PPS_CLK_GEN_CHAN, &clk_cfg, true);
|
2024-07-02 10:14:54 -07:00
|
|
|
}
|
2022-09-14 12:04:29 +02:00
|
|
|
case PTP_CLK_REQ_EXTTS:
|
2024-07-02 10:14:54 -07:00
|
|
|
{
|
|
|
|
struct ice_extts_channel extts_cfg = {};
|
|
|
|
|
|
|
|
extts_cfg.flags = rq->extts.flags;
|
|
|
|
extts_cfg.gpio_pin = TIME_SYNC_PIN_INDEX;
|
|
|
|
extts_cfg.ena = !!on;
|
|
|
|
|
2024-07-02 10:14:56 -07:00
|
|
|
return ice_ptp_cfg_extts(pf, rq->extts.index, &extts_cfg, true);
|
2024-07-02 10:14:54 -07:00
|
|
|
}
|
2022-09-14 12:04:29 +02:00
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
2024-03-26 00:20:39 +01:00
|
|
|
u64 time_ns;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2024-03-26 00:20:39 +01:00
|
|
|
time_ns = ice_ptp_read_src_clk_reg(pf, sts);
|
|
|
|
*ts = ns_to_timespec64(time_ns);
|
2021-06-09 09:39:50 -07:00
|
|
|
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;
|
|
|
|
|
2024-05-28 16:03:54 -07:00
|
|
|
/* For Vernier mode on E82X, we need to recalibrate after new settime.
|
|
|
|
* Start with marking timestamps as invalid.
|
2021-10-13 08:54:51 -07:00
|
|
|
*/
|
2024-05-28 16:03:54 -07:00
|
|
|
if (hw->ptp.phy_model == ICE_PHY_E82X) {
|
|
|
|
err = ice_ptp_clear_phy_offset_ready_e82x(hw);
|
|
|
|
if (err)
|
|
|
|
dev_warn(ice_pf_to_dev(pf), "Failed to mark timestamps as invalid before settime\n");
|
|
|
|
}
|
2021-10-13 08:54:51 -07:00
|
|
|
|
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 */
|
2024-05-28 16:03:51 -07:00
|
|
|
if (hw->ptp.phy_model == ICE_PHY_E82X)
|
2023-07-27 15:50:35 +02:00
|
|
|
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;
|
2024-05-13 16:08:08 +05:30
|
|
|
system->cycles = hh_ts;
|
|
|
|
system->cs_id = CSID_X86_ART;
|
2021-10-13 09:00:08 -07:00
|
|
|
/* 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;
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
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 -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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
pf->ptp.tstamp_config.tx_type = 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
|
|
|
break;
|
|
|
|
case HWTSTAMP_TX_ON:
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
pf->ptp.tstamp_config.tx_type = HWTSTAMP_TX_ON;
|
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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
pf->ptp.tstamp_config.rx_filter = 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
|
|
|
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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
pf->ptp.tstamp_config.rx_filter = HWTSTAMP_FILTER_ALL;
|
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;
|
|
|
|
}
|
|
|
|
|
ice: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
/* Immediately update the device timestamping mode */
|
|
|
|
ice_ptp_restore_timestamp_mode(pf);
|
|
|
|
|
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;
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
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 -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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-12-05 22:08:31 +01:00
|
|
|
* ice_ptp_get_rx_hwts - Get packet Rx timestamp in 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
|
|
|
* @rx_desc: Receive descriptor
|
2023-12-05 22:08:34 +01:00
|
|
|
* @pkt_ctx: Packet context to get the 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
|
|
|
*
|
|
|
|
* The driver receives a notification in the receive descriptor with timestamp.
|
|
|
|
*/
|
2023-12-05 22:08:31 +01:00
|
|
|
u64 ice_ptp_get_rx_hwts(const union ice_32b_rx_flex_desc *rx_desc,
|
2023-12-05 22:08:34 +01:00
|
|
|
const struct ice_pkt_ctx *pkt_ctx)
|
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
|
|
|
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))
|
2023-12-05 22:08:31 +01: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
|
|
|
|
2023-12-05 22:08:34 +01:00
|
|
|
cached_time = READ_ONCE(pkt_ctx->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)
|
2023-12-05 22:08:31 +01:00
|
|
|
return 0;
|
2022-07-27 16:16:02 -07:00
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
2023-12-05 22:08:31 +01:00
|
|
|
return 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 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. */
|
2023-07-27 15:50:36 +02:00
|
|
|
pf->ptp.clock = ptp_clock_register(info, dev);
|
|
|
|
if (IS_ERR(pf->ptp.clock)) {
|
|
|
|
dev_err(ice_pf_to_dev(pf), "Failed to register PTP clock device");
|
|
|
|
return PTR_ERR(pf->ptp.clock);
|
|
|
|
}
|
2021-06-09 09:39:50 -07:00
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
2023-11-29 13:40:23 +01:00
|
|
|
unsigned long flags;
|
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
|
|
|
u8 idx;
|
|
|
|
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_lock_irqsave(&tx->lock, flags);
|
2022-12-05 11:52:47 -08:00
|
|
|
|
|
|
|
/* Check that this tracker is accepting new timestamp requests */
|
|
|
|
if (!ice_ptp_is_tx_tracker_up(tx)) {
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
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 */
|
2023-11-29 13:40:23 +01:00
|
|
|
idx = find_next_zero_bit(tx->in_use, tx->len,
|
|
|
|
tx->last_ll_ts_idx_read + 1);
|
|
|
|
if (idx == tx->len)
|
|
|
|
idx = find_first_zero_bit(tx->in_use, tx->len);
|
|
|
|
|
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 (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
|
|
|
}
|
|
|
|
|
2023-11-29 13:40:23 +01:00
|
|
|
spin_unlock_irqrestore(&tx->lock, flags);
|
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 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: periodically kick Tx timestamp interrupt
The E822 hardware for Tx timestamping keeps track of how many
outstanding timestamps are still in the PHY memory block. It will not
generate a new interrupt to the MAC until all of the timestamps in the
region have been read.
If somehow all the available data is not read, but the driver has exited
its interrupt routine already, the PHY will not generate a new interrupt
even if new timestamp data is captured. Because no interrupt is
generated, the driver never processes the timestamp data. This state
results in a permanent failure for all future Tx timestamps.
It is not clear how the driver and hardware could enter this state.
However, if it does, there is currently no recovery mechanism.
Add a recovery mechanism via the periodic PTP work thread which invokes
ice_ptp_periodic_work(). Introduce a new check,
ice_ptp_maybe_trigger_tx_interrupt() which checks the PHY timestamp
ready bitmask. If any bits are set, trigger a software interrupt by
writing to PFINT_OICR.
Once triggered, the main timestamp processing thread will read through
the PHY data and clear the outstanding timestamp data. Once cleared, new
data should trigger interrupts as expected.
This should allow recovery from such a state rather than leaving the
device in a state where we cannot process Tx timestamps.
It is possible that this function checks for timestamp data
simultaneously with the interrupt, and it might trigger additional
unnecessary interrupts. This will cause a small amount of additional
processing.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Reviewed-by: Andrii Staikov <andrii.staikov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-01 10:08:43 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_maybe_trigger_tx_interrupt - Trigger Tx timstamp interrupt
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* The device PHY issues Tx timestamp interrupts to the driver for processing
|
|
|
|
* timestamp data from the PHY. It will not interrupt again until all
|
|
|
|
* current timestamp data is read. In rare circumstances, it is possible that
|
|
|
|
* the driver fails to read all outstanding data.
|
|
|
|
*
|
|
|
|
* To avoid getting permanently stuck, periodically check if the PHY has
|
|
|
|
* outstanding timestamp data. If so, trigger an interrupt from software to
|
|
|
|
* process this data.
|
|
|
|
*/
|
|
|
|
static void ice_ptp_maybe_trigger_tx_interrupt(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
bool trigger_oicr = false;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (ice_is_e810(hw))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!ice_pf_src_tmr_owned(pf))
|
|
|
|
return;
|
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
for (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) {
|
ice: periodically kick Tx timestamp interrupt
The E822 hardware for Tx timestamping keeps track of how many
outstanding timestamps are still in the PHY memory block. It will not
generate a new interrupt to the MAC until all of the timestamps in the
region have been read.
If somehow all the available data is not read, but the driver has exited
its interrupt routine already, the PHY will not generate a new interrupt
even if new timestamp data is captured. Because no interrupt is
generated, the driver never processes the timestamp data. This state
results in a permanent failure for all future Tx timestamps.
It is not clear how the driver and hardware could enter this state.
However, if it does, there is currently no recovery mechanism.
Add a recovery mechanism via the periodic PTP work thread which invokes
ice_ptp_periodic_work(). Introduce a new check,
ice_ptp_maybe_trigger_tx_interrupt() which checks the PHY timestamp
ready bitmask. If any bits are set, trigger a software interrupt by
writing to PFINT_OICR.
Once triggered, the main timestamp processing thread will read through
the PHY data and clear the outstanding timestamp data. Once cleared, new
data should trigger interrupts as expected.
This should allow recovery from such a state rather than leaving the
device in a state where we cannot process Tx timestamps.
It is possible that this function checks for timestamp data
simultaneously with the interrupt, and it might trigger additional
unnecessary interrupts. This will cause a small amount of additional
processing.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Reviewed-by: Andrii Staikov <andrii.staikov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-01 10:08:43 -08:00
|
|
|
u64 tstamp_ready;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);
|
|
|
|
if (!err && tstamp_ready) {
|
|
|
|
trigger_oicr = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (trigger_oicr) {
|
|
|
|
/* Trigger a software interrupt, to ensure this data
|
|
|
|
* gets processed.
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "PTP periodic task detected waiting timestamps. Triggering Tx timestamp interrupt now.\n");
|
|
|
|
|
|
|
|
wr32(hw, PFINT_OICR, PFINT_OICR_TSYN_TX_M);
|
|
|
|
ice_flush(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
|
|
|
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
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
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;
|
|
|
|
|
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
|
|
|
|
ice: periodically kick Tx timestamp interrupt
The E822 hardware for Tx timestamping keeps track of how many
outstanding timestamps are still in the PHY memory block. It will not
generate a new interrupt to the MAC until all of the timestamps in the
region have been read.
If somehow all the available data is not read, but the driver has exited
its interrupt routine already, the PHY will not generate a new interrupt
even if new timestamp data is captured. Because no interrupt is
generated, the driver never processes the timestamp data. This state
results in a permanent failure for all future Tx timestamps.
It is not clear how the driver and hardware could enter this state.
However, if it does, there is currently no recovery mechanism.
Add a recovery mechanism via the periodic PTP work thread which invokes
ice_ptp_periodic_work(). Introduce a new check,
ice_ptp_maybe_trigger_tx_interrupt() which checks the PHY timestamp
ready bitmask. If any bits are set, trigger a software interrupt by
writing to PFINT_OICR.
Once triggered, the main timestamp processing thread will read through
the PHY data and clear the outstanding timestamp data. Once cleared, new
data should trigger interrupts as expected.
This should allow recovery from such a state rather than leaving the
device in a state where we cannot process Tx timestamps.
It is possible that this function checks for timestamp data
simultaneously with the interrupt, and it might trigger additional
unnecessary interrupts. This will cause a small amount of additional
processing.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
Reviewed-by: Andrii Staikov <andrii.staikov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-01 10:08:43 -08:00
|
|
|
ice_ptp_maybe_trigger_tx_interrupt(pf);
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
/**
|
|
|
|
* ice_ptp_prepare_for_reset - Prepare PTP for reset
|
|
|
|
* @pf: Board private structure
|
2024-01-25 13:57:50 -08:00
|
|
|
* @reset_type: the reset type being performed
|
2024-01-25 13:57:49 -08:00
|
|
|
*/
|
2024-01-25 13:57:50 -08:00
|
|
|
void ice_ptp_prepare_for_reset(struct ice_pf *pf, enum ice_reset_req reset_type)
|
2024-01-25 13:57:49 -08:00
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
|
|
|
u8 src_tmr;
|
|
|
|
|
|
|
|
if (ptp->state != ICE_PTP_READY)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ptp->state = ICE_PTP_RESETTING;
|
|
|
|
|
|
|
|
/* Disable timestamping for both Tx and Rx */
|
|
|
|
ice_ptp_disable_timestamp_mode(pf);
|
|
|
|
|
|
|
|
kthread_cancel_delayed_work_sync(&ptp->work);
|
|
|
|
|
2024-01-25 13:57:50 -08:00
|
|
|
if (reset_type == ICE_RESET_PFR)
|
2024-01-25 13:57:49 -08:00
|
|
|
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-12-20 08:58:27 -08:00
|
|
|
/**
|
2024-01-25 13:57:54 -08:00
|
|
|
* ice_ptp_rebuild_owner - Initialize PTP clock owner after reset
|
2021-12-20 08:58:27 -08:00
|
|
|
* @pf: Board private structure
|
2024-01-25 13:57:54 -08:00
|
|
|
*
|
|
|
|
* Companion function for ice_ptp_rebuild() which handles tasks that only the
|
|
|
|
* PTP clock owner instance should perform.
|
2021-12-20 08:58:27 -08:00
|
|
|
*/
|
2024-01-25 13:57:54 -08:00
|
|
|
static int ice_ptp_rebuild_owner(struct ice_pf *pf)
|
2021-12-20 08:58:27 -08:00
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
struct timespec64 ts;
|
|
|
|
u64 time_diff;
|
2024-01-25 13:57:53 -08:00
|
|
|
int err;
|
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)
|
2024-01-25 13:57:54 -08:00
|
|
|
return err;
|
2021-12-20 08:58:27 -08:00
|
|
|
|
|
|
|
/* Acquire the global hardware lock */
|
|
|
|
if (!ice_ptp_lock(hw)) {
|
|
|
|
err = -EBUSY;
|
2024-01-25 13:57:54 -08:00
|
|
|
return err;
|
2021-12-20 08:58:27 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
2024-01-25 13:57:54 -08:00
|
|
|
return err;
|
2021-12-20 08:58:27 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
2024-01-25 13:57:54 -08:00
|
|
|
return err;
|
2021-12-20 08:58:27 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Release the global hardware lock */
|
|
|
|
ice_ptp_unlock(hw);
|
|
|
|
|
2024-01-25 13:57:55 -08:00
|
|
|
/* Flush software tracking of any outstanding timestamps since we're
|
|
|
|
* about to flush the PHY timestamp block.
|
|
|
|
*/
|
|
|
|
ice_ptp_flush_all_tx_tracker(pf);
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
if (!ice_is_e810(hw)) {
|
|
|
|
/* Enable quad interrupts */
|
2024-01-25 13:57:53 -08:00
|
|
|
err = ice_ptp_cfg_phy_interrupt(pf, true, 1);
|
2024-01-25 13:57:54 -08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
ice_ptp_restart_all_phy(pf);
|
|
|
|
}
|
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
/* Re-enable all periodic outputs and external timestamp events */
|
|
|
|
ice_ptp_enable_all_clkout(pf);
|
|
|
|
ice_ptp_enable_all_extts(pf);
|
|
|
|
|
2024-01-25 13:57:54 -08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_ptp_rebuild - Initialize PTP hardware clock support after reset
|
|
|
|
* @pf: Board private structure
|
|
|
|
* @reset_type: the reset type being performed
|
|
|
|
*/
|
|
|
|
void ice_ptp_rebuild(struct ice_pf *pf, enum ice_reset_req reset_type)
|
|
|
|
{
|
|
|
|
struct ice_ptp *ptp = &pf->ptp;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (ptp->state == ICE_PTP_READY) {
|
|
|
|
ice_ptp_prepare_for_reset(pf, reset_type);
|
|
|
|
} else if (ptp->state != ICE_PTP_RESETTING) {
|
|
|
|
err = -EINVAL;
|
|
|
|
dev_err(ice_pf_to_dev(pf), "PTP was not initialized\n");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ice_pf_src_tmr_owned(pf) && reset_type != ICE_RESET_PFR) {
|
|
|
|
err = ice_ptp_rebuild_owner(pf);
|
2021-10-13 08:54:51 -07:00
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
ptp->state = ICE_PTP_READY;
|
2021-12-20 08:58:27 -08:00
|
|
|
|
|
|
|
/* 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:
|
2024-01-25 13:57:49 -08:00
|
|
|
ptp->state = ICE_PTP_ERROR;
|
2021-12-20 08:58:27 -08:00
|
|
|
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;
|
2024-06-11 15:01:04 +02:00
|
|
|
const struct auxiliary_driver *aux_drv;
|
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
|
|
|
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));
|
2023-12-12 10:40:15 +08:00
|
|
|
if (!name)
|
|
|
|
return -ENOMEM;
|
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
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2023-07-27 15:50:36 +02:00
|
|
|
/**
|
|
|
|
* ice_ptp_clock_index - Get the PTP clock index for this device
|
|
|
|
* @pf: Board private structure
|
|
|
|
*
|
|
|
|
* Returns: the PTP clock index associated with this PF, or -1 if no PTP clock
|
|
|
|
* is associated.
|
|
|
|
*/
|
|
|
|
int ice_ptp_clock_index(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct auxiliary_device *aux_dev;
|
|
|
|
struct ice_pf *owner_pf;
|
|
|
|
struct ptp_clock *clock;
|
|
|
|
|
|
|
|
aux_dev = &pf->ptp.port.aux_dev;
|
|
|
|
owner_pf = ice_ptp_aux_dev_to_owner_pf(aux_dev);
|
|
|
|
if (!owner_pf)
|
|
|
|
return -1;
|
|
|
|
clock = owner_pf->ptp.clock;
|
|
|
|
|
|
|
|
return clock ? ptp_clock_index(clock) : -1;
|
|
|
|
}
|
|
|
|
|
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;
|
2024-01-25 13:57:53 -08:00
|
|
|
int err;
|
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);
|
|
|
|
|
2024-05-28 16:03:53 -07:00
|
|
|
/* Configure PHY interrupt settings */
|
|
|
|
err = ice_ptp_cfg_phy_interrupt(pf, true, 1);
|
|
|
|
if (err)
|
|
|
|
goto err_exit;
|
2021-10-13 08:54:51 -07:00
|
|
|
|
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;
|
|
|
|
|
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:
|
|
|
|
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);
|
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
switch (hw->ptp.phy_model) {
|
2024-05-28 16:03:57 -07:00
|
|
|
case ICE_PHY_ETH56G:
|
|
|
|
return ice_ptp_init_tx_eth56g(pf, &ptp_port->tx,
|
|
|
|
ptp_port->port_num);
|
2023-07-17 15:17:13 -07:00
|
|
|
case ICE_PHY_E810:
|
2021-10-13 08:54:51 -07:00
|
|
|
return ice_ptp_init_tx_e810(pf, &ptp_port->tx);
|
2023-12-01 10:08:44 -08:00
|
|
|
case ICE_PHY_E82X:
|
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-12-01 10:08:44 -08:00
|
|
|
return ice_ptp_init_tx_e82x(pf, &ptp_port->tx,
|
2023-07-17 15:17:13 -07:00
|
|
|
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));
|
2023-12-12 10:40:15 +08:00
|
|
|
if (!name)
|
|
|
|
return -ENOMEM;
|
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
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
2024-05-28 16:03:51 -07:00
|
|
|
switch (pf->hw.ptp.phy_model) {
|
2023-12-01 10:08:44 -08:00
|
|
|
case ICE_PHY_E82X:
|
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
|
|
|
/* 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;
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
ptp->state = ICE_PTP_INITIALIZING;
|
|
|
|
|
2024-05-28 16:03:51 -07:00
|
|
|
ice_ptp_init_hw(hw);
|
2023-07-17 15:17:13 -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_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;
|
2024-05-28 16:04:01 -07:00
|
|
|
if (ice_is_e825c(hw) && hw->ptp.is_2x50g_muxed_topo)
|
|
|
|
ptp->port.port_num = hw->pf_id * 2;
|
|
|
|
|
2021-10-13 08:54:51 -07:00
|
|
|
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);
|
|
|
|
|
2023-11-21 13:12:56 -08:00
|
|
|
/* Configure initial Tx interrupt settings */
|
|
|
|
ice_ptp_cfg_tx_interrupt(pf);
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
err = ice_ptp_create_auxbus_device(pf);
|
2021-12-20 08:58:27 -08:00
|
|
|
if (err)
|
|
|
|
goto err;
|
2021-06-09 09:39:50 -07:00
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
ptp->state = ICE_PTP_READY;
|
|
|
|
|
|
|
|
err = ice_ptp_init_work(pf, ptp);
|
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 (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;
|
|
|
|
}
|
2024-01-25 13:57:49 -08:00
|
|
|
ptp->state = ICE_PTP_ERROR;
|
2021-12-20 08:58:27 -08:00
|
|
|
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)
|
|
|
|
{
|
2024-01-25 13:57:49 -08:00
|
|
|
if (pf->ptp.state != ICE_PTP_READY)
|
2021-10-11 15:02:16 +08:00
|
|
|
return;
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
pf->ptp.state = ICE_PTP_UNINIT;
|
|
|
|
|
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: restore timestamp configuration after device reset
The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
to disable timestamping while the device is resetting. This operation
destroys the user requested configuration. While the driver does call
ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
after a reset, it unconditionally passes true or false, resulting in
failure to restore previous user space configuration.
This results in a device reset forcibly disabling timestamp configuration
regardless of current user settings.
This was not detected previously due to a quirk of the LinuxPTP ptp4l
application. If ptp4l detects a missing timestamp, it enters a fault state
and performs recovery logic which includes executing SIOCSHWTSTAMP again,
restoring the now accidentally cleared configuration.
Not every application does this, and for these applications, timestamps
will mysteriously stop after a PF reset, without being restored until an
application restart.
Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
2) ice_ptp_restore_timestamp_mode() which calls
ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
issues an immediate TSYN_TX interrupt to ensure that timestamps which
may have occurred during the device reset get processed.
Modify the ice_ptp_set_timestamp_mode to directly save the user
configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
no longer destroys the saved user configuration.
This obsoletes the ice_set_tx_tstamp() function which can now be safely
removed.
With this change, all devices should now restore Tx and Rx timestamping
functionality correctly after a PF reset without application intervention.
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
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>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-11-21 13:12:57 -08:00
|
|
|
ice_ptp_disable_timestamp_mode(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
|
|
|
|
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);
|
|
|
|
|
2024-07-02 10:14:54 -07:00
|
|
|
ice_ptp_disable_all_extts(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
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2024-01-25 13:57:49 -08:00
|
|
|
if (ice_pf_src_tmr_owned(pf))
|
|
|
|
ice_ptp_unregister_auxbus_driver(pf);
|
|
|
|
|
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:50 -07:00
|
|
|
ptp_clock_unregister(pf->ptp.clock);
|
|
|
|
pf->ptp.clock = NULL;
|
|
|
|
|
|
|
|
dev_info(ice_pf_to_dev(pf), "Removed PTP clock\n");
|
|
|
|
}
|