* Re: PCA9541 as mux and gatekeeper mode in Linux? [not found] <CAGXyBZnSFfGALfQWMb3jjbCjiECMn1aWGhjZwYb_P81iL3Tm_g@mail.gmail.com> @ 2017-06-29 15:09 ` Peter Rosin 2017-07-02 14:52 ` Bruce Hyde 0 siblings, 1 reply; 3+ messages in thread From: Peter Rosin @ 2017-06-29 15:09 UTC (permalink / raw) To: Bruce Hyde; +Cc: linux-i2c 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 > +---------+ +---------+ +----+ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PCA9541 as mux and gatekeeper mode in Linux? 2017-06-29 15:09 ` PCA9541 as mux and gatekeeper mode in Linux? Peter Rosin @ 2017-07-02 14:52 ` Bruce Hyde 2017-07-14 10:41 ` Peter Rosin 0 siblings, 1 reply; 3+ messages in thread From: Bruce Hyde @ 2017-07-02 14:52 UTC (permalink / raw) To: Peter Rosin; +Cc: linux-i2c Hi!! I did use TCA9548A multiplexer device connected with PCA9541 and this is working OK! Thank you for idea! Best regards, Bruce. 2017-06-29 17:09 GMT+02:00 Peter Rosin <peda@axentia.se>: > 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 >> +---------+ +---------+ +----+ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PCA9541 as mux and gatekeeper mode in Linux? 2017-07-02 14:52 ` Bruce Hyde @ 2017-07-14 10:41 ` Peter Rosin 0 siblings, 0 replies; 3+ messages in thread From: Peter Rosin @ 2017-07-14 10:41 UTC (permalink / raw) To: Bruce Hyde; +Cc: linux-i2c On 2017-07-02 16:52, Bruce Hyde wrote: > Hi!! > > I did use TCA9548A multiplexer device connected with PCA9541 and this > is working OK! > Thank you for idea! Cool, glad to be of help. However, after thinking some more, I think your original scheme was also ok, and allowed more parallel accesses. So, I'm real sorry for muddying the waters for you. I hope I didn't cause any major inconvenience! Anyway, the TCA9548A look compatible with PCA9548, do you happen to know if that's a fact? Should we add some more compatible strings to the i2c-mux-pca954x driver, so that any unexpected incompatibility can be handled cleanly? I find these chips that look like candidates: TCA9543A, TCA9544A, TCA9545A, TCA9546A and your TCA9548A. Cheers, Peter > Best regards, > Bruce. > > 2017-06-29 17:09 GMT+02:00 Peter Rosin <peda@axentia.se>: >> 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 >>> +---------+ +---------+ +----+ ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-07-14 10:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAGXyBZnSFfGALfQWMb3jjbCjiECMn1aWGhjZwYb_P81iL3Tm_g@mail.gmail.com>
2017-06-29 15:09 ` PCA9541 as mux and gatekeeper mode in Linux? Peter Rosin
2017-07-02 14:52 ` Bruce Hyde
2017-07-14 10:41 ` Peter Rosin
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.