Jean Delvare <khali@...> writes: [...] > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
