1. 15 Apr, 2019 3 commits
  2. 19 Feb, 2019 3 commits
  3. 18 Feb, 2019 6 commits
  4. 27 Nov, 2018 1 commit
  5. 22 Oct, 2018 2 commits
  6. 19 Oct, 2018 3 commits
  7. 18 Oct, 2018 2 commits
  8. 27 Jun, 2018 2 commits
  9. 26 Feb, 2018 4 commits
    • Federico Vaga's avatar
      kernel: reset last trigger on new acquisition · 9120066f
      Federico Vaga authored
      This prevent to get confused about the value of this register.
      Whenever the user starts a new acquisition we reset the
      last triggered register. This guarantee that the value shown comes
      from the last acquisition
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      9120066f
    • Federico Vaga's avatar
      kernel: enable software trigger by default · e3fc1b13
      Federico Vaga authored
      Enabling the software trigger by default it does not cause any harm and
      it simplifies the code and the interface. The user is free to disable it
      using the `source` attribute from sysfs.
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      e3fc1b13
    • Federico Vaga's avatar
      kernel: gateware v5 updates · e3700a3a
      Federico Vaga authored
      The gateware version 5 does not have anymore the selection
      between internal or external trigger. Instead, there is the
      possibility to have more that one trigger source enabled.
      
      Internals:
      - the acquisition metadata now provides a whiterabbit timestamp
        and information about the trigger source that started the acquisition
      
      Registers change:
      - one register to enable/disable all trigger sources
      - one register to set the polarity on all the triggers
      - threshould/hysteresis for each channel
      - delay on the following triggers: ext, channel[1; 4]
      
      Sysfs changes
      - add attributes to configure threshould
      - trigger "enable" will restore the last known enable status
      e3700a3a
    • Federico Vaga's avatar
      kernel: do a proper reset of the FMC mezzanine · 32ef6bfc
      Federico Vaga authored
      In gateware version 5 the logic of the FMC reset bit change from active low
      to active high: "reset: {1: reset, 0 unreset}".
      
      Here with this patch we do a complete reset cycle of the FMC mezzanine.
      The sleeping time between reset and unreset is huge but we do not care much,
      this is just the initialization.
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      32ef6bfc
  10. 14 Feb, 2018 4 commits
  11. 13 Feb, 2018 4 commits
  12. 09 Feb, 2018 1 commit
  13. 29 Jan, 2018 3 commits
  14. 21 Dec, 2017 1 commit
  15. 29 Nov, 2017 1 commit