kernel/linux.git/include/linux/i2c-algo-bit.h, branch v6.12.80

i2c: algo: bit: add flag to whitelist atomic transfers

2019-04-16T11:08:16+00:00

Use the new xfer_atomic callback to check a newly introduced flag to whitelist atomic transfers. This will report configurations which worked accidently. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang

i2c: algo-bit: convert to SPDX header

2019-02-05T13:05:03+00:00

And use kernel style for the remaining comments in the header. Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman Signed-off-by: Wolfram Sang

i2c: algo-bit: include main i2c header

2019-02-05T13:05:03+00:00

We are using symbols from it, so we should include it directly. Found after sorting includes in a driver. Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman Signed-off-by: Wolfram Sang

i2c: Update the FSF address

2012-03-26T19:47:19+00:00

Signed-off-by: Jean Delvare

i2c: export bit-banging algo functions

2012-02-29T19:47:42+00:00

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: Jean Delvare Signed-off-by: Daniel Vetter

i2c-algo-bit: Add pre- and post-xfer hooks

2010-03-13T19:56:56+00:00

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 Cc: Alex Deucher

include files: convert "include" subdirectory to UTF-8

2007-05-09T06:58:21+00:00

Convert the "include" subdirectory to UTF-8. Signed-off-by: John Anthony Kazos Jr. Signed-off-by: Adrian Bunk

i2c-algo-bit: Implement a 50/50 SCL duty cycle

2007-05-01T21:26:33+00:00

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

i2c-algo-bit: Add i2c_bit_add_numbered_bus

2007-05-01T21:26:31+00:00

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

i2c: Discard the i2c algo del_bus wrappers

2006-12-10T20:21:33+00:00

They are all only calling i2c_del_adapter, so we may as well do it directly. Signed-off-by: Jean Delvare