> I would like to add my five cents here. Do not limit the bus_clk with 400kHz (FM) while HighSpeed is above > 1MHz (above FM+ devices). I've successfully tested FM+ (1Mhz) in a quite big i2c network (a number of > pca9600, pca9675, pca9848) with at least eight AST2150 SoCs on the common bus. Interesting point, on one hand I would argue that we should force people to use either FM or FM+ in a conformant manner. But on the other hand, I suppose a device may not support FM+'s electrical characteristics, but could run at a higher clock rate, and it is better to allow that than forcing FM+. Maybe I should remove any kind of restriction, and just allow the clock to be set to any conformant frequency and expose FM+ as a separate option in device tree. Thoughts? > BTW. Just a lame question. If the device isn't designed to work on the higher speed (like standard of FM) > while the bus selected as FM+, would those kind of devices just unoperate or may have undefined behavior > and disturb the SDA/SCL? Just wondering to dynamically slowdown down to 100Khz (if needed) for the > specific slave, but keep high rate (FM+) at the normal operation. I have never tried this myself, but I suspect there may be other issues with running an FM device on an FM+ bus: FM+ uses a higher current to make the rise times on the line faster. A bigger problem: if a master wanted to select a high speed capable slave, it could write the address at a high speed which might look like a different address to a low speed slave that is incapable of sampling the address properly. So I do not think that supporting dynamically slowing down an I2C bus makes much sense. An interesting idea, though. -- 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
