[Intel-wired-lan] [PATCH iwl-next] ice: periodically kick Tx timestamp interrupt

[Pucha, HimasekharX Reddy]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces at osuosl.org> On Behalf Of Karol Kolacinski
> Sent: Friday, November 3, 2023 10:00 PM
> To: intel-wired-lan at lists.osuosl.org
> Cc: netdev at vger.kernel.org; Brandeburg, Jesse <jesse.brandeburg at intel.com>; Staikov, Andrii <andrii.staikov at intel.com>; Kolacinski, Karol <karol.kolacinski at intel.com>; Nguyen, Anthony L <anthony.l.nguyen at intel.com>; Keller, Jacob E <jacob.e.keller at intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next] ice: periodically kick Tx timestamp interrupt
>
> From: Jacob Keller <jacob.e.keller at 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.keller at intel.com>
> Signed-off-by: Karol Kolacinski <karol.kolacinski at intel.com>
> Reviewed-by: Andrii Staikov <andrii.staikov at intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_ptp.c | 50 ++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha at intel.com> (A Contingent worker at Intel)