Commit Graph

15 Commits

Author SHA1 Message Date
Wolfram Sang 8927fbf481 i2c: algo: bit: add flag to whitelist atomic transfers
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 <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-04-16 13:08:16 +02:00
Wolfram Sang 738ac0679b i2c: algo-bit: convert to SPDX header
And use kernel style for the remaining comments in the header.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-02-05 14:05:03 +01:00
Wolfram Sang 2292822e15 i2c: algo-bit: include main i2c header
We are using symbols from it, so we should include it directly. Found
after sorting includes in a driver.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-02-05 14:05:03 +01:00
Jean Delvare 5694f8a888 i2c: Update the FSF address
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-03-26 21:47:19 +02:00
Daniel Vetter b0209b3995 i2c: export bit-banging algo functions
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 <khali@linux-fr.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-29 20:47:42 +01:00
Jean Delvare 0a9c147513 i2c-algo-bit: Add pre- and post-xfer hooks
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>
2010-03-13 20:56:56 +01:00
John Anthony Kazos Jr 121e70b69a include files: convert "include" subdirectory to UTF-8
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>
2007-05-09 08:58:21 +02:00
Jean Delvare 424ed67c7d i2c-algo-bit: Implement a 50/50 SCL duty cycle
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>
2007-05-01 23:26:33 +02:00
Jean Delvare 0f3b483852 i2c-algo-bit: Add i2c_bit_add_numbered_bus
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>
2007-05-01 23:26:31 +02:00
Jean Delvare 3269711b76 i2c: Discard the i2c algo del_bus wrappers
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>
2006-12-10 21:21:33 +01:00
David Brownell 438d6c2c01 i2c: Whitespace cleanups
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>
2006-12-10 21:21:31 +01:00
Jean Delvare a0d9c63d36 i2c-algo-bit: Discard the mdelay data struct member
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>
2006-09-26 15:38:51 -07:00
Jean Delvare d3554b4a2f [PATCH] i2c: Drop unused per-i2c-algorithm adapter max
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>
2005-10-28 14:02:10 -07:00
Jean Delvare bf813b314a [PATCH] i2c: Drop useless CVS revision IDs
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>
2005-10-28 14:02:09 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00