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

i2c: i801: SMBus patch for Intel Coleto Creek DeviceIDs

2014-02-13T21:48:03+00:00

commit f39901c1befa556bc91902516a3e2e460000b4a8 upstream.

This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH.

Signed-off-by: Seth Heasley 
Signed-off-by: Wolfram Sang 
Cc: "Chan, Wei Sern" 
Signed-off-by: Greg Kroah-Hartman

i2c: mux: gpio: use gpio_set_value_cansleep()

2013-12-04T18:55:50+00:00

commit 250ad590d6f12d93f4d85be305b0a598d609232e upstream.

Some gpio chips may have get/set operations that
can sleep. gpio_set_value() only works for chips
which do not sleep, for the others we will get a
kernel warning. Using gpio_set_value_cansleep()
will work for both chips that do sleep and those
who don't.

Signed-off-by: Ionut Nicu 
Acked-by: Peter Korsgaard 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: mux: gpio: use reg value for i2c_add_mux_adapter

2013-12-04T18:55:50+00:00

commit 8c0ec2500eeb89749341884a972860d7f9e56f9c upstream.

The i2c-mux driver requires that the chan_id parameter
passed to the i2c_add_mux_adapter() function is equal
to the reg value for that adapter:

for_each_child_of_node(mux_dev->of_node, child) {
	ret = of_property_read_u32(child, "reg", ®);
	if (ret)
		continue;
	if (chan_id == reg) {
		priv->adap.dev.of_node = child;
		break;
	}
}

The i2c-mux-gpio driver uses an internal logical index
for chan_id when calling i2c_add_mux_adapter() instead
of using the reg value.

Because of this, there will problems in selecting the
right adapter when the i2c-mux-gpio's index into
mux->data.values doesn't match the reg value.

An example of such a case:

mux->data.values = { 1, 0 }

For chan_id = 0, i2c-mux will bind the adapter to the
of_node with reg = <0>, but when it will call the
select() callback with chan_id set to 0, the i2c-mux-gpio
will use it as an index into mux->data.values and it will
actually select the bus with reg = <1>.

Signed-off-by: Ionut Nicu 
Acked-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: ismt: initialize DMA buffer

2013-11-04T12:31:06+00:00

commit bf4169100c909667ede6af67668b3ecce6928343 upstream.

This patch adds code to initialize the DMA buffer to compensate for
possible hardware data corruption.

Signed-off-by: James Ralston 
[wsa: changed to use 'sizeof']
Signed-off-by: Wolfram Sang 
Cc: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

i2c: omap: Clear ARDY bit twice

2013-10-18T14:45:44+00:00

commit 4cdbf7d346e7461c3b93a26707c852e2c9db3753 upstream.

Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac
"i2c-omap: Double clear of ARDY status in IRQ handler"
added a workaround for undocumented errata ProDB0017052.
But then commit 1d7afc95946487945cc7f5019b41255b72224b70
"i2c: omap: ack IRQ in parts" refactored code and missed
one of ARDY clearings. So current code violates errata.
It causes often i2c bus timeouts on my Pandaboard.

This patch adds a second clearing in place.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Taras Kondratiuk 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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