Files
kernel/kernel-rt/debian/patches/ice-VDF/0004-ice-periodically-kick-Tx-timestamp-interrupt.patch
Jiping Ma 5be9ba03ba ice: Additional patches to support the customer use cases
Intel listed total 28 commits that need us to back port. There are
9 commits that are already included in our code base. The commit
"ice: Add support for E825-C TS PLL handling" will not be back
ported since we're not dealing with E825 for 24.09. So we need
back port 18 commits. These commits were introduced in linux-6.9.y
and linux-6.10.y.

To back port these 18 commits successfully, we totally back ported
37 upstream commits.

1) The patches 1-15 are cherry picked to fix the conflicts for patch
   16 ("ice: introduce PTP state machine") and patch 36 "ice:
   Introduce ice_ptp_hw struct". Also will be helpful for the
   subsequent commits back porting.

2) The patches 24-27 are cherry picked to fix the conflicts for patch
   28 ("ice: Fix debugfs with devlink reload")

3) The minor adjust was done for the patches 17, 21, 23 and 33 to
   fit with the context change.

Verification:
- installs from iso succeed on servers with ice(Intel Ethernet
  Controller E810-XXVDA4T Westport Channel) and i40e hw(Intel
  Ethernet Controller X710) for rt and std.
- interfaces are up and pass packets for rt and std.
- create vfs, ensure that they are picked up by the new iavf
  driver and that the interface can come up and pass packets
  on rt and std system.
- Check dmesg to see DDP package is loaded successfully and
  the version is 1.3.36.0 for rt and std.

Story: 2011056
Task: 50950

Change-Id: I9aef0378ea01451684341093a167eaead3edc458
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
2024-09-03 08:26:28 +00:00

122 lines
4.4 KiB
Diff

From 214f06259ade960e3790b62f96bc1b75e5b76e79 Mon Sep 17 00:00:00 2001
From: Jacob Keller <jacob.e.keller@intel.com>
Date: Fri, 1 Dec 2023 10:08:43 -0800
Subject: [PATCH 04/36] 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>
(cherry picked from commit 712e876371f8350c446a33577cf4a0aedcd4742a)
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
---
drivers/net/ethernet/intel/ice/ice_ptp.c | 50 ++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index 92459589f6ce..0d6c7215e0c1 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -2509,6 +2509,54 @@ enum ice_tx_tstamp_work ice_ptp_process_ts(struct ice_pf *pf)
}
}
+/**
+ * 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;
+
+ for (i = 0; i < ICE_MAX_QUAD; i++) {
+ 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);
+ }
+}
+
static void ice_ptp_periodic_work(struct kthread_work *work)
{
struct ice_ptp *ptp = container_of(work, struct ice_ptp, work.work);
@@ -2520,6 +2568,8 @@ static void ice_ptp_periodic_work(struct kthread_work *work)
err = ice_ptp_update_cached_phctime(pf);
+ ice_ptp_maybe_trigger_tx_interrupt(pf);
+
/* Run twice a second or reschedule if phc update failed */
kthread_queue_delayed_work(ptp->kworker, &ptp->work,
msecs_to_jiffies(err ? 10 : 500));
--
2.43.0