On Fri, 23 Jan 2009 10:49:41 +0100, Peter Korsgaard wrote: > >>>>> "Jean" == Jean Delvare <khali@xxxxxxxxxxxx> writes: > > Hi, > > Jean> There are still a few caveats when doing this. In particular, > Jean> if you use drivers which probe the I2C bus for devices, you > Jean> must make sure that the devices will be properly found on > Jean> either the trunk or one of the multiplexer branches but not > Jean> both. In fact this is with this specific case in mind that I > Jean> decided to wait for the i2c device driver binding model to be > Jean> cleaned up before going on with full multiplexing support. > > True. I unsually solve this by making sure the multiplexer starts in > an unconnected state so the trunk probe doesn't find anything, or > simply not use the old style probing. Please keep in mind that the difficulty here is with probing itself, not just with old-style. The new binding model also has a detection mode, which is also affected. Making sure that the multiplexer is in an unconnected state initially isn't sufficient, as you can load I2C chip drivers at any later point in time and this will trigger a new detection cycle. And not all multiplexers can be disabled that way, some have always one outer channel enabled. I've been thinking about it a bit and my conclusion is that detection is simply not compatible with multiplexed I2C buses in general. In specific cases (for example if there is no chip on the trunk) you can get it to work but I couldn't come up with a logic that always works. If anyone has ideas, these are welcome. -- Jean Delvare -- 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
