1. 08 Apr, 2016 13 commits
  2. 31 Mar, 2016 1 commit
  3. 01 Mar, 2016 2 commits
  4. 29 Feb, 2016 4 commits
  5. 16 Feb, 2016 1 commit
  6. 15 Feb, 2016 2 commits
  7. 09 Feb, 2016 1 commit
  8. 13 Jan, 2016 4 commits
  9. 23 Nov, 2015 1 commit
  10. 09 Nov, 2015 1 commit
  11. 13 Oct, 2015 2 commits
  12. 09 Oct, 2015 1 commit
    • Alessandro Rubini's avatar
      wr-servo: TRACK_PHASE now monitors delays to zero it · e052a9be
      Alessandro Rubini authored
      During track-phase we used to find the setpoint and then track changes in
      the master-to-slave delay, thus not zeroing any initial error that may
      happen (e.g. the initial sample was more jittery than average).
      
      Now we use the clock offset as correction source. Setpoint is
      adjusted by 1/4th of the current offset, to smooth a little the jitter.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      e052a9be
  13. 08 Oct, 2015 1 commit
    • Alessandro Rubini's avatar
      wr-servo: fix a synchronization bug · 4070caf1
      Alessandro Rubini authored
      This is likely the result of my cleanup of wr-servo, where I forgot
      some pieces.
      
      Greg collected some interesting logs in wrpc where the setpoint
      was calculated wrongly. This fixes the thing and removes some redundancy.
      
      I "git diff" order:
      
      - avoid WR_UNINITIALIZED, really unused. Do what's needed at
        wr_servo_init() time
      
      - adjust phase to 0 at init time, where s->cur_setpoint is set (we
        really should set and use in a single unified place)
      
      - set delta_ms_prev before entering TRACK_PHASE, not earlier where it
        doesn't fit
      
      - avoid extra checks of non-zero offset.seconds and
      offset.nanoseconds, because they are checked at the beginning anyways.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      4070caf1
  14. 01 Sep, 2015 5 commits
  15. 25 Aug, 2015 1 commit
    • Grzegorz Daniluk's avatar
      increase Announce rcv timeout to 20 - workaround for the WRS · ea89bf17
      Grzegorz Daniluk authored
      It's done to prevent PPSi leaving Slave state on the WRS when high load of
      background traffic is present. It's just a temporary workaround. In the future
      the HDL of the switch has to be fixed so that PPSi frames have higher priority
      than the normal traffic and are not dropped when WRS is overloaded.
      ea89bf17