1. 23 Jul, 2015 1 commit
  2. 22 Jul, 2015 3 commits
    • Alessandro Rubini's avatar
    • Alessandro Rubini's avatar
      wr-servo: run twice as fast · 6ecdf970
      Alessandro Rubini authored
      The old code used to discard every other tuple, because when "wait for
      hardware was set", the code cleared the flag and did nothing. This was
      exposed by one of the clean-up passes, but I chose not to change the
      behaviour.
      
      Now I do the normal work when wait_for_hw gets cleared.  However, as a
      side effect, wr_mon was always saying "wait for hardware", because any
      action would set the flag.
      
      Thus, the solution is not setting the flag in TRACK_PHASE, but only
      in the initial SYNC_SEC and SYNC_NSEC states. The code then checks
      if the hardware is busy, irrespective of any flag.  The result in wr_mon
      is matching reality, and the code works twice as fast as it used to.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      6ecdf970
    • Alessandro Rubini's avatar
      WR: set system time from WR time · 11c199bc
      Alessandro Rubini authored
      The previous code to set system time from WR time is not really
      working.
      
      It is implemented in wrs_time_ops->set and it relies on ppsi being
      non-wr slave before being wr slave, but this should not happen.  Such
      code, with its "weird" message, remains in place to be used when we
      run in non-wr mode (as slaves).
      
      This new code is the right thing to do: when we are done syncing the
      "big steps" in WR, and start dealing with sub-tick, we jump system
      time.
      
      There is no correction for TAI/UTC because the time operations for
      arch-unux (set/get) already do the conversion.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      11c199bc
  3. 21 Jul, 2015 5 commits
  4. 20 Jul, 2015 2 commits
  5. 10 Jul, 2015 1 commit
  6. 09 Jul, 2015 3 commits
    • Alessandro Rubini's avatar
      wr-servo: changes for the better · ac320650
      Alessandro Rubini authored
      What happened, sometimes, is that the phase setpoint take a meaningless
      (and high) value. This is because we were into SYNC_NSEC and moved
      to SYNC_PHASE without checking. Maybe because of other problems too.
      That situation led to a lockup of the softpll, which tries to
      reach an unreachable setpoint.
      
      Now we force to stay in SYNC_NSEC if the offset is more than one cycle
      (and SYNC_SEC if more than one second).
      
      As a side effect, the phase setpoint is always 0..16ns (while earlier
      I got setpoints of 1.5 of 17.5 etc, up to 64.5 for the same setup and
      same temperature).
      
      The problem here is: what is going to happen if, by thermal effect,
      the phase setpoint crosses the 0..16n interval?
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      ac320650
    • Alessandro Rubini's avatar
      c385d8aa
    • Adam Wujek's avatar
      Merge branch 'adam-snmp_tune' · a5a85d39
      Adam Wujek authored
      a5a85d39
  7. 08 Jul, 2015 3 commits
  8. 06 Jul, 2015 22 commits