Driver for pca9541 bus master selector
Hi all,
I am in the process of writing a driver for the pca9541 bus master selector. I using the i2c multiplexer framework, which fits the requirements quite nicely.
If anyone happens to know about an existing driver for this chip, please let me know. I would love to get some input for the arbitration mechanism needed to determine if and when to switch bus ownership from one master to the other.
Thanks,
Guenter
Hi Guenter,
Quoted 6 lines · Guenter Roeck
I am in the process of writing a driver for the pca9541 bus master selector. I using the i2c multiplexer framework, which fits the requirements quite nicely.
If anyone happens to know about an existing driver for this chip, please let me know. I would love to get some input for the arbitration mechanism needed to determine if and when to switch bus ownership from one master to the other.
See drivers/i2c/muxes/pca954x.c in 2.6.36-rc2 and later.
Signature · 1 line
Jean Delvare
Quoted 12 lines · Jean Delvare
Hi Guenter,
Quoted 6 lines · Guenter Roeck
I am in the process of writing a driver for the pca9541 bus master selector. I using the i2c multiplexer framework, which fits the requirements quite nicely.
If anyone happens to know about an existing driver for this chip, please let me know. I would love to get some input for the arbitration mechanism needed to determine if and when to switch bus ownership from one master to the other.
See
drivers/i2c/muxes/pca954x.cin 2.6.36-rc2 and later.
Yes, I know. I use it as basis. But it doesn't support pca9541, unfortunately. I use the select/deselect mechanism to trigger arbitration, but I still need a mechanism to communicate between the masters. After all, the problem to solve is that I have two masters and one slave, not one master and multiple slaves as with the other chips.
Note that I do have a solution which I think will work. Just figured it might save time if someone else already solved the same problem, and especially it might help me to determine arbitration time constants. There was mention of a pca9541 driver several years ago, but I have not been able to find details.
Thanks,
Guenter
Quoted 7 lines · Guenter Roeck
Quoted 6 lines · Jean Delvare
Hi Guenter,
Quoted 3 lines · Guenter Roeck
I am in the process of writing a driver for the pca9541 bus master selector. I using the i2c multiplexer framework, which fits the requirements quite nicely.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
If anyone happens to know about an existing driver for this chip, please let me know. I would love to get some input for the arbitration mechanism needed to determine if and when to switch bus ownership from one master to the other.
See
drivers/i2c/muxes/pca954x.cin 2.6.36-rc2 and later.Yes, I know. I use it as basis. But it doesn't support pca9541, unfortunately.
Oh, my bad. I had not noticed the PCA9541 was of a totally different kind.
Quoted 9 lines
I use the select/deselect mechanism to trigger arbitration, but I still need a mechanism to communicate between the masters. After all, the problem to solve is that I have two masters and one slave, not one master and multiple slaves as with the other chips.
Note that I do have a solution which I think will work. Just figured it might save time if someone else already solved the same problem, and especially it might help me to determine arbitration time constants. There was mention of a pca9541 driver several years ago, but I have not been able to find details.
Signature · 1 line
Jean Delvare
Hi Jean,
Quoted 12 lines · Jean Delvare
Quoted 11 lines · Guenter Roeck
Quoted 10 lines · Jean Delvare
Hi Guenter,
Quoted 6 lines · Guenter Roeck
I am in the process of writing a driver for the pca9541 bus master selector. I using the i2c multiplexer framework, which fits the requirements quite nicely.
If anyone happens to know about an existing driver for this chip, please let me know. I would love to get some input for the arbitration mechanism needed to determine if and when to switch bus ownership from one master to the other.
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
See
drivers/i2c/muxes/pca954x.cin 2.6.36-rc2 and later.Yes, I know. I use it as basis. But it doesn't support pca9541, unfortunately.
Oh, my bad. I had not noticed the PCA9541 was of a totally different kind.
Actually, I fell into the same trap. I was quite happy that someone else wrote the driver for me ... until I realized that the chips solve the opposite problem.
Time goes by ... have a look at
http://lists.lm-sensors.org/pipermail/lm-sensors/2004-June/008023.html
I wasn't sure if you (or someone else) ever had a driver for 9541, or if you referred to 9540 in above post. The links in the post don't work anymore.
Thanks,
Guenter
Quoted 9 lines · Guenter Roeck
Quoted 1 line · Jean Delvare
Oh, my bad. I had not noticed the PCA9541 was of a totally different kind.
Actually, I fell into the same trap. I was quite happy that someone else wrote the driver for me ... until I realized that the chips solve the opposite problem.
Time goes by ... have a look at
http://lists.lm-sensors.org/pipermail/lm-sensors/2004-June/008023.html
I didn't remember that discussion (unsurprisingly.)
Quoted 2 lines
I wasn't sure if you (or someone else) ever had a driver for 9541, or if you referred to 9540 in above post. The links in the post don't work anymore.
I was speaking of the PCA9540. I don't think anyone ever wrote a driver for the PCA9541. And in all honestly I don't think the new i2c-mux infrastructure is ready for this. It was written with single-master topologies in mind. You'll have to rethink a lot of things if you want to add support for "inverted" multiplexers. And I don't have the time to help, sorry.
I don't quite see the point of such chips, BTW. I2C supports multi-master already, so two masters talking to the same slave sequentially is already supported.
Signature · 1 line
Jean Delvare
On Wed, Sep 29, 2010 at 03:19:28AM -0400, Jean Delvare wrote:
[ ... ]
Quoted 8 lines
I was speaking of the PCA9540. I don't think anyone ever wrote a driver for the PCA9541. And in all honestly I don't think the new i2c-mux infrastructure is ready for this. It was written with single-master topologies in mind. You'll have to rethink a lot of things if you want to add support for "inverted" multiplexers. And I don't have the time to help, sorry.
Actually, the infrastructure works quite nicely. I use select_chan to acquire the slave, and release_chan to initiate release. It behaves like a one-channel multiplexer.
Quoted 4 lines
I don't quite see the point of such chips, BTW. I2C supports multi-master already, so two masters talking to the same slave sequentially is already supported.
Tell that to our HW team, and to them:
http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
Guenter
Guenter Roeck said the following:
Quoted 14 lines · Jean Delvare
[ ... ]
Quoted 8 lines
I was speaking of the PCA9540. I don't think anyone ever wrote a driver for the PCA9541. And in all honestly I don't think the new i2c-mux infrastructure is ready for this. It was written with single-master topologies in mind. You'll have to rethink a lot of things if you want to add support for "inverted" multiplexers. And I don't have the time to help, sorry.
Actually, the infrastructure works quite nicely. I use
select_chanto acquire the slave, andrelease_chanto initiate release. It behaves like a one-channel multiplexer.
Quoted 8 lines
Quoted 4 lines
I don't quite see the point of such chips, BTW. I2C supports multi-master already, so two masters talking to the same slave sequentially is already supported.
Tell that to our HW team, and to them:
I only took a rough look, but it seemed to me that the pca is part of the main device.
Quoted 1 line
From abstraction side of view your problem seems a matter of
synchronization of two independent computer systems. You will need a shared resource. The access to it could either be part of driver code or by introducing a 'one-channel multiplexer' as you did. But the sync needs to be done by your code via a shared data object.
Signature · 2 lines
KR Michael
On Thu, Sep 30, 2010 at 01:59:44AM -0400, Michael Lawnick wrote:
[ ... ]
Quoted 2 lines
I only took a rough look, but it seemed to me that the pca is part of the main device.
Yes
Quoted 6 lines
From abstraction side of view your problem seems a matter of synchronization of two independent computer systems. You will need a shared resource. The access to it could either be part of driver code or by introducing a 'one-channel multiplexer' as you did. But the sync needs to be done by your code via a shared data object.
Actually, the pca9541 has a bit in its register set which I can use. See NTESTON in its control register. That is visible as interrupt status at the other master. That is all I need, and reduces complexity significantly.
Thanks,
Guenter
Jean Delvare <khali@...> writes:
[...]
Quoted 5 lines
I don't quite see the point of such chips, BTW. I2C supports multi-master already, so two masters talking to the same slave sequentially is already supported.
To follow up on this, turns out there are (at least) two good reasons for having such a chip.
Firts, not all i2c masters support multi-master configuration.
The second reason is much more important. In a redundant system, one would not want redundant masters to be on the same i2c bus. If one of the two fails and blocks the bus, access to all slaves would be blocked. Not a good idea. Much better to have two i2c busses, and select the current master on the slave side.
Turns out both reasons apply in my use case. Testing shows that master selection works quite well with the driver I just submitted. I can persistently access all slaves from both masters even under high contention (both masters trying to access the same slave at the same time). If one of the masters fails while having access to the connected slaves, the other simply takes over after arbitration times out.
Guenter
On Wed, Sep 29, 2010 at 03:19:28AM -0400, Jean Delvare wrote:
[ ... ]
Quoted 3 lines
I don't quite see the point of such chips, BTW. I2C supports multi-master already, so two masters talking to the same slave sequentially is already supported.
To follow up on this, turns out there are (at least) two good reasons for having such a chip.
First, not all i2c masters support multi-master configuration.
The second reason is much more important. In a redundant system, one would not want redundant masters to be on the same i2c bus. If one of the two fails and blocks the bus, access to all slaves would be blocked. Not a good idea. Much better to have two i2c busses, and select the current master on the slave side.
Turns out both reasons apply in my use case. Testing shows that master selection works quite well with the driver I just submitted. I can persistently access all slaves from both masters even under high contention (both masters trying to access the same slave at the same time). If one of the masters fails while having access to the connected slaves, the other simply takes over after arbitration times out.
Guenter