> -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-boun...@osuosl.org> On Behalf Of Karol > Kolacinski > Sent: Friday, November 3, 2023 10:00 PM > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Brandeburg, Jesse <jesse.brandeb...@intel.com>; > Staikov, Andrii <andrii.stai...@intel.com>; Kolacinski, Karol > <karol.kolacin...@intel.com>; Nguyen, Anthony L <anthony.l.ngu...@intel.com>; > Keller, Jacob E <jacob.e.kel...@intel.com> > Subject: [Intel-wired-lan] [PATCH iwl-next] ice: periodically kick Tx > timestamp interrupt > > From: Jacob Keller <jacob.e.kel...@intel.com> > > 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.kel...@intel.com> > Signed-off-by: Karol Kolacinski <karol.kolacin...@intel.com> > Reviewed-by: Andrii Staikov <andrii.stai...@intel.com> > --- > drivers/net/ethernet/intel/ice/ice_ptp.c | 50 ++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) >
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pu...@intel.com> (A Contingent worker at Intel) _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
