Re: Two separate i2c transfers

From: Wolfram Sang <wsa@the-dreams.de>
To: "Adamski, Krzysztof (Nokia - PL/Wrocław)" <krzysztof.adamski@nokia.com>
Cc: Peter Rosin <peda@axentia.se>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: Two separate i2c transfers
Date: Fri, 15 May 2020 09:53:03 +0200	[thread overview]
Message-ID: <20200515075303.GA1083@ninjato> (raw)
In-Reply-To: <1f6b97e9-9ff8-2cdb-c6c5-16304f067d47@nokia.com>

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

> 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.

Thanks for this explanation. Much more clear to me now.

However, Peter might have way more insight than me because he was
already working on PCA9641 driver a year ago and I don't know how the
arbitration was designed there.

http://patchwork.ozlabs.org/project/linux-i2c/list/?series=95793

(Do you use this driver or a custom one?)

I'd think that the PCA9641 driver should return -EBUSY if another master
is active, so we'd have the lock on that level. But I may be totally
missing some detail here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]