Possible. But this change just makes i2c-mux-pinctrl honor status
property at all. There is no functional change except it now allows
you to disable any of the sub-busses.
Actually, this is the feature I like. However, I wonder if we shouldn't
have that in the core, say in
Hi Wolfram,
On Wed, Mar 18, 2015 at 10:07:30PM +0100, Wolfram Sang wrote:
On Mon, Feb 16, 2015 at 03:20:04PM +0200, Baruch Siach wrote:
This commit adds a driver for the I2C master controller on the CX92755 SoC.
The
CX92755 is one SoC in the Conexant Digicolor series. This driver should
I don't call that multi-master, though, so I guess we may have a bit of a
terminology problem.
This is definately not a multi-master issue, I agree. It is just
another issue I saw when thinking about your patch thoroughly again.
I'll see what I can come up with, but I am not sure if I'll
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
v2:
* Address the comment of Wolfram Sang:
- Advertise the I2C_FUNC_NOSTART capability
- Rebase on v4.0-rc1
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-digicolor.c |
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 bar...@tkos.co.il
---
v2: no change
---
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
v3:
* Fix checkpatch.pl errors
v2:
* Address the comment of Wolfram Sang:
- Advertise the I2C_FUNC_NOSTART capability
- Rebase on v4.0-rc1
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile| 1 +
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 bar...@tkos.co.il
---
v3: No change
v2: No change
---
On Thu, Mar 19, 2015 at 11:54:18AM +0200, Baruch Siach wrote:
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
v2:
* Address the comment of Wolfram Sang:
- Advertise the I2C_FUNC_NOSTART capability
- Rebase on v4.0-rc1
Please fix:
Applying: i2c: driver for the Conexant
I am still not too eager working on it but if you insist, I can see
what I can do as long as Stephen sticks with testing it on Tegra. ;)
Please decide if you want to work on it. Remember, I am not short of
patches to deal with.
Maybe sounds more harsh than it was meant. I just want to
Hi Wolfram,
On Thu, Mar 19, 2015 at 12:00:02PM +0100, Wolfram Sang wrote:
On Thu, Mar 19, 2015 at 11:54:18AM +0200, Baruch Siach wrote:
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
v2:
* Address the comment of Wolfram Sang:
- Advertise the I2C_FUNC_NOSTART capability
On 03/19/2015 01:16 AM, Wolfram Sang wrote:
I don't call that multi-master, though, so I guess we may have a bit of a
terminology problem.
This is definately not a multi-master issue, I agree. It is just
another issue I saw when thinking about your patch thoroughly again.
I'll see what I
On Thu, Mar 19, 2015 at 09:16:21AM +0100, Wolfram Sang wrote:
I don't call that multi-master, though, so I guess we may have a bit of a
terminology problem.
This is definately not a multi-master issue, I agree. It is just
another issue I saw when thinking about your patch thoroughly
On 19.03.2015 17:02, Wolfram Sang wrote:
Perhaps better would be to have a mux-specific function to iterate over a
mux's child nodes and instantiate buses for those. That function would check
whether each bus node was disabled or not. That'd isolate the special case
into the place where it was
Hello Wolfram,
On Thu, Mar 12, 2015 at 01:42:01PM +0100, Wolfram Sang wrote:
From: Wolfram Sang wsa+rene...@sang-engineering.com
After more discussion, brave users, and additional datasheet evaluation,
some API updates for the new I2C slave framework became imminent. The
slave events now
Turns out this is really easy to reproduce. One process reads
the eeprom over and over again, another runs i2cdump in a loop,
and voila ... lots of corruptions. Scary, especially considering
how wide-spread this kind of i2c access is in the kernel.
A coccinelle script should at least be able
-/* Only register child devices if the adapter has a node pointer set */
-if (!adap-dev.of_node)
+/* Only register childs if adapter has a node pointer with enabled
status */
+if (!adap-dev.of_node || !of_device_is_available(adap-dev.of_node))
return;
That
On Thu, Mar 19, 2015 at 01:16:47PM +0200, Baruch Siach wrote:
Signed-off-by: Baruch Siach bar...@tkos.co.il
I fixed two remaining 'check' issues with spaces around operators.
Applied to for-next, thanks!
signature.asc
Description: Digital signature
On Thu, Mar 19, 2015 at 01:16:46PM +0200, Baruch Siach wrote:
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
On 03/19/2015 04:09 AM, Wolfram Sang wrote:
Possible. But this change just makes i2c-mux-pinctrl honor status
property at all. There is no functional change except it now allows
you to disable any of the sub-busses.
Actually, this is the feature I like. However, I wonder if we shouldn't
have
On 03/19/2015 10:02 AM, Wolfram Sang wrote:
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap-dev.of_node)
+ /* Only register childs if adapter has a node pointer with enabled
status */
+ if (!adap-dev.of_node ||
20 matches
Mail list logo
