Looking for guidance to support 74CBTLV3253 mux

Looking for guidance to support 74CBTLV3253 mux

[MikeB]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[Peter Rosin]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[Peter Rosin]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[MikeB]

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.

Re: Looking for guidance to support 74CBTLV3253 mux

[Peter Rosin]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[Peter Rosin]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[MikeB]

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

Re: Looking for guidance to support 74CBTLV3253 mux

[Peter Rosin]

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