1. 26 Mar, 2012 1 commit
  2. 29 Feb, 2012 1 commit
    • Daniel Vetter's avatar
      i2c: export bit-banging algo functions · b0209b39
      Daniel Vetter authored
      i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
      we need to be able to fall back to the bit-banging algo on gpio pins.
      The current code sets up a 2nd i2c controller for the same i2c bus using
      the bit-banging algo. This has a bunch of issues, the major one being
      that userspace can directly access this fallback i2c adaptor behind
      the drivers back.
      But we need to frob a few registers before and after using fallback
      gpio bit-banging, so this horribly fails.
      The new plan is to only set up one i2c adaptor and transparently fall
      back to bit-banging by directly calling the xfer function of the bit-
      banging algo in the i2c core.
      To make that possible, export the 2 i2c algo functions.
      v2: As suggested by Jean Delvare, simply export the i2c_bit_algo
      vtable instead of the individual functions.
      Acked-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  3. 13 Mar, 2010 1 commit
  4. 09 May, 2007 1 commit
  5. 01 May, 2007 2 commits
    • Jean Delvare's avatar
      i2c-algo-bit: Implement a 50/50 SCL duty cycle · 424ed67c
      Jean Delvare authored
      The original i2c-algo-bit implementation uses a 33/66 SCL duty cycle
      when bits are being written on the bus. While the I2C specification
      doesn't forbid it, this prevents us from driving the I2C bus to its
      max speed, limiting us to 66 kbps max on standard I2C busses.
      Implementing a 50/50 duty cycle instead lets us max out the bandwidth
      up to the theoretical max of 100 kbps on standard I2C busses. This is
      particularly important when large amounts of data need to be transfered
      over the bus, as is the case with some TV adapters when the firmware is
      being uploaded.
      In fact this change even allows, at least in theory, fast-mode I2C
      support at 125, 166 and 250 kbps. There's no way to reach the
      theoretical max of 400 kbps with this implementation. But I don't
      think we want to put efforts in that direction anyway: software-driven
      I2C is very CPU-intensive and bad for latency.
      Other timing changes:
      * Don't set SDA high explicitly on error, we're going to issue a stop
        condition before we leave anyway.
      * If an error occurs when sending the slave address, yield the CPU
        before retrying, and remove the additional delay after the new start
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
    • Jean Delvare's avatar
      i2c-algo-bit: Add i2c_bit_add_numbered_bus · 0f3b4838
      Jean Delvare authored
      Add i2c_bit_add_numbered_bus(), which is equivalent to i2c_bit_add_bus
      except that it calls i2c_add_numbered_adapter() at the end instead of
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
  6. 10 Dec, 2006 2 commits
  7. 26 Sep, 2006 1 commit
  8. 28 Oct, 2005 2 commits
  9. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!