Angelo Compagnucci | 27 Feb 22:05 2015
Picon

i2c-tools: add Android.mk

Hi Jean,

This patch adds an Android.mk to compile i2c-tools under Android.

Hope this helps!

--

-- 
Profile: http://it.linkedin.com/in/compagnucciangelo
Wolfram Sang | 27 Feb 17:16 2015
Picon

[RFC] i2c-tools: i2ctransfer: add new tool

This tool allows to construct and concat multiple I2C messages into one
single transfer. Its aim is to test I2C master controllers, and so there
is no SMBus fallback.

Signed-off-by: Wolfram Sang <wsa@...>
---

I've been missing such a tool a number of times now, so I finally got around to
writing it myself. As with all I2C tools, it can be dangerous, but it can also
be very useful when developing. I am not sure if distros should supply it, I'll
leave that to Jean's experience. For embedded build systems, I think this
should be selectable. It is RFC for now because it needs broader testing and some
more beautification. However, I've been using it already to test the i2c_quirk
infrastructure and Renesas I2C controllers.

 tools/Module.mk     |   8 +-
 tools/i2ctransfer.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 303 insertions(+), 1 deletion(-)
 create mode 100644 tools/i2ctransfer.c

diff --git a/tools/Module.mk b/tools/Module.mk
index d14bb0c..62f1238 100644
--- a/tools/Module.mk
+++ b/tools/Module.mk
 <at>  <at>  -14,7 +14,7  <at>  <at>  TOOLS_CFLAGS	:= -Wstrict-prototypes -Wshadow -Wpointer-arith -Wcast-qual \
 		   -W -Wundef -Wmissing-prototypes -Iinclude
 TOOLS_LDFLAGS	:= -Llib -li2c

-TOOLS_TARGETS	:= i2cdetect i2cdump i2cset i2cget
+TOOLS_TARGETS	:= i2cdetect i2cdump i2cset i2cget i2ctransfer
(Continue reading)

Danielle Costantino | 21 Feb 08:09 2015
Picon

I2C library and tools (lsi2c) for linux

I published lsi2c and libi2cdev on github if anyone is interested in
trying out the new i2c bus tools.

https://github.com/costad2/i2cdev

Any feedback and contribution is greatly appreciated

EXAMPLE:

[root <at> linux ~]# lsi2c
I2C Adapters:
bus: i2c-0 path: 0               type: i2c name: MPC adapter at 0xffe03000
bus: i2c-2 path: 0:0.0           type: mux name: i2c-0-mux (chan_id 0)
bus: i2c-3 path: 0:0.1           type: mux name: i2c-0-mux (chan_id 1)
bus: i2c-4 path: 0:0.2           type: mux name: i2c-0-mux (chan_id 2)
bus: i2c-5 path: 0:0.3           type: mux name: i2c-0-mux (chan_id 3)
bus: i2c-6 path: 0:0.4           type: mux name: i2c-0-mux (chan_id 4)
bus: i2c-7 path: 0:0.5           type: mux name: i2c-0-mux (chan_id 5)
bus: i2c-8 path: 0:0.6           type: mux name: i2c-0-mux (chan_id 6)
bus: i2c-9 path: 0:0.7           type: mux name: i2c-0-mux (chan_id 7)
bus: i2c-1 path: 1               type: i2c name: MPC adapter at 0xffe03100
bus: i2c-10 path: 1:0.0           type: mux name: i2c-1-mux (chan_id 0)
bus: i2c-11 path: 1:0.1           type: mux name: i2c-1-mux (chan_id 1)
bus: i2c-18 path: 1:0.1:0.0       type: mux name: i2c-11-mux (chan_id 0)
bus: i2c-12 path: 1:0.2           type: mux name: i2c-1-mux (chan_id 2)
bus: i2c-32 path: 1:0.2:0.0       type: mux name: i2c-12-mux (chan_id 0)
bus: i2c-33 path: 1:0.2:0.0:0.0   type: mux name: i2c-32-mux (chan_id 0)
bus: i2c-34 path: 1:0.2:0.0:0.1   type: mux name: i2c-32-mux (chan_id 1)
bus: i2c-35 path: 1:0.2:0.0:0.2   type: mux name: i2c-32-mux (chan_id 2)
bus: i2c-36 path: 1:0.2:0.0:0.3   type: mux name: i2c-32-mux (chan_id 3)
(Continue reading)

Felipe Balbi | 19 Feb 19:06 2015
Picon

[PATCH] i2c: omap: implement bus recovery

If either SCL or SDA are stuck low, we need to
recover the bus using the procedure described
on section 3.1.16 of the I2C specification.

Note that we're trying to implement the procedure
exactly as described by that section. First we
check which line is stuck low, then implement
one or the other procedure. If SDA recovery procedure
fails, we reset our IP in an attempt to make it work.

Signed-off-by: Felipe Balbi <balbi@...>
---

Tested with AM437x IDK, AM437x SK, BeagleBoneBlack and Beagle X15 with
1000 iterations of i2cdetect on all available buses.

That said, I couldn't get any device to hold the bus busy so I could
see this working. If anybody has any good way of forcing a condition
so that we need bus recovery, I'd be glad to look at.

cheers

 drivers/i2c/busses/i2c-omap.c | 71 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0e894193accf..c3e4da751adf 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
 <at>  <at>  -472,6 +472,73  <at>  <at>  static int omap_i2c_init(struct omap_i2c_dev *dev)
(Continue reading)

Wolfram Sang | 19 Feb 17:37 2015
Picon

[PATCH] i2c: ocores: rework clk code to handle NULL cookie

For, !HAVE_CLK the clk API returns a NULL cookie. Rework the
initialization code to handle that. If clk_get_rate() delivers 0, we use
the fallback mechanisms. The patch is pretty easy when ignoring white
space issues (git diff -b).

Suggested-by: Russell King <rmk+kernel@...>
Signed-off-by: Wolfram Sang <wsa@...>
Cc: Max Filippov <jcmvbkbc@...>
Cc: Peter Korsgaard <jacmet@...>
---

Max, can you please test/review. I can only compile-test. This is the outcome
of this thread: https://lkml.org/lkml/2015/2/5/544

 drivers/i2c/busses/i2c-ocores.c | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 3fc76b6ffcaade..abf5db7e441eba 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
 <at>  <at>  -354,20 +354,24  <at>  <at>  static int ocores_i2c_of_probe(struct platform_device *pdev,
 		i2c->ip_clock_khz = clk_get_rate(i2c->clk) / 1000;
 		if (clock_frequency_present)
 			i2c->bus_clock_khz = clock_frequency / 1000;
-	} else if (of_property_read_u32(np, "opencores,ip-clock-frequency",
-					&val)) {
-		if (!clock_frequency_present) {
-			dev_err(&pdev->dev,
-				"Missing required parameter 'opencores,ip-clock-frequency'\n");
(Continue reading)

Wolfram Sang | 19 Feb 17:05 2015
Picon

[PATCH] i2c: designware-baytrail: another fixup for proper Kconfig dependencies

IOSF_MBI is tristate. Baytrail driver isn't.

Reported-by: Randy Dunlap <rdunlap@...>
Acked-by: David E. Box <david.e.box@...>
Signed-off-by: Wolfram Sang <wsa@...>
---
 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 3de426e..81a3ce9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
 <at>  <at>  -477,7 +477,7  <at>  <at>  config I2C_DESIGNWARE_PCI

 config I2C_DESIGNWARE_BAYTRAIL
 	bool "Intel Baytrail I2C semaphore support"
-	depends on I2C_DESIGNWARE_PLATFORM && IOSF_MBI && ACPI
+	depends on I2C_DESIGNWARE_PLATFORM && IOSF_MBI=y && ACPI
 	help
 	  This driver enables managed host access to the PMIC I2C bus on select
 	  Intel BayTrail platforms using the X-Powers AXP288 PMIC. It allows
--

-- 
2.1.4

Baruch Siach | 19 Feb 11:51 2015
Picon

[PATCH] i2c: fix reference to functionality constants definition

Since commit 607ca46e97 ('UAPI: (Scripted) Disintegrate include/linux') the
list of functionality constants moved to include/uapi/linux/i2c.h. Update the
reference accordingly.

Fixes: 607ca46e97 ('UAPI: (Scripted) Disintegrate include/linux')
Signed-off-by: Baruch Siach <baruch@...>
---
 Documentation/i2c/functionality | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 4556a3eb87c4..4aae8ed15873 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
 <at>  <at>  -12,7 +12,7  <at>  <at>  FUNCTIONALITY CONSTANTS
 -----------------------

 For the most up-to-date list of functionality constants, please check
-<linux/i2c.h>!
+<uapi/linux/i2c.h>!

   I2C_FUNC_I2C                    Plain i2c-level commands (Pure SMBus
                                   adapters typically can not do these)
--

-- 
2.1.4

Feng Kan | 18 Feb 20:34 2015

[PATCH V2 1/3] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan <fkan@...>
Signed-off-by: Hieu Le <hnle@...>
---
 drivers/i2c/busses/Kconfig             |   9 +
 drivers/i2c/busses/Makefile            |   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 464 +++++++++++++++++++++++++++++++++
 3 files changed, 474 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 825b586..5c27005 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
 <at>  <at>  -1072,6 +1072,15  <at>  <at>  config I2C_CROS_EC_TUNNEL
 	  connected there. This will work whatever the interface used to
 	  talk to the EC (SPI, I2C or LPC).

+config I2C_XGENE_SLIMPRO
+	tristate "APM X-Gene SoC I2C SLIMpro devices support"
+	depends on ARCH_XGENE && MAILBOX
+	help
+	  Enable I2C bus access using the APM X-Gene SoC SLIMpro
+	  co-processor. The I2C device access the I2C bus via the X-Gene
+	  to SLIMpro (On chip coprocessor) mailbox mechanism.
+	  If unsure, say N.
+
(Continue reading)

Uwe Kleine-König | 17 Feb 10:12 2015
Picon

[PATCH] i2c: pca954x: improve usage of gpiod API

Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for
outputs.

Also there is an *_optional variant that serves well here.  The sematics
is slightly changed here by using it. Now if a reset gpio is specified
and getting hold on it fails, pca954x_probe fails, too.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...>
---
 drivers/i2c/muxes/i2c-mux-pca954x.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index ec11b404b433..0042cf3d77db 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
 <at>  <at>  -201,9 +201,9  <at>  <at>  static int pca954x_probe(struct i2c_client *client,
 	i2c_set_clientdata(client, data);

 	/* Get the mux out of reset if a reset GPIO is specified. */
-	gpio = devm_gpiod_get(&client->dev, "reset");
-	if (!IS_ERR(gpio))
-		gpiod_direction_output(gpio, 0);
+	gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(gpio))
+		return PTR_ERR(gpio);

 	/* Write the mux register at addr to verify
(Continue reading)

Christian ROSALIE | 16 Feb 17:33 2015

Issue with USB/i2C

Hello,

I've got an issue with and USB/i2c device when i plug and unplug several 
times the usb device with a user-application using /dev/i2c-* file the 
kernel crashes because the data containing the struct i2c_adapter has 
been dealocated.

In the probe function of my driver, i allocates my resource (an internal 
structure) that contains a struct i2c_adapter with the struct 
i2c_algorithm. In my disconnect function i unregister the i2c adapter 
and then i free the ressource. Take not that i use kref design patern to 
prevent free data that are still used.

I look deeper in the i2c-dev (even on 3.19 release) and i notice that 
the callback function in the struct file_operations use struct 
i2c_client with an reference on a struct i2c_adapter and there is no 
mechanism to be sure that this reference has not be deallocated.

When i unplug my usb-device, i unregister my i2c-adapter but my 
user-space application still hold a file descriptor with a struc 
i2c_client that point to an struct i2c_adapter already freed.

I try to make a lock mechanism by adding a wait queue in the struct 
i2c_dev, to be sure that the adapter is no more used after a call to 
i2c_del_adapter, but it does not work and most of the time put the 
kernel in a dead lock.

To conclude it is not a good solution (not safe) to lock in 
i2c_del_adapter, because if the usb device is plugged again before the 
user-space application use the file descriptor the kernel is locked. A 
(Continue reading)

Baruch Siach | 16 Feb 14:20 2015
Picon

[PATCH 1/2] i2c: dt binding documentation for the Digicolor I2C controller

The CX92755 is an SoC in the Conexant Digicolor series. This devicetree binding
document describes the I2C controller on the CX92755 SoC, that is also shared
by some other SoCs in the Digicolor series.

Signed-off-by: Baruch Siach <baruch@...>
---
 .../devicetree/bindings/i2c/i2c-digicolor.txt      | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-digicolor.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt b/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
new file mode 100644
index 000000000000..457a098d4f7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
 <at>  <at>  -0,0 +1,25  <at>  <at> 
+Conexant Digicolor I2C controller
+
+Required properties:
+ - compatible: must be "cnxt,cx92755-i2c"
+ - reg: physical address and length of the device registers
+ - interrupts: a single interrupt specifier
+ - clocks: clock for the device
+ - #address-cells: should be <1>
+ - #size-cells: should be <0>
+
+Optional properties:
+- clock-frequency: the desired I2C bus clock frequency in Hz; in
+  absence of this property the default value is used (100 kHz).
+
(Continue reading)


Gmane