summaryrefslogtreecommitdiffstats
path: root/include/linux/i2c-algo-bit.h
Commit message (Collapse)AuthorAgeFilesLines
* i2c-algo-bit: Add pre- and post-xfer hooksJean Delvare2010-03-131-0/+2
| | | | | | | | | Drivers might have to do random things before and/or after I2C transfers. Add hooks to the i2c-algo-bit implementation to let them do so. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Alex Deucher <alexdeucher@gmail.com>
* include files: convert "include" subdirectory to UTF-8John Anthony Kazos Jr2007-05-091-1/+1
| | | | | | | Convert the "include" subdirectory to UTF-8. Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* i2c-algo-bit: Implement a 50/50 SCL duty cycleJean Delvare2007-05-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <khali@linux-fr.org>
* i2c-algo-bit: Add i2c_bit_add_numbered_busJean Delvare2007-05-011-0/+1
| | | | | | | | 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 <khali@linux-fr.org>
* i2c: Discard the i2c algo del_bus wrappersJean Delvare2006-12-101-1/+0
| | | | | | | They are all only calling i2c_del_adapter, so we may as well do it directly. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c: Whitespace cleanupsDavid Brownell2006-12-101-2/+2
| | | | | | | | Remove extraneous whitespace from various i2c headers and core files, like space-before-tab and whitespace at end of line. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
* i2c-algo-bit: Discard the mdelay data struct memberJean Delvare2006-09-261-1/+0
| | | | | | | | | | | | | | 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 <khali@linux-fr.org> Acked-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] i2c: Drop unused per-i2c-algorithm adapter maxJean Delvare2005-10-281-2/+0
| | | | | | | | There are no more per-i2c-algorithm adapter max. Last time there were was in July 1999. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] i2c: Drop useless CVS revision IDsJean Delvare2005-10-281-2/+0
| | | | | | | CVS revision IDs are totally useless and irrelevant by now. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+54
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!