14 Mar, 2010

1 commit


09 May, 2007

1 commit


02 May, 2007

2 commits

  • 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
    condition.

    Signed-off-by: Jean Delvare

    Jean Delvare
     
  • 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
    i2c_add_adapter().

    Signed-off-by: Jean Delvare

    Jean Delvare
     

11 Dec, 2006

2 commits


27 Sep, 2006

1 commit

  • i2c-algo-bit: Discard the mdelay data struct member

    The i2c_algo_bit_data structure has an mdelay member, which is not
    used by the algorithm code (the code has always been ifdef'd out.)
    Let's discard it to save some code and memory.

    Signed-off-by: Jean Delvare
    Acked-by: Mauro Carvalho Chehab
    Cc: Adrian Bunk
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     

29 Oct, 2005

2 commits


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds