1. 08 Jul, 2014 2 commits
  2. 02 Jul, 2014 5 commits
  3. 12 Jun, 2014 1 commit
  4. 11 Jun, 2014 4 commits
  5. 28 Feb, 2014 2 commits
  6. 14 Feb, 2014 5 commits
  7. 12 Feb, 2014 2 commits
  8. 11 Feb, 2014 3 commits
  9. 18 Nov, 2013 1 commit
  10. 04 Nov, 2013 2 commits
  11. 02 Jul, 2013 1 commit
  12. 07 Jun, 2013 2 commits
  13. 31 May, 2013 3 commits
  14. 20 May, 2013 4 commits
  15. 16 May, 2013 3 commits
    • Alessandro Rubini's avatar
      new fmc-bus and fix in destroy(), to match new dev->release · 580113ae
      Alessandro Rubini authored
      fmc-bus is now fixed WRT the dev->release(). Now devices are correctly
      released when their use count reaches zero. Thus, we can't release them
      ourselves.
      
      This commit picks the new fmc-bus and adapts th own releae method.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      580113ae
    • Alessandro Rubini's avatar
      kernel/wr-nic (and doc): disable interrupts if too many · dcafaf66
      Alessandro Rubini authored
      When using the SPEC as White Rabbit grandmaster, you need to feed it
      with 10MHz, which would kill the computer with an interrupt flood.
      
      DIO interrupts are now disabled if they consume more than 80% of the
      total time, which usually triggers between 100kHz and 200kHz. Network
      interrupts are not affected.
      
      Thanks to Anders Wallin for reporting the problem and helping in the
      diagnosis.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      dcafaf66
    • Alessandro Rubini's avatar
      kernel/spec-i2c: bugfix: add delays in bitbanging i2c · 8b7a486f
      Alessandro Rubini authored
      This is a long-standing bug, and completely my fault.  Since our i2c
      is simply a bitbanging gpio-based interface, I need to add some delays
      into the operations.  Without this, accessing eeprom worked with most
      mezzanines but not with all of them. The measured speed was more than 1MHz.
      
      The devices are rated at 400kHz, so delay 1.25 usecs at each output
      operation (thus, writing is three such delay for each bit).  Addin the
      unpredictable software delays I see slightly more than than 200kHz
      in my test system.
      
      The driver now takes 2.5s to read the whole eeprom, but there's ample
      space to make it better by fixing the FIXME in spec-i2c.c .
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      8b7a486f