On Thu, Jan 15, 2015 at 04:54:14PM +0200, Laurent Pinchart wrote:
DT nodes should use the more specific adi,adxl345 and adi,adxl346
compatible values instead. As the ADXL346 is backward-compatible with
the ADXL345, ADXL346 nodes must list both adi,adxl346 and adi,adxl345,
in that order.
On Thu, Jan 15, 2015 at 6:02 PM, Wolfram Sang w...@the-dreams.de wrote:
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -18,8 +18,7 @@ adi,adt7475 +/-1C TDM Extended Temp Range I.C
adi,adt7476
On Thu, Jan 15, 2015 at 06:45:33PM +0100, Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 3:54 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
The I2C subsystem can match devices without explicit OF support based on
the part of their compatible property after the
From: Marcin Wojtas m...@semihalf.com
This commit enables obtaining timeout value in miliseconds using the
timeout-ms property. If it doesn't succeed, the default value of
1000ms is set.
The Device Tree binding documentation is updated accordingly.
[gregory.clem...@free-electrons.com: convert
On Thu, Jan 15, 2015 at 06:32:31PM +0100, Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 6:02 PM, Wolfram Sang w...@the-dreams.de wrote:
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -18,8 +18,7 @@
On Thu, Jan 15, 2015 at 6:43 PM, Wolfram Sang w...@the-dreams.de wrote:
On Thu, Jan 15, 2015 at 06:32:31PM +0100, Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 6:02 PM, Wolfram Sang w...@the-dreams.de wrote:
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++
On Thu, Jan 15, 2015 at 04:54:15PM +0200, Laurent Pinchart wrote:
The I2C subsystem can match devices without explicit OF support based on
the part of their compatible property after the comma. However, this
mechanism uses the first compatible value only. For adxl34x OF device
nodes the
On Thu, Jan 15, 2015 at 08:33:18PM +0200, Pantelis Antoniou wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter
On Thu, Jan 15, 2015 at 3:54 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
The I2C subsystem can match devices without explicit OF support based on
the part of their compatible property after the comma. However, this
mechanism uses the first compatible value only. For
On Thu, Jan 15, 2015 at 06:02:09PM +0100, Wolfram Sang wrote:
On Thu, Jan 15, 2015 at 04:54:14PM +0200, Laurent Pinchart wrote:
DT nodes should use the more specific adi,adxl345 and adi,adxl346
compatible values instead. As the ADXL346 is backward-compatible with
the ADXL345, ADXL346 nodes
On Thu, Jan 15, 2015 at 06:33:55PM +0200, Pantelis Antoniou wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter
Hi Wolfram,
On Jan 15, 2015, at 19:35 , Wolfram Sang w...@the-dreams.de wrote:
On Thu, Jan 15, 2015 at 06:33:55PM +0200, Pantelis Antoniou wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter device
which caused a deadlock with muxes, and does not break the build
On Thu, Jan 15, 2015 at 3:54 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
DT nodes should use the more specific adi,adxl345 and adi,adxl346
compatible values instead. As the ADXL346 is backward-compatible with
the ADXL345, ADXL346 nodes must list both adi,adxl346 and
Hi Greg,
On Jan 14, 2015, at 22:41 , Greg Kroah-Hartman gre...@linuxfoundation.org
wrote:
On Wed, Jan 14, 2015 at 07:24:22PM +0200, Pantelis Antoniou wrote:
I’ll try to dig around tomorrow and see what the real device reference counts
are, but my hunch goes like this:
MUX
+—- ADAPTER
Hello,
This patch set fixes OF matching for the adxl34x driver when the DT node lists
a device-specific adi,adxl345 or adi,adxl346 compatible value first.
The first version (see http://www.spinics.net/lists/linux-i2c/msg18107.html)
added an OF match entry for the adi,adxl34x compatible string.
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter device
which caused a deadlock with muxes.
Signed-off-by: Pantelis
Hello,
On Thu, Jan 15, 2015 at 01:07:05PM +0100, Wolfram Sang wrote:
+ iproc_i2c-msg = msg;
Can it happen that iproc_i2c-msg still holds an uncompleted message
here or is this serialized by the core? Wolfram? Either here something
We have per-adapter locks serializing transfers, if you
Hi Wolfram,
On Thursday 15 January 2015 14:19:35 Wolfram Sang wrote:
On Thu, Jan 15, 2015 at 02:09:09PM +0100, Alexander Sverdlin wrote:
On 15/01/15 13:32, ext Wolfram Sang wrote:
On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote:
of: i2c: Add idle-disconnect DT property
On Thu, Jan 15, 2015 at 6:32 AM, Wolfram Sang w...@the-dreams.de wrote:
On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote:
of: i2c: Add idle-disconnect DT property to PCA954x mux driver
Add idle-disconnect device tree property to PCA954x mux driver. The new
property
forces
DT nodes should use the more specific adi,adxl345 and adi,adxl346
compatible values instead. As the ADXL346 is backward-compatible with
the ADXL345, ADXL346 nodes must list both adi,adxl346 and adi,adxl345,
in that order.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
The I2C subsystem can match devices without explicit OF support based on
the part of their compatible property after the comma. However, this
mechanism uses the first compatible value only. For adxl34x OF device
nodes the compatible property will contain the more specific
adi,adxl345 or
On Thursday 15 January 2015 21:00:37 Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 7:54 PM, Dmitry Torokhov wrote:
I still do not understand what we are trying to fix here. Why is
adi,adxl34x compatible string no good anymore? If we start using exact
models and the physical device does
Dear Gregory CLEMENT,
On Thu, 15 Jan 2015 18:24:31 +0100, Gregory CLEMENT wrote:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index 5c30026921ae..d7fa740b68f1 100644
---
On Thu, Jan 15, 2015 at 09:12:36PM +0200, Pantelis Antoniou wrote:
Hi Guenter,
On Jan 15, 2015, at 20:55 , Guenter Roeck li...@roeck-us.net wrote:
On Thu, Jan 15, 2015 at 08:33:18PM +0200, Pantelis Antoniou wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
Hi Wolfram,
On Thursday 15 January 2015 18:43:33 Wolfram Sang wrote:
On Thu, Jan 15, 2015 at 06:32:31PM +0100, Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 6:02 PM, Wolfram Sang w...@the-dreams.de wrote:
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++
On Thu, Jan 15, 2015 at 12:33 PM, Pantelis Antoniou
pantelis.anton...@konsulko.com wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the
On Thu, Jan 15, 2015 at 10:34:29PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015 21:00:37 Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 7:54 PM, Dmitry Torokhov wrote:
I still do not understand what we are trying to fix here. Why is
adi,adxl34x compatible string no good
On Thursday 15 January 2015 13:06:32 Dmitry Torokhov wrote:
On Thu, Jan 15, 2015 at 10:34:29PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015 21:00:37 Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 7:54 PM, Dmitry Torokhov wrote:
I still do not understand what we are
On Thu, Jan 15, 2015 at 11:34:00PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015 13:06:32 Dmitry Torokhov wrote:
On Thu, Jan 15, 2015 at 10:34:29PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015 21:00:37 Geert Uytterhoeven wrote:
On Thu, Jan 15, 2015 at 7:54 PM,
Hello.
On 01/15/2015 11:34 PM, Laurent Pinchart wrote:
I still do not understand what we are trying to fix here. Why is
adi,adxl34x compatible string no good anymore? If we start using exact
models and the physical device does not match do we abort probe? What is
the problem that we are
Hi Dmitry,
On Thursday 15 January 2015 13:50:53 Dmitry Torokhov wrote:
On Thu, Jan 15, 2015 at 11:34:00PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015 13:06:32 Dmitry Torokhov wrote:
On Thu, Jan 15, 2015 at 10:34:29PM +0200, Laurent Pinchart wrote:
On Thursday 15 January 2015
Hi Wolfram,
On Fri, 2015-01-09 at 18:21 +0100, Wolfram Sang wrote:
+ */
+struct i2c_adapter_quirks {
+ u64 flags;
+ int max_num_msgs;
+ u16 max_write_len;
+ u16 max_read_len;
+ u16 max_comb_write_len;
+ u16 max_comb_read_len;
+};
+
+#define
Hi Greg,
On Jan 16, 2015, at 00:55 , Greg Kroah-Hartman gre...@linuxfoundation.org
wrote:
On Thu, Jan 15, 2015 at 06:25:22PM +0200, Pantelis Antoniou wrote:
Hi Greg,
On Jan 14, 2015, at 22:41 , Greg Kroah-Hartman gre...@linuxfoundation.org
wrote:
On Wed, Jan 14, 2015 at 07:24:22PM
From: Subhendu Sekhar Behera sbeh...@broadcom.com
Add vendor name netlogic in vendor-prefixes.txt, which will be used for
the Netlogic XLP and XLPII MIPS SoCs. These processors were from NetLogic
Microsystems which is now part of Broadcom Corporation.
Signed-off-by: Subhendu Sekhar Behera
From: Subhendu Sekhar Behera sbeh...@broadcom.com
Add an I2C bus driver i2c-xlp9xx.c to support the I2C block in the
XLP9xx/XLP5xx MIPS SoC. Update Kconfig and Makefile to add the
CONFIG_I2C_XLP9XX option.
Also add document Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
for DT compatible
Hi Pantelis,
On Thu, 15 Jan 2015 18:25:22 +0200, Pantelis Antoniou wrote:
The remove method of the mux gets called and on it’s remove method
i2c_del_mux_adapter is called,
which in turn calls i2c_del_adapter() which hangs.
Anyway, finally figured out what the problem was, a reference was
Hi Guenter,
On Jan 15, 2015, at 20:55 , Guenter Roeck li...@roeck-us.net wrote:
On Thu, Jan 15, 2015 at 08:33:18PM +0200, Pantelis Antoniou wrote:
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
CM3232 is an advanced ambient light sensor with I2C protocol interface.
The I2C slave address is internally hardwired as 0x10 (7-bit). Writing
to configure register is byte mode, but reading ALS register requests to
use word mode for 16-bit resolution.
Signed-off-by: Kevin Tsai
Hello,
On Wed, Jan 14, 2015 at 02:23:32PM -0800, Ray Jui wrote:
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include
Hello,
On Wed, Jan 14, 2015 at 02:23:33PM -0800, Ray Jui wrote:
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
s/$/./
Signed-off-by:
V4: - Added bus lock to i2c_dw_init() as suggested by Jarrko Nikula
jarkko.nik...@linux.intel.com. Addresses infrequent hang that was
seen occuring during probe.
- Added label in i2c_dw_xfer() to bypass unnecessary lock release when
acquire fails.
This patch implements an I2C bus sharing mechanism between the host and platform
hardware on select Intel BayTrail SoC platforms using the X-Powers AXP288 PMIC.
On these platforms access to the PMIC must be shared with platform hardware. The
hardware unit assumes full control of the I2C bus and
Adds support for acquiring and releasing a hardware bus lock in the i2c
designware core transfer function. This is needed for i2c bus controllers
that are shared with but not controlled by the kernel.
Signed-off-by: David E. Box david.e@linux.intel.com
---
On Thu, Dec 18, 2014 at 02:49:28PM +0200, Laurent Pinchart wrote:
Hi Wolfram,
On Thursday 18 December 2014 09:21:51 Wolfram Sang wrote:
On Thu, Dec 18, 2014 at 04:15:23AM +0200, Laurent Pinchart wrote:
The I2C subsystem can match devices without explicit OF support based on
the part of
+ case M_CMD_STATUS_LOST_ARB:
+ dev_err(dev-device, lost bus arbitration\n);
I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors
for the next two cases is, maybe degrade them to dev_dbg, too?
These errors are rare, and it's nice to keep them at the
+ iproc_i2c-msg = msg;
Can it happen that iproc_i2c-msg still holds an uncompleted message
here or is this serialized by the core? Wolfram? Either here something
We have per-adapter locks serializing transfers, if you mean that?
+static int bcm_iproc_i2c_cfg_speed(struct
On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote:
of: i2c: Add idle-disconnect DT property to PCA954x mux driver
Add idle-disconnect device tree property to PCA954x mux driver. The new
property
forces the multiplexer to disconnect child buses in idle state. This is used,
On Thu, Jan 15, 2015 at 02:09:09PM +0100, Alexander Sverdlin wrote:
Hi Wolfram!
On 15/01/15 13:32, ext Wolfram Sang wrote:
On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote:
of: i2c: Add idle-disconnect DT property to PCA954x mux driver
Add idle-disconnect device tree
On Thu, Jan 15, 2015 at 1:53 PM, Wolfram Sang w...@the-dreams.de wrote:
There are three compatible strings defined for the ADXL345 and ADXL346 in
Documentation/devicetree/bindings/i2c/trivial-devices.txt: adi,adxl345,
adi,adxl346, adi,adxl34x. Given that the last one is a fallback for the
Hi Wolfram!
On 15/01/15 13:32, ext Wolfram Sang wrote:
On Fri, Dec 19, 2014 at 06:00:10PM +0100, Alexander Sverdlin wrote:
of: i2c: Add idle-disconnect DT property to PCA954x mux driver
Add idle-disconnect device tree property to PCA954x mux driver. The new
property
forces the multiplexer
Hi Wolfram,
On 15/01/15 14:19, ext Wolfram Sang wrote:
of: i2c: Add idle-disconnect DT property to PCA954x mux driver
Add idle-disconnect device tree property to PCA954x mux driver. The
new property
forces the multiplexer to disconnect child buses in idle state. This
is used,
Hi Wolfram,
On Thursday 15 January 2015 13:53:22 Wolfram Sang wrote:
On Thu, Dec 18, 2014 at 02:49:28PM +0200, Laurent Pinchart wrote:
On Thursday 18 December 2014 09:21:51 Wolfram Sang wrote:
On Thu, Dec 18, 2014 at 04:15:23AM +0200, Laurent Pinchart wrote:
The I2C subsystem can match
On Thu, Jan 15, 2015 at 7:54 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
I still do not understand what we are trying to fix here. Why is
adi,adxl34x compatible string no good anymore? If we start using exact
models and the physical device does not match do we abort probe? What is
the
On Thursday 15 January 2015 16:19:19 Laurent Pinchart wrote:
On Thursday 15 January 2015 13:53:22 Wolfram Sang wrote:
On Thu, Dec 18, 2014 at 02:49:28PM +0200, Laurent Pinchart wrote:
On Thursday 18 December 2014 09:21:51 Wolfram Sang wrote:
On Thu, Dec 18, 2014 at 04:15:23AM +0200, Laurent
On Thu, Jan 15, 2015 at 3:19 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
An option would be to remove adi,adxl34x from
Documentation/devicetree/bindings/i2c/trivial-devices.txt, in which case
the driver should match explicitly on adi,adxl345 and adi,adxl346.
That might
Been there, got bitten. We only found out too late, because one driver
was in i2c and the other in GPIO (or LED even?), both using 953x :(
That seems like a development, review and/or merge process failure to me, I
wouldn't avoid generic compatible strings for that reason only.
On Thursday 15 January 2015 15:36:37 Wolfram Sang wrote:
Been there, got bitten. We only found out too late, because one driver
was in i2c and the other in GPIO (or LED even?), both using 953x :(
That seems like a development, review and/or merge process failure to
me, I wouldn't avoid
58 matches
Mail list logo
