Hi Wolfram, Peter,
Thank you for the quick response.
W dniu 14.05.2020 o 16:50, Wolfram Sang pisze:
> Hi Krzysztof,
>
> On Thu, May 14, 2020 at 02:41:17PM +0200, Adamski, Krzysztof (Nokia - PL/Wrocław) wrote:
>
> Adding Peter as the mux maintainer to CC.
>
>> I have a problem that I think cannot be currently easily addressed by I2C framework in the kernel and I'm seeking for an
>> advice on how to approach this. I have an I2C device that can be accessed from two I2C masters connected to I2C bus
>> master selector channels. Both masters must do such a sequence before performing long operation:
>
> I need a diagram of that setup. What is the BMS? A chip? Some software?
> Can you draw a graph and give names of chips etc...?
>
> And, of course, why on earth do you need to access the same chip from
> two masters within one Linux? :) (That's how I understood it)
>
A diagram might be good indeed as it seems to be hard to explain. I don't use two masters from one Linux, both masters
are own two separate, independent systems and each of them needs access to the target device. BMS is a commonly
available chip - PCA9641 2-channel I2C-bus master arbiter but the problem is not related to any specific arbitrator
device. The target device is also a physical commonly available chip and it is designed in a way that the operation we
are performing might not be interrupted by other transfers except reading status register. The arbitrator device is
there to temporary block access from the other system if the first one is doing its transactions so it gives us a
possibility to do a mutex lock on the bus.
Here's my try to draw this, hopefully this clears things up:
+---------------+
| Target device |
+---------------+
|
+-----+-----|----+------+
| | Upstream | |
| +----------+ |
| Bus Master Arbiter |
| PCA9641 |
| +---+ +---+ |
| |Ch0| |Ch1| |
+----+---+---+---+------+
| |
+--------------------------+ | | +--------------------------+
| System 1 +------------+| | | |+------------+ System 2 |
| | I2C Master |+---+ +---+| I2C Master | |
| +------------+| |+------------+ |
| +-----+ | | +-----+ |
| | CPU | | | | CPU | |
| +-----+ | | +-----+ |
+--------------------------+ +--------------------------+
I was thinking that maybe a lock like this could be expressed by i2c_lock_bus with some special flag that would make
sure no deselect is called in i2c_mux_master_xfer() (and would be ignored if our parent is not an arbiter)? We already
have the I2C_MUX_ARBITRATOR flag and the i2c_mux_core does have an arbitrator bool so it is just a matter of allowing to
do this kind of deeper lock on the bus.
Best regards,
Krzysztof Adamski
