[PATCH v4 1/2] i2c: aspeed: added driver for Aspeed I2C

[Brendan Higgins]

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