1. 15 Nov, 2019 4 commits
  2. 10 Nov, 2018 1 commit
  3. 06 Nov, 2018 1 commit
  4. 31 Oct, 2018 1 commit
    • Miroslav Lichvar's avatar
      igb: shorten maximum PHC timecounter update interval · 094bf4d0
      Miroslav Lichvar authored
      The timecounter needs to be updated at least once per ~550 seconds in
      order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old
      timestamp.
      
      Since commit 500462a9
      
       ("timers: Switch to a non-cascading wheel"),
      scheduling of delayed work seems to be less accurate and a requested
      delay of 540 seconds may actually be longer than 550 seconds. Shorten
      the delay to 480 seconds to be sure the timecounter is updated in time.
      
      This fixes an issue with HW timestamps on 82580/I350/I354 being off by
      ~1100 seconds for few seconds every ~9 minutes.
      
      Cc: Jacob Keller <jacob.e.keller@intel.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      094bf4d0
  5. 27 Apr, 2018 1 commit
  6. 23 Mar, 2018 1 commit
  7. 24 Jan, 2018 1 commit
    • Daniel Hua's avatar
      igb: Clear TXSTMP when ptp_tx_work() is timeout · 3a532852
      Daniel Hua authored
      
      
      Problem description:
      After ethernet cable connect and disconnect for several iterations on a
      device with i210, tx timestamp will stop being put into the socket.
      
      Steps to reproduce:
      1. Setup a device with i210 and wire it to a 802.1AS capable switch (
      Extreme Networks Summit x440 is used in our case)
      2. Have the gptp daemon running on the device and make sure it is synced
      with the switch
      3. Have the switch disable and enable the port, wait for the device gets
      resynced with the switch
      4. Iterates step 3 until the device is not albe to get resynced
      5. Review the log in dmesg and you will see warning message "igb : clearing
      Tx timestamp hang"
      
      Root cause:
      If ptp_tx_work() gets scheduled just before the port gets disabled, a LINK
      DOWN event will be processed before ptp_tx_work(), which may cause timeout
      in ptp_tx_work(). In the timeout logic, the TSYNCTXCTL's TXTT bit (Transmit
      timestamp valid bit) is not cleared, causing no new timestamp loaded to
      TXSTMP register. Consequently therefore, no new interrupt is triggerred by
      TSICR.TXTS bit and no more Tx timestamp send to the socket.
      Signed-off-by: default avatarDaniel Hua <daniel.hua@ni.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3a532852
  8. 06 Jun, 2017 2 commits
    • Jacob Keller's avatar
      igb: check for Tx timestamp timeouts during watchdog · e5f36ad1
      Jacob Keller authored
      
      
      The igb driver has logic to handle only one Tx timestamp at a time,
      using a state bit lock to avoid multiple requests at once.
      
      It may be possible, if incredibly unlikely, that a Tx timestamp event is
      requested but never completes. Since we use an interrupt scheme to
      determine when the Tx timestamp occurred we would never clear the state
      bit in this case.
      
      Add an igb_ptp_tx_hang() function similar to the already existing
      igb_ptp_rx_hang() function. This function runs in the watchdog routine
      and makes sure we eventually recover from this case instead of
      permanently disabling Tx timestamps.
      
      Note: there is no currently known way to cause this without hacking the
      driver code to force it.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e5f36ad1
    • Jacob Keller's avatar
      igb: fix race condition with PTP_TX_IN_PROGRESS bits · 4ccdc013
      Jacob Keller authored
      
      
      Hardware related to the igb driver has a limitation of only handling one
      Tx timestamp at a time. Thus, the driver uses a state bit lock to
      enforce that only one timestamp request is honored at a time.
      
      Unfortunately this suffers from a simple race condition. The bit lock is
      not cleared until after skb_tstamp_tx() is called notifying the stack of
      a new Tx timestamp. Even a well behaved application which sends only one
      timestamp request at once and waits for a response might wake up and
      send a new packet before the bit lock is cleared. This results in
      needlessly dropping some Tx timestamp requests.
      
      We can fix this by unlocking the state bit as soon as we read the
      Timestamp register, as this is the first point at which it is safe to
      unlock.
      
      To avoid issues with the skb pointer, we'll use a copy of the pointer
      and set the global variable in the driver structure to NULL first. This
      ensures that the next timestamp request does not modify our local copy
      of the skb pointer.
      
      This ensures that well behaved applications do not accidentally race
      with the unlock bit. Obviously an application which sends multiple Tx
      timestamp requests at once will still only timestamp one packet at
      a time. Unfortunately there is nothing we can do about this.
      Reported-by: default avatarDavid Mirabito <davidm@metamako.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4ccdc013
  9. 21 May, 2017 1 commit
  10. 17 Mar, 2017 1 commit
  11. 25 Dec, 2016 1 commit
  12. 10 Nov, 2016 1 commit
  13. 28 Sep, 2016 1 commit
  14. 22 Sep, 2016 1 commit
  15. 19 Aug, 2016 1 commit
  16. 16 Aug, 2016 1 commit
    • Kshitiz Gupta's avatar
      igb: fix adjusting PTP timestamps for Tx/Rx latency · 0066c8b6
      Kshitiz Gupta authored
      
      
      Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and
      igb_ptp_rx_rgtstamp. Add PHY delay compensation in
      igb_ptp_rx_pktstamp().
      
      In the IGB driver, there are two functions that retrieve timestamps
      received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp().
      The previous commit only changed igb_ptp_rx_rgtstamp(), and the change
      was incorrect.
      
      There are two instances in which PHY delay compensations should be
      made:
      
      - Before the packet transmission over the PHY, the latency between
        when the packet is timestamped and transmission of the packets,
        should be an add operation, but it is currently a subtract.
      
      - After the packets are received from the PHY, the latency between
        the receiving and timestamping of the packets should be a subtract
        operation, but it is currently an add.
      Signed-off-by: default avatarKshitiz Gupta <kshitiz.gupta@ni.com>
      Fixes: 3f544d2a
      
       (igb: adjust ptp timestamps for tx/rx latency)
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0066c8b6
  17. 29 Jun, 2016 4 commits
  18. 13 May, 2016 2 commits
  19. 24 Feb, 2016 1 commit
    • Roland Hii's avatar
      igb: add conditions for I210 to generate periodic clock output · 569f3b3d
      Roland Hii authored
      
      
      In general case the maximum supported half cycle time of the synchronized
      output clock is 70msec. Slower half cycle time than 70msec can be
      programmed also as long as the output clock is synchronized to whole
      seconds, useful specifically for generating a 1Hz clock.
      
      Permitted values for the clock half cycle time are: 125,000,000 decimal,
      250,000,000 decimal and 500,000,000 decimal (equals to 125msec, 250msec
      and 500msec respectively).
      
      Before this patch, only the half cycle time of less than or equal to 70msec
      uses the I210 clock output function. This patch adds additional conditions
      when half cycle time is equal to 125msec or 250msec or 500msec to use
      clock output function.
      
      Under other conditions, interrupt driven target time output events method
      is still used to generate the desired clock output.
      Signed-off-by: default avatarRoland Hii <roland.king.guan.hii@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569f3b3d
  20. 05 Oct, 2015 1 commit
  21. 18 Aug, 2015 1 commit
  22. 11 Jun, 2015 1 commit
  23. 31 Mar, 2015 2 commits
  24. 09 Mar, 2015 1 commit
  25. 06 Mar, 2015 2 commits
  26. 23 Jan, 2015 3 commits
  27. 02 Jan, 2015 1 commit
  28. 31 Dec, 2014 1 commit