linux-toradex.git/drivers/i2c, branch v3.0.16

i2c-algo-bit: Generate correct i2c address sequence for 10-bit target

2011-12-09T16:52:19+00:00

commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream.

The wrong bits were put on the wire, fix that.

This fixes kernel bug #42562.

Signed-off-by: Sheng-Hui J. Chu 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-30-rc5/all-i2c' of git://git.fluff.org/bjdooks/linux

2011-07-07T23:29:29+00:00

* 'for-30-rc5/all-i2c' of git://git.fluff.org/bjdooks/linux:
  i2c-bfin-twi: abort transfer is MEM bit is reset unexpectedly
  i2c-s3c2410: Remove useless break code
  i2c-s3c2410: Fix typo 'i2s' -> 'i2c'
  i2c: tegra: Assign unused slave address

i2c/pca954x: Initialize the mux to disconnected state

2011-06-29T09:36:11+00:00

pca954x power-on default is channel 0 connected. If multiple pca954x
muxes are connected to the same physical I2C bus, the parent bus will
see channel 0 devices behind both muxes by default. This is bad.

Scenario:
            -- pca954x @ 0x70 -- ch 0 (I2C-bus-101) -- EEPROM @ 0x50
            |
I2C-bus-1 ---
            |
            -- pca954x @ 0x71 -- ch 0 (I2C-bus-111) -- EEPROM @ 0x50

1. Load I2C bus driver: creates I2C-bus-1
2. Load pca954x driver: creates virtual I2C-bus-101 and I2C-bus-111
3. Load eeprom driver
4. Try to read EEPROM @ 0x50 on I2C-bus-101. The transaction will also bleed
   onto I2C-bus-111 because pca954x @ 0x71 channel 0 is connected by default.

Fix: Initialize pca954x to disconnected state in pca954x_probe()

Signed-off-by: Petri Gynther 
Signed-off-by: Jean Delvare 
Cc: stable@kernel.org

i2c-taos-evm: Fix log messages

2011-06-29T09:36:10+00:00

* Print all error and information messages even when debugging is
  disabled.
* Don't use adapter device to log messages before it is ready.

Signed-off-by: Jean Delvare 
Cc: stable@kernel.org

Merge branches 'for-30-rc4/i2c-bfin', 'for-30-rc4/i2c-omap', 'for-30-rc4/i2c-s3c' and 'for-30-rc4/i2c-tegra' into for-30-rc5/all-i2c

2011-06-27T22:07:24+00:00

i2c-bfin-twi: abort transfer is MEM bit is reset unexpectedly

2011-06-27T22:06:48+00:00

Sometimes, the first I2C transmit interrupt is not serviced in time (like
when higher priority interrupts take too long).  Since the RESTART bit is
not set before the next I2C clock, when the TWI handler is finally called,
the I2C session is aborted (MEM bit is reset) and both SMITSERV and MCOMP
int status bits are set.

So when this happens, abort the transfer.

Reported-by: Isabelle Leonardi 
Signed-off-by: Sonic Zhang 
Signed-off-by: Mike Frysinger 
Signed-off-by: Ben Dooks

i2c-s3c2410: Remove useless break code

2011-06-27T22:06:05+00:00

Signed-off-by: Jonghwan Choi 
Signed-off-by: Kukjin Kim 
Signed-off-by: Ben Dooks

i2c-s3c2410: Fix typo 'i2s' -> 'i2c'

2011-06-27T22:05:56+00:00

Signed-off-by: Huisung Kang 
Signed-off-by: Kukjin Kim 
Signed-off-by: Ben Dooks

i2c: tegra: Assign unused slave address

2011-06-27T22:03:42+00:00

On Tegra, we should always use the "new" I2C slave controller, to avoid
issues with the old controller. This was implemented in commit 65a1a0a
"i2c: tegra: Enable new slave mode."

There is currently no driver for the Tegra I2C slave controller upstream.
Additionally, the controller cannot be completely disabled. Instead, we
need to:

a) Set I2C_SL_CNFG_NACK to make the controller automatically NACK any
incoming transactions.

b) The controller's definition of NACK isn't identical to the I2C
protocol's definition. Specifically, it will perform a standard NACK, but
*also* continue to hold the clock line low in expectation of receiving
more data. This can hang the bus, or at least cause transaction timeouts,
if something starts a transaction that matches the controller's slave
address. Since the default address is 0x00, the general call address,
this does occur in practice.

To avoid this, we explicitly program a slave address that is reserved for
future expansion. For current boards, this guarantees the address will
never be used. If a future board ever needs to use this address, we can
add platform data to determine a board-specific safe address. 0xfc is
picked by this patch.

This patch is based on a change previously posted by: Wei Ni 
http://www.spinics.net/lists/linux-i2c/msg05437.html
In turned based on internal changes by: Bharat Nihalani 

A semantically equivalent change has been contained in the various
ChromeOS kernels for a while.

I tested this change on top of 3.0-rc2 on Harmony, and interacted with
the WM8903 I2C-based audio codec.

Signed-off-by: Stephen Warren 
Signed-off-by: Ben Dooks

mfd: Use mfd cell platform_data for timberdale cells platform bits

2011-05-26T17:45:05+00:00

With the addition of a device platform mfd_cell pointer, MFD drivers
can go back to passing platform data back to their sub drivers.
This allows for an mfd_cell->mfd_data removal and thus keep the
sub drivers MFD agnostic. This is mostly needed for non MFD aware
sub drivers.

Acked-by: Richard Röjfors 
Signed-off-by: Samuel Ortiz