* Looking for guidance to support 74CBTLV3253 mux
@ 2016-11-10 11:59 MikeB
2016-11-10 12:52 ` Peter Rosin
0 siblings, 1 reply; 8+ messages in thread
From: MikeB @ 2016-11-10 11:59 UTC (permalink / raw)
To: linux-i2c
Hello,
I have a system with several 74CBTLV3253 mux set up as below.
+----------------+
| |
| PCA9547 |
| |
+-------+----+---+
| |
| +-------------------+
| |
+----+----+ +--------+-------+
| +----------+ |
| CPLD +----------+ 74CBTLV3253 |
| | | |
+---------+ +--+---+--+---+--+
| | | |
| | | |
+ + + +
In case the ascii-art is unlcear. At the top is a PCA9547 mux. On
one channel of the PCA9547 is a CPLD device. On another channel of
the PCA9547 is a 74CBTLV3253 mux. The CPLD has two signal lines
connected to the 74CBTLV3253 mux used to select its channel. There
are four channels on the 74CBTLV3253.
I'm looking to provide an i2c mux driver for the 74CBTLV3253 mux.
A register in the CPLD device controls the channel selection in the 74CBTLV3253.
To select a 74CBTLV3253 channel, requires the following sequence.
1. Select the CPLD channel on PCA9547.
2. Write the 74CBTLV3253 channel number to a register in the CPLD.
3. Select the 74CBTLV3253 channel on the PCA9547.
I'm struggling with the best way to deal with the fact that the action
of selecting a channel on the 74CBTLV3253 must access a device on an
entirely different i2c-adapter.
Any advice or guidance on how to attack this mux driver would be appreciated.
Regards, Mike
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-10 11:59 Looking for guidance to support 74CBTLV3253 mux MikeB @ 2016-11-10 12:52 ` Peter Rosin 2016-11-10 13:01 ` Peter Rosin 0 siblings, 1 reply; 8+ messages in thread From: Peter Rosin @ 2016-11-10 12:52 UTC (permalink / raw) To: MikeB, linux-i2c Hi! On 2016-11-10 12:59, MikeB wrote: > Hello, > > I have a system with several 74CBTLV3253 mux set up as below. > > +----------------+ > | | > | PCA9547 | > | | > +-------+----+---+ > | | > | +-------------------+ > | | > +----+----+ +--------+-------+ > | +----------+ | > | CPLD +----------+ 74CBTLV3253 | > | | | | > +---------+ +--+---+--+---+--+ > | | | | > | | | | > + + + + > > In case the ascii-art is unlcear. At the top is a PCA9547 mux. On Looks fine over here! > one channel of the PCA9547 is a CPLD device. On another channel of > the PCA9547 is a 74CBTLV3253 mux. The CPLD has two signal lines > connected to the 74CBTLV3253 mux used to select its channel. There > are four channels on the 74CBTLV3253. > > I'm looking to provide an i2c mux driver for the 74CBTLV3253 mux. > > A register in the CPLD device controls the channel selection in the 74CBTLV3253. > > To select a 74CBTLV3253 channel, requires the following sequence. > > 1. Select the CPLD channel on PCA9547. > 2. Write the 74CBTLV3253 channel number to a register in the CPLD. > 3. Select the 74CBTLV3253 channel on the PCA9547. > > I'm struggling with the best way to deal with the fact that the action > of selecting a channel on the 74CBTLV3253 must access a device on an > entirely different i2c-adapter. > > Any advice or guidance on how to attack this mux driver would be appreciated. The way to think about this is that it is the CPLD that stands for the muxing. So, you need to write a driver that on mux requests writes to the CPLD register, presumably 0-3. The fact that the i2c signals then travel through that 74CBTLV3253 thing is just HW immaterial to the programming logic. That IC could be replaced by any number of similar ICs, as long as the two signals from the CPLD does what is expected. What is different from most other i2c muxes is that you need to point out both the i2c master that is used to communicate with the CPLD and the i2c master that is muxed. The first one is the normal one you can access from the i2c_client struct (like any i2c devices). The other you need to pass in some other way, probably though devicetree or ACPI. Take a look at how i2c-mux-gpio gets to the i2c master it is muxing. Basically, replace the calls that i2c-mux-gpio does to update gpio pins with calls that update the CPLD register via the i2c master from the i2c_client struct. There is however one requirement, the CPLD-mux must be "mux-locked" as explained in Documentation/i2c/i2c-topology. Otherwise accesses to devices behind that mux will lock the PCA9547 mux for the full duration of the transaction and thus lock out any attempts to update the CPLD mux as part of the transaction. In that topology document, you are in the "Parent-locked mux as parent of mux-locked mux" section, with "dev D3" controlling "mux M2". Cheers, Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-10 12:52 ` Peter Rosin @ 2016-11-10 13:01 ` Peter Rosin 2016-11-11 11:47 ` MikeB 0 siblings, 1 reply; 8+ messages in thread From: Peter Rosin @ 2016-11-10 13:01 UTC (permalink / raw) To: MikeB, linux-i2c On 2016-11-10 13:52, Peter Rosin wrote: > Hi! > > On 2016-11-10 12:59, MikeB wrote: >> Hello, >> >> I have a system with several 74CBTLV3253 mux set up as below. >> >> +----------------+ >> | | >> | PCA9547 | >> | | >> +-------+----+---+ >> | | >> | +-------------------+ >> | | >> +----+----+ +--------+-------+ >> | +----------+ | >> | CPLD +----------+ 74CBTLV3253 | >> | | | | >> +---------+ +--+---+--+---+--+ >> | | | | >> | | | | >> + + + + >> >> In case the ascii-art is unlcear. At the top is a PCA9547 mux. On > > Looks fine over here! > >> one channel of the PCA9547 is a CPLD device. On another channel of >> the PCA9547 is a 74CBTLV3253 mux. The CPLD has two signal lines >> connected to the 74CBTLV3253 mux used to select its channel. There >> are four channels on the 74CBTLV3253. >> >> I'm looking to provide an i2c mux driver for the 74CBTLV3253 mux. >> >> A register in the CPLD device controls the channel selection in the 74CBTLV3253. >> >> To select a 74CBTLV3253 channel, requires the following sequence. >> >> 1. Select the CPLD channel on PCA9547. >> 2. Write the 74CBTLV3253 channel number to a register in the CPLD. >> 3. Select the 74CBTLV3253 channel on the PCA9547. >> >> I'm struggling with the best way to deal with the fact that the action >> of selecting a channel on the 74CBTLV3253 must access a device on an >> entirely different i2c-adapter. >> >> Any advice or guidance on how to attack this mux driver would be appreciated. > > The way to think about this is that it is the CPLD that stands for the > muxing. So, you need to write a driver that on mux requests writes > to the CPLD register, presumably 0-3. The fact that the i2c signals then > travel through that 74CBTLV3253 thing is just HW immaterial to the > programming logic. That IC could be replaced by any number of similar > ICs, as long as the two signals from the CPLD does what is expected. > > What is different from most other i2c muxes is that you need to point > out both the i2c master that is used to communicate with the CPLD and > the i2c master that is muxed. The first one is the normal one you can > access from the i2c_client struct (like any i2c devices). The other > you need to pass in some other way, probably though devicetree or > ACPI. Take a look at how i2c-mux-gpio gets to the i2c master it is > muxing. Basically, replace the calls that i2c-mux-gpio does to update > gpio pins with calls that update the CPLD register via the i2c master > from the i2c_client struct. > > There is however one requirement, the CPLD-mux must be "mux-locked" > as explained in Documentation/i2c/i2c-topology. Otherwise accesses > to devices behind that mux will lock the PCA9547 mux for the full > duration of the transaction and thus lock out any attempts to update > the CPLD mux as part of the transaction. In that topology document, > you are in the "Parent-locked mux as parent of mux-locked mux" > section, with "dev D3" controlling "mux M2". I.e. the CPLD is both "dev D3" *and* the control part of "mux M2", and 74CBTLV3253 is the (from the kernel point of view) uninteresting hardware part of "mux M2". Cheers, Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-10 13:01 ` Peter Rosin @ 2016-11-11 11:47 ` MikeB 2016-11-11 12:04 ` Peter Rosin 0 siblings, 1 reply; 8+ messages in thread From: MikeB @ 2016-11-11 11:47 UTC (permalink / raw) To: Peter Rosin; +Cc: linux-i2c Thank you for the informative reply. I was unfamiliar with the new mux and parent locking schemes. They do make the solution for this problem much easier to deal with. I'm working with release 4.4 (Ubuntu Xenial), so the mux/parent locking hadn't shown up on my radar yet. Unfortunately, the target release for my work is and will remain 4.4 for a while. Regards, Mike On Thu, Nov 10, 2016 at 8:01 AM, Peter Rosin <peda@axentia.se> wrote: >> There is however one requirement, the CPLD-mux must be "mux-locked" >> as explained in Documentation/i2c/i2c-topology. Otherwise accesses >> to devices behind that mux will lock the PCA9547 mux for the full >> duration of the transaction and thus lock out any attempts to update >> the CPLD mux as part of the transaction. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-11 11:47 ` MikeB @ 2016-11-11 12:04 ` Peter Rosin 2016-11-11 12:18 ` Peter Rosin 0 siblings, 1 reply; 8+ messages in thread From: Peter Rosin @ 2016-11-11 12:04 UTC (permalink / raw) To: MikeB; +Cc: linux-i2c On 2016-11-11 12:47, MikeB wrote: > On Thu, Nov 10, 2016 at 8:01 AM, Peter Rosin <peda@axentia.se> wrote: >>> There is however one requirement, the CPLD-mux must be "mux-locked" >>> as explained in Documentation/i2c/i2c-topology. Otherwise accesses >>> to devices behind that mux will lock the PCA9547 mux for the full >>> duration of the transaction and thus lock out any attempts to update >>> the CPLD mux as part of the transaction. > > Thank you for the informative reply. I was unfamiliar with the new > mux and parent locking schemes. They do make the solution for this > problem much easier to deal with. I'm working with release 4.4 > (Ubuntu Xenial), so the mux/parent locking hadn't shown up on my radar > yet. Unfortunately, the target release for my work is and will remain > 4.4 for a while. Lucky you :-) Anyway, you might be able to backport the changes? Start with: a7ab72390b77062420fb50e4451f71c9321aae05 "i2c: mux: add common data for every i2c-mux instance" through to 23fe440c59b9f08afe108e7ec7b6714cb2a3b955 "i2c: mux: drop old unused i2c-mux api" And then: 785d32c7a9638a96730686663564d1842f7c2f03 "i2c: allow adapter drivers to override the adapter locking" through to f76b724ee915415c52068c622ca48c652c1bd10c "i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes" There are a handful of commits right after that that are also related, but they should be irrelevant to you... Haven't tried it though, YMMV, and I might have forgotten a patch or two that came in later, but I don't remember any serious fallout... Cheers, Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-11 12:04 ` Peter Rosin @ 2016-11-11 12:18 ` Peter Rosin 2016-11-11 12:23 ` MikeB 2016-11-20 8:53 ` Peter Rosin 0 siblings, 2 replies; 8+ messages in thread From: Peter Rosin @ 2016-11-11 12:18 UTC (permalink / raw) To: MikeB; +Cc: linux-i2c On 2016-11-11 13:04, Peter Rosin wrote: > On 2016-11-11 12:47, MikeB wrote: >> On Thu, Nov 10, 2016 at 8:01 AM, Peter Rosin <peda@axentia.se> wrote: >>>> There is however one requirement, the CPLD-mux must be "mux-locked" >>>> as explained in Documentation/i2c/i2c-topology. Otherwise accesses >>>> to devices behind that mux will lock the PCA9547 mux for the full >>>> duration of the transaction and thus lock out any attempts to update >>>> the CPLD mux as part of the transaction. >> >> Thank you for the informative reply. I was unfamiliar with the new >> mux and parent locking schemes. They do make the solution for this >> problem much easier to deal with. I'm working with release 4.4 >> (Ubuntu Xenial), so the mux/parent locking hadn't shown up on my radar >> yet. Unfortunately, the target release for my work is and will remain >> 4.4 for a while. > > Lucky you :-) > > Anyway, you might be able to backport the changes? > > Start with: > > a7ab72390b77062420fb50e4451f71c9321aae05 > "i2c: mux: add common data for every i2c-mux instance" > > through to > > 23fe440c59b9f08afe108e7ec7b6714cb2a3b955 > "i2c: mux: drop old unused i2c-mux api" > > And then: > > 785d32c7a9638a96730686663564d1842f7c2f03 > "i2c: allow adapter drivers to override the adapter locking" > > through to > > f76b724ee915415c52068c622ca48c652c1bd10c > "i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes" Correction, those two commits became 8320f495cf441d593f7cd4f30e6b63455be71a2c and 2254d24aff3ab472dca287aef0123e8f0e06a14a when they got upstream. > There are a handful of commits right after that that are also > related, but they should be irrelevant to you... > > Haven't tried it though, YMMV, and I might have forgotten a patch > or two that came in later, but I don't remember any serious fallout... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-11 12:18 ` Peter Rosin @ 2016-11-11 12:23 ` MikeB 2016-11-20 8:53 ` Peter Rosin 1 sibling, 0 replies; 8+ messages in thread From: MikeB @ 2016-11-11 12:23 UTC (permalink / raw) To: Peter Rosin; +Cc: linux-i2c Thanks again. I was worried that I'd be entering backport hell trying to find everything needed to backport the new functionality. I can see from your list that the set is contained and manageable. Regards, Mike On Fri, Nov 11, 2016 at 7:18 AM, Peter Rosin <peda@axentia.se> wrote: > On 2016-11-11 13:04, Peter Rosin wrote: >> On 2016-11-11 12:47, MikeB wrote: >>> On Thu, Nov 10, 2016 at 8:01 AM, Peter Rosin <peda@axentia.se> wrote: >>>>> There is however one requirement, the CPLD-mux must be "mux-locked" >>>>> as explained in Documentation/i2c/i2c-topology. Otherwise accesses >>>>> to devices behind that mux will lock the PCA9547 mux for the full >>>>> duration of the transaction and thus lock out any attempts to update >>>>> the CPLD mux as part of the transaction. >>> >>> Thank you for the informative reply. I was unfamiliar with the new >>> mux and parent locking schemes. They do make the solution for this >>> problem much easier to deal with. I'm working with release 4.4 >>> (Ubuntu Xenial), so the mux/parent locking hadn't shown up on my radar >>> yet. Unfortunately, the target release for my work is and will remain >>> 4.4 for a while. >> >> Lucky you :-) >> >> Anyway, you might be able to backport the changes? >> >> Start with: >> >> a7ab72390b77062420fb50e4451f71c9321aae05 >> "i2c: mux: add common data for every i2c-mux instance" >> >> through to >> >> 23fe440c59b9f08afe108e7ec7b6714cb2a3b955 >> "i2c: mux: drop old unused i2c-mux api" >> >> And then: >> >> 785d32c7a9638a96730686663564d1842f7c2f03 >> "i2c: allow adapter drivers to override the adapter locking" >> >> through to >> >> f76b724ee915415c52068c622ca48c652c1bd10c >> "i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes" > > Correction, those two commits became > 8320f495cf441d593f7cd4f30e6b63455be71a2c and > 2254d24aff3ab472dca287aef0123e8f0e06a14a when they got upstream. > >> There are a handful of commits right after that that are also >> related, but they should be irrelevant to you... >> >> Haven't tried it though, YMMV, and I might have forgotten a patch >> or two that came in later, but I don't remember any serious fallout... > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Looking for guidance to support 74CBTLV3253 mux 2016-11-11 12:18 ` Peter Rosin 2016-11-11 12:23 ` MikeB @ 2016-11-20 8:53 ` Peter Rosin 1 sibling, 0 replies; 8+ messages in thread From: Peter Rosin @ 2016-11-20 8:53 UTC (permalink / raw) To: linux-i2c On 2016-11-11 13:18, Peter Rosin wrote: > On 2016-11-11 13:04, Peter Rosin wrote: >> On 2016-11-11 12:47, MikeB wrote: >>> On Thu, Nov 10, 2016 at 8:01 AM, Peter Rosin <peda@axentia.se> wrote: >>>>> There is however one requirement, the CPLD-mux must be "mux-locked" >>>>> as explained in Documentation/i2c/i2c-topology. Otherwise accesses >>>>> to devices behind that mux will lock the PCA9547 mux for the full >>>>> duration of the transaction and thus lock out any attempts to update >>>>> the CPLD mux as part of the transaction. >>> >>> Thank you for the informative reply. I was unfamiliar with the new >>> mux and parent locking schemes. They do make the solution for this >>> problem much easier to deal with. I'm working with release 4.4 >>> (Ubuntu Xenial), so the mux/parent locking hadn't shown up on my radar >>> yet. Unfortunately, the target release for my work is and will remain >>> 4.4 for a while. >> >> Lucky you :-) >> >> Anyway, you might be able to backport the changes? >> >> Start with: >> >> a7ab72390b77062420fb50e4451f71c9321aae05 >> "i2c: mux: add common data for every i2c-mux instance" >> >> through to >> >> 23fe440c59b9f08afe108e7ec7b6714cb2a3b955 >> "i2c: mux: drop old unused i2c-mux api" >> >> And then: >> >> 785d32c7a9638a96730686663564d1842f7c2f03 >> "i2c: allow adapter drivers to override the adapter locking" >> >> through to >> >> f76b724ee915415c52068c622ca48c652c1bd10c >> "i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes" > > Correction, those two commits became > 8320f495cf441d593f7cd4f30e6b63455be71a2c and > 2254d24aff3ab472dca287aef0123e8f0e06a14a when they got upstream. > >> There are a handful of commits right after that that are also >> related, but they should be irrelevant to you... >> >> Haven't tried it though, YMMV, and I might have forgotten a patch >> or two that came in later, but I don't remember any serious fallout... For the archives, this is a bugfix for one of the commits mentioned: ad092de60f865c1ad94221bd06d381ecea446cc8 "i2c: i2c-mux-pca954x: fix deselect enabling for device-tree" Cheers, Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-11-20 10:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-10 11:59 Looking for guidance to support 74CBTLV3253 mux MikeB 2016-11-10 12:52 ` Peter Rosin 2016-11-10 13:01 ` Peter Rosin 2016-11-11 11:47 ` MikeB 2016-11-11 12:04 ` Peter Rosin 2016-11-11 12:18 ` Peter Rosin 2016-11-11 12:23 ` MikeB 2016-11-20 8:53 ` 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.