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

i2c: i2c-mxs: Use DMA mode even for small transfers

2013-08-15T05:59:06+00:00

commit d6e102f498cbcc8dd2e36721a01213f036397112 upstream.

Recently we have been seing some reports about PIO mode not working properly.

- http://www.spinics.net/lists/linux-i2c/msg11985.html
- http://marc.info/?l=linux-i2c&m=137235593101385&w=2
- https://lkml.org/lkml/2013/6/24/430

Let's use DMA mode even for small transfers.

Without this patch, i2c reads the incorrect sgtl5000 version on a mx28evk when
touchscreen is enabled:

[    5.856270] sgtl5000 0-000a: Device with ID register 0 is not a sgtl5000
[    9.877307] sgtl5000 0-000a: ASoC: failed to probe CODEC -19
[    9.883528] mxs-sgtl5000 sound.12: ASoC: failed to instantiate card -19
[    9.892955] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-19)

[wsa: we have a proper solution for -next, so this non intrusive
solution is OK for now]

Signed-off-by: Fabio Estevam 
Acked-by: Shawn Guo 
Acked-by: Lucas Stach 
Acked-by: Marek Vasut 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c-piix4: Add AMD CZ SMBus device ID

2013-07-25T21:07:28+00:00

commit b996ac90f595dda271cbd858b136b45557fc1a57 upstream.

To add AMD CZ SMBus controller device ID.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Tejun Heo 
Reviewed-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2013-05-21T18:11:45+00:00

Pull i2c bugfixes from Wolfram Sang:
 "These should have been in rc2 but I missed it due to working on devm
  longer than expected.

  There is one ID addition, since we are touching the driver anyhow.
  And the feature bit documentation is one outcome of a debug session
  and will make it easier for users to work around problems.  The rest
  is typical driver bugfixes."

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: suppress lockdep warning on delete_device
  i2c: mv64xxx: work around signals causing I2C transactions to be aborted
  i2c: i801: Document feature bits in modinfo
  i2c: designware: add Intel BayTrail ACPI ID
  i2c: designware: always clear interrupts before enabling them
  i2c: designware: fix RX FIFO overrun

drivers/i2c/busses: don't check resource with devm_ioremap_resource

2013-05-18T09:55:32+00:00

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.

Signed-off-by: Wolfram Sang 
Acked-by: Stephen Warren 
Acked-by: Barry Song

i2c: suppress lockdep warning on delete_device

2013-05-17T20:49:45+00:00

i2c: suppress lockdep warning on delete_device

Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c multiplexer):

=============================================
[ INFO: possible recursive locking detected ]
3.8.7-0-sampleversion-fct #8 Tainted: G           O
---------------------------------------------
bash/3743 is trying to acquire lock:
  (s_active#110){++++.+}, at: [] sysfs_hash_and_remove+0x58/0xc8

but task is already holding lock:
  (s_active#110){++++.+}, at: [] sysfs_write_file+0xc8/0x208

other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(s_active#110);
   lock(s_active#110);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

4 locks held by bash/3743:
  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x4c/0x208
  #1:  (s_active#110){++++.+}, at: [] sysfs_write_file+0xc8/0x208
  #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [] i2c_sysfs_delete_device+0x90/0x238
  #3:  (&__lockdep_no_validate__){......}, at: [] device_release_driver+0x24/0x48

stack backtrace:
Call Trace:
[] dump_stack+0x8/0x34
[] __lock_acquire+0x161c/0x2110
[] lock_acquire+0x4c/0x70
[] sysfs_addrm_finish+0x19c/0x1e0
[] sysfs_hash_and_remove+0x58/0xc8
[] sysfs_remove_group+0x64/0x148
[] device_remove_attrs+0x9c/0x1a8
[] device_del+0x104/0x1d8
[] device_unregister+0x28/0x70
[] i2c_del_adapter+0x1cc/0x328
[] i2c_del_mux_adapter+0x14/0x38
[] pca954x_remove+0x90/0xe0 [pca954x]
[] i2c_device_remove+0x80/0xe8
[] __device_release_driver+0x74/0xf8
[] device_release_driver+0x2c/0x48
[] bus_remove_device+0x13c/0x1d8
[] device_del+0x10c/0x1d8
[] device_unregister+0x28/0x70
[] i2c_sysfs_delete_device+0x180/0x238
[] sysfs_write_file+0xe4/0x208
[] vfs_write+0xbc/0x160
[] SyS_write+0x54/0xd8
[] handle_sys64+0x44/0x64

The problem is already known for USB and PCI subsystems. The reason is that
delete_device attribute is defined statically in i2c-core.c and used for all
devices in i2c subsystem.

Discussion of original USB problem:
http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html

Commit 356c05d58af05d582e634b54b40050c73609617b introduced new macro to suppress
lockdep warnings for this special case and included workaround for USB code.

LKML discussion of the workaround:
http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html

As i2c case is in principle the same, the same workaround could be used here.

Signed-off-by: Alexander Sverdlin 
Acked-by: Alan Stern 
Cc: Eric W. Biederman 
Cc: Tejun Heo 
Cc: Peter Zijlstra 
Cc: Greg Kroah-Hartman 
Signed-off-by: Wolfram Sang

i2c: mv64xxx: work around signals causing I2C transactions to be aborted

2013-05-17T20:49:37+00:00

Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver, which can cause that driver to fail.  I2C drivers are not
expected to abort transactions on signals.

Signed-off-by: Russell King 
Signed-off-by: Wolfram Sang

i2c: i801: Document feature bits in modinfo

2013-05-17T20:49:30+00:00

Duplicate the feature bits documentation in modinfo, as not every user
will read the driver's source code or documentation file.

Signed-off-by: Jean Delvare 
Signed-off-by: Wolfram Sang

i2c: designware: add Intel BayTrail ACPI ID

2013-05-17T20:49:22+00:00

This is the same controller as on Intel Lynxpoint but the ACPI ID is
different (8086F41). Add support for this.

Signed-off-by: Mika Westerberg 
Signed-off-by: Wolfram Sang

i2c: designware: always clear interrupts before enabling them

2013-05-17T08:33:36+00:00

If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like a STOP condition from the controller point-of-view which sets
STOP detected bit in its status register causing the driver to fail
subsequent transfers.

Fix this by always clearing all interrupts before we start a transfer.

Signed-off-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: designware: fix RX FIFO overrun

2013-05-17T08:33:11+00:00

i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
to/from the bus into the TX FIFO.
For master-rx transactions, the maximum amount of data that can be
received is calculated depending solely on TX and RX FIFO load.

This is racy - TX FIFO may contain master-rx data yet to be
processed, which will eventually land into the RX FIFO. This
data is not taken into account and the function may request more
data than the controller is actually capable of storing.

This patch ensures the driver takes into account the outstanding
master-rx data in TX FIFO to prevent RX FIFO overrun.

Signed-off-by: Josef Ahmad 
Acked-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org