On 2015-10-19 10:51, Ludovic Desroches wrote:
> Hi Peter,
>
> On Fri, Oct 16, 2015 at 11:08:42AM +0200, Peter Rosin wrote:
>> On 2015-10-16 01:47, Peter Rosin wrote:
>>> On 2015-10-14 07:43, Ludovic Desroches wrote:
>>>> On Tue, Oct 13, 2015 at 08:01:34PM +02
On 2015-10-16 01:47, Peter Rosin wrote:
> On 2015-10-14 07:43, Ludovic Desroches wrote:
>> On Tue, Oct 13, 2015 at 08:01:34PM +0200, Peter Rosin wrote:
>>> On 2015-10-13 18:47, Cyrille Pitchen wrote:
>>>> Le 13/10/2015 17:19, Peter Rosin a écrit :
>>>>>
On 2015-10-20 15:27, Ludovic Desroches wrote:
> On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote:
>> On 2015-10-19 10:51, Ludovic Desroches wrote:
>>> Hi Peter,
>>>
>>> On Fri, Oct 16, 2015 at 11:08:42AM +0200, Peter Rosin wrote:
>>
On 2015-10-21 09:21, Peter Rosin wrote:
> On 2015-10-20 15:27, Ludovic Desroches wrote:
>> On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote:
>>> On 2015-10-19 10:51, Ludovic Desroches wrote:
>>>> Hi Peter,
>>>>
>>>> On Fr
91
> kernel image. Adapted to linux-next.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitc...@atmel.com>
> Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA
> controller")
> Reported-by: Peter Rosin <p...@lysator.liu.se>
> Signed-o
On 2015-10-13 18:47, Cyrille Pitchen wrote:
> Le 13/10/2015 17:19, Peter Rosin a écrit :
>> On 2015-10-13 16:21, Ludovic Desroches wrote:
>>> From: Cyrille Pitchen <cyrille.pitc...@atmel.com>
>>>
>>> In some cases a NACK interrupt may be pending i
From: Peter Rosin <p...@axentia.se>
Instead of checking for i2c parent adapters for every lock/unlock, simply
override the locking for muxes to always lock/unlock the parent adapter
directly.
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/i2c
From: Peter Rosin <p...@axentia.se>
Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
unlock_bus ops in the adapter. These funcs/ops take an additional flags
argument that indicates for what purpose the adapter is locked.
There are two flags, I2C_LOCK_A
From: Peter Rosin <p...@axentia.se>
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/muxes/i2c-mux-pca9541.c | 82 +++--
1 file changed, 15 insertions(+), 67 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
b/drivers/i2c/m
From: Peter Rosin <p...@axentia.se>
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/m
From: Peter Rosin <p...@axentia.se>
Hi!
I have a pair of boards with this i2c topology:
GPIO ---| -- BAT1
| v /
I2C -+--B---+ MUX
| \
EEPROM -- BAT2
On 2016-01-04 16:19, Lars-Peter Clausen wrote:
> On 01/04/2016 04:10 PM, Peter Rosin wrote:
>> From: Peter Rosin <p...@axentia.se>
>>
>> Signed-off-by: Peter Rosin <p...@axentia.se>
>
> It would be quite good if the commit messaged said why it is now safe
From: Peter Rosin <p...@axentia.se>
The initial core mux structure starts off small with only the parent
adapter pointer, which all muxes have, and a priv pointer for mux
driver private data.
Add i2c_mux_alloc function to unify the creation of a mux.
Where appropriate, pass around the mu
From: Peter Rosin <p...@axentia.se>
The dev pointer is readily available in the mux core struct, no point in
keeping multiple copies around.
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/i2c-mux.c | 24
drivers/i2c/muxes/
From: Peter Rosin <p...@axentia.se>
All muxes have slave side adapters, many have some arbitrary number of
them. Handle this in the mux core, so that drivers are simplified.
Add i2c_mux_reserve_adapter that can be used when it is known in advance
how many child adapters that is to be
From: Peter Rosin <p...@axentia.se>
The mux select and deselect ops are common to the mux most of the time,
so store the ops in the mux core.
Change the select and deselect op to work in terms of the mux core instead
of the child adapter. No driver uses the child adapter
From: Peter Rosin <p...@axentia.se>
With a i2c topology like the following
GPIO ---| -- BAT1
| v /
I2C -+--+ MUX
| \
EEPROM -- BAT2
there is a l
Hi Guenter,
On 2016-01-04 16:37, Guenter Roeck wrote:
> On 01/04/2016 07:10 AM, Peter Rosin wrote:
>> From: Peter Rosin <p...@axentia.se>
>>
>> The initial core mux structure starts off small with only the parent
>> adapter pointer, which all muxes have, and
From: Peter Rosin <p...@axentia.se>
The initial core mux structure starts off small with only the parent
adapter pointer, which all muxes have, and a priv pointer for mux
driver private data.
Add i2c_mux_alloc function to unify the creation of a mux.
Where appropriate, pass around the mu
From: Peter Rosin <p...@axentia.se>
The mux select and deselect ops are common to the mux most of the time,
so store the ops in the mux core.
Change the select and deselect op to work in terms of the mux core instead
of the child adapter. No driver uses the child adapter
From: Peter Rosin <p...@axentia.se>
The dev pointer is readily available in the mux core struct, no point in
keeping multiple copies around.
The patch also fixes a bug in rtl2832, which attached its mux slave
adapter to the device owning the mux parent adapter instead of
attaching it to i
From: Peter Rosin <p...@axentia.se>
All muxes have slave side adapters, many have some arbitrary number of
them. Handle this in the mux core, so that drivers are simplified.
Add i2c_mux_reserve_adapter that can be used when it is known in advance
how many child adapters that is to be
From: Peter Rosin <p...@axentia.se>
Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
unlock_bus ops in the adapter. These funcs/ops take an additional flags
argument that indicates for what purpose the adapter is locked.
There are two flags, I2C_LOCK_A
From: Peter Rosin <p...@axentia.se>
Instead of checking for i2c parent adapters for every lock/unlock, simply
override the locking for muxes to always lock/unlock the parent adapter
directly.
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/i2c
From: Peter Rosin <p...@axentia.se>
With a i2c topology like the following
GPIO ---| -- BAT1
| v /
I2C -+--+ MUX
| \
EEPROM -- BAT2
there is a l
From: Peter Rosin <p...@axentia.se>
There is a copy of the device pointer in the mux core.
Signed-off-by: Peter Rosin <p...@axentia.se>
---
drivers/i2c/muxes/i2c-mux-pinctrl.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/m
From: Peter Rosin <p...@axentia.se>
Hi!
I have a pair of boards with this i2c topology:
GPIO ---| -- BAT1
| v /
I2C -+--B---+ MUX
| \
EEPROM -- BAT2
Hi Guenter,
[BTW, if anyone feels spammed by this series, please drop me a note]
On 2016-01-05 17:42, Guenter Roeck wrote:
> On 01/05/2016 07:57 AM, Peter Rosin wrote:
>> From: Peter Rosin <p...@axentia.se>
>>
>> The initial core mux structure starts off small with
-05 17:49, kbuild test robot wrote:
> Hi Peter,
>
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on v4.4-rc8 next-20160105]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https
Hi Wolfram,
On 2016-01-05 19:48, Wolfram Sang wrote:
> Peter,
>
>> PS. needs a bunch of testing, I do not have access to all the involved hw
>
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.
Yeah, I started with dipping just the toes,
Hi Rob,
On 2016-01-06 15:49, Rob Herring wrote:
> On Tue, Jan 05, 2016 at 04:57:18PM +0100, Peter Rosin wrote:
>> From: Peter Rosin <p...@axentia.se>
>>
>> With a i2c topology like the following
>>
>>GPIO ---| -- BAT1
>>
Hi Antti,
On 2016-01-06 18:17, Antti Palosaari wrote:
> On 01/05/2016 05:57 PM, Peter Rosin wrote:
>> From: Peter Rosin <p...@axentia.se>
>>
>> Hi!
>>
>> I have a pair of boards with this i2c topology:
>>
>> GPIO ---
- devm_kfree(muxc->dev, muxc->adapter);
muxc->adapter = adapter;
muxc->max_adapters = adapters;
return 0;
--
On 2016-01-05 16:57, Peter Rosin wrote:
> From: Peter Rosin <p...@axentia.se>
>
> All muxes have slave side adapters, m
33 matches
Mail list logo
