All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Bruce Hyde <chrome.bureau@gmail.com>
Cc: "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: PCA9541 as mux and gatekeeper mode in Linux?
Date: Thu, 29 Jun 2017 17:09:36 +0200	[thread overview]
Message-ID: <59551830.1070505@axentia.se> (raw)
In-Reply-To: <CAGXyBZnSFfGALfQWMb3jjbCjiECMn1aWGhjZwYb_P81iL3Tm_g@mail.gmail.com>

Hi!

(please cc: the linux-i2c@ list; even though I'm the listed maintainer,
I'm not the only one who is able to answer questions, and others may get
hits while searching the list archives...)

On 2017-06-29 15:29, Bruce Hyde wrote:
> Hi!
> 
> I've noticed that you're currently the main maintainer of the i2c-mux
> functionality. I hope you will be able to help in my considerations or at least
> point to some useful information :-)
> Enclosed, you will find .txt file with my I2C topology illustrated (I wasn't
> sure if this would send in the proper plain text mode).

I read almost all my email with a fixed width typeface. I hate non-plaintext
email...

> In a nutshell: I'd like to use PCA9541 as a mux device. The main
> problem is that I'm
> not sure if it would be safe to let D1 and D3 have an address 0x30,
> and D2 and D4
> to have an address 0x40 => two devices with the same addresses on the i2c-0 bus
> from the master perspective.

If you could only consider one master, this topology would work. However,
since you presumably don't know what the other master is up to, that other
master may open the other pca9541 while "your" master tries to operate the
first pca9541. If that ever happens (and it will, probably for the first
time with some really awkward timing, in accordance with Murphy's law...)
then two client devices with the same address are visible on i2c-0 while one
(or both) master(s) does an access. That must not happen.

You are better off having one pca9541 do the 2-1 arbitration, followed
by one mux of some other kind doing 1-2 muxing on the client side of the
single pca9541. Like so:


+---------+       +---------+   +---------+             +----+
|         |       |  0x10   |   |  0x70   +---------+---+ D1 | 0x30
| MASTER1 +-------+         +---+         |         |   +----+
|         |       | PCA9541 |   | PCA9542 |         |   +----+
+---------+  +----+         |   |         +----+    +---+ D2 | 0x40
             |    +---------+   +---------+    |        +----+
             |                                 |
             |                                 |        +----+
+---------+  |                                 +----+---+ D3 | 0x30
|         |  |                                      |   +----+
| MASTER2 +--+                                      |   +----+
|         |                                         +---+ D4 | 0x40
+---------+                                             +----+

Cheers,
peda


> It's stated in the PCA9541 datasheet (section 10.4) that:
> 
>> Since each PCA9541/03 has its own unique address (for example, ‘A’, ‘B’, ‘C’, and so on), the EEPROMs
>> can be connected to the master, one at a time, by connecting one PCA9541/03 (Master 0 position) while
>> keeping the rest of the cards/devices isolated (off position).
> 
> but should I really care about setting the PCA9541 to off position
> (isolation) while
> using Linux mux interface? I mean, for example, when I'd like to communicate
> with D1 (0x30) device, kernel knows that it is on the virtual bus
> i2c-11 (for example),
> so it will first send the request to the particular PCA9541 device to
> ->select proper
> channel and then allow to communicate with D1 device, blocking any
> requests to the
> other PCA9541, since this is parent locked mux.
> 
> So, it's *not* possible that the master will somehow try to talk with
> D3 device (also with an address 0x30), because it is behind another PCA9541 mux.
> Could you please confirm if my thinking is correct and explain what am
> I missing, if it is
> not? Is that possible that mentioned topology will lead to I2C address
> collision and the
> only way to make it safe is to allow only one PCA9541 to be enabled at
> the particular
> time frame?
> 
> Best regards,
> Bruce.

[attachment inlined for those on the list]

> +---------+                +---------+    +----+
> |         |                |  0x10   +----+ D1 | 0x30
> | MASTER1 +---+------------+         |    +----+
> |         |   |            | PCA9541 |    +----+
> +---------+   | +----------+         +----+ D2 | 0x40
>               | |          +---------+    +----+
>               | |
>               | |          +---------+    +----+
> +---------+   +------------+         +----+ D3 | 0x30
> |         |     |          | PCA9541 |    +----+
> | MASTER2 +-----+----------+  0x11   |    +----+
> |         |                |         +----+ D4 | 0x40
> +---------+                +---------+    +----+

       reply	other threads:[~2017-06-29 15:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGXyBZnSFfGALfQWMb3jjbCjiECMn1aWGhjZwYb_P81iL3Tm_g@mail.gmail.com>
2017-06-29 15:09 ` Peter Rosin [this message]
2017-07-02 14:52   ` PCA9541 as mux and gatekeeper mode in Linux? Bruce Hyde
2017-07-14 10:41     ` Peter Rosin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59551830.1070505@axentia.se \
    --to=peda@axentia.se \
    --cc=chrome.bureau@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.