1. 11 Jun, 2021 8 commits
    • Jacob Keller's avatar
      ice: enable transmit timestamps for E810 devices · ea9b847c
      Jacob Keller authored
      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: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      ea9b847c
    • Jacob Keller's avatar
      ice: enable receive hardware timestamping · 77a78115
      Jacob Keller authored
      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: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      77a78115
    • Jacob Keller's avatar
      ice: report the PTP clock index in ethtool .get_ts_info · 67569a7f
      Jacob Keller authored
      Now that the driver registers a PTP clock device that represents the
      clock hardware, it is important that the clock index is reported via the
      ethtool .get_ts_info callback.
      
      The underlying hardware resource is shared between multiple PF
      functions. Only one function owns the hardware resources associated with
      a timer, but multiple functions may be associated with it for the
      purposes of timestamping.
      
      To support this, the owning PF will store the clock index into the
      driver shared parameters buffer in firmware. Other PFs will look up the
      clock index by reading the driver shared parameter on demand when
      requested via the .get_ts_info ethtool function.
      
      In this way, all functions which are tied to the same timer are able to
      report the clock index. Userspace software such as ptp4l performs
      a look up on the netdev to determine the associated clock, and all
      commands to control or configure the clock will be handled through the
      controlling PF.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      67569a7f
    • Jacob Keller's avatar
      ice: register 1588 PTP clock device object for E810 devices · 06c16d89
      Jacob Keller authored
      Add a new ice_ptp.c file for holding the basic PTP clock interface
      functions. If the device supports PTP, call the new ice_ptp_init and
      ice_ptp_release functions where appropriate.
      
      If the function owns the hardware resource associated with the PTP
      hardware clock, register with the PTP_1588_CLOCK infrastructure to
      allocate a new clock object that represents the device hardware clock.
      
      Implement basic functionality for reading and setting the clock time,
      performing clock adjustments, and adjusting the clock frequency.
      
      Future changes will introduce functionality for handling related
      features including Tx and Rx timestamps.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      06c16d89
    • Jacob Keller's avatar
      ice: add low level PTP clock access functions · 03cb4473
      Jacob Keller authored
      Add the ice_ptp_hw.c file and some associated definitions to the ice
      driver folder. This file contains basic low level definitions for
      functions that interact with the device hardware.
      
      For now, only E810-based devices are supported. The ice hardware
      supports 2 major variants which have different PHYs with different
      procedures necessary for interacting with the device clock.
      
      Because the device captures timestamps in the PHY, each PHY has its own
      internal timer. The timers are synchronized in hardware by first
      preparing the source timer and the PHY timer shadow registers, and then
      issuing a synchronization command. This ensures that both the source
      timer and PHY timers are programmed simultaneously. The timers
      themselves are all driven from the same oscillator source.
      
      The functions in ice_ptp_hw.c abstract over the differences between how
      the PHYs in E810 are programmed vs how the PHYs in E822 devices are
      programmed. This series only implements E810 support, but E822 support
      will be added in a future change.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      03cb4473
    • Jacob Keller's avatar
      ice: add support for set/get of driver-stored firmware parameters · 7f9ab54d
      Jacob Keller authored
      Depending on the device configuration, the ice hardware may share the
      PTP hardware clock timer between multiple PFs. Each PF is informed by
      firmware during initialization of the PTP timer association.
      
      When bringing up PTP, only the PFs which own the timer shall allocate
      a PTP hardware clock. Other PFs associated with that timer must report
      the correct PTP clock index in order to allow userspace software the
      ability to know which ports are connected to the same clock.
      
      To support this, the firmware has driver shared parameters. These
      parameters enable one PF to write the clock index into firmware, and
      have other PFs read the associated value out. This enables the driver to
      have only a single PF allocate and control the device timer registers,
      while other PFs associated with that timer can report the correct clock
      in the ETHTOOL_GET_TS_INFO report.
      
      Add support for the necessary admin queue commands to enable reading and
      writing of the driver shared parameters. This will be used in a future
      change to enable sharing the PTP clock index between PF drivers.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      7f9ab54d
    • Jacob Keller's avatar
      ice: process 1588 PTP capabilities during initialization · 9733cc94
      Jacob Keller authored
      The device firmware reports PTP clock capabilities to each PF during
      initialization. This includes various information for both the overall
      device and the individual function, including
      
      For functions:
      * whether this function has timesync enabled
      * whether this function owns one of the 2 possible clock timers, and
        which one
      * which timer the function is associated with
      * the clock frequency, if the device supports multiple clock frequencies
      * The GPIO pin association for the timer owned by this PF, if any
      
      For the device:
      * Which PF owns timer 0, if any
      * Which PF owns timer 1, if any
      * whether timer 0 is enabled
      * whether timer 1 is enabled
      
      Extract the bits from the capabilities information reported by firmware
      and store them in the device and function capability structures.o
      
      This information will be used in a future change to have the function
      driver enable PTP hardware clock support.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      9733cc94
    • Jacob Keller's avatar
      ice: add support for sideband messages · 8f5ee3c4
      Jacob Keller authored
      In order to support certain device features, including enabling the PTP
      hardware clock, the ice driver needs to control some registers on the
      device PHY.
      
      These registers are accessed by sending sideband messages. For some
      hardware, these messages must be sent over the device admin queue, while
      other hardware has a dedicated control queue for the sideband messages.
      
      Add the neighbor device message structure for sending a message to the
      neighboring device. Where supported, initialize the sideband control
      queue and handle cleanup.
      
      Add a wrapper function for sending sideband control queue messages that
      read or write a neighboring device register.
      
      Because some devices send sideband messages over the AdminQ, also
      increase the length of the admin queue to allow more messages to be
      queued up. This is important because the sideband messages add
      additional pressure on the AQ usage.
      
      This support will be used in following patches to enable support for
      CONFIG_1588_PTP_CLOCK.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      8f5ee3c4
  2. 10 Jun, 2021 32 commits