Message ID | 20240220211123.2664977-1-komlodi@google.com |
---|---|
Headers | show |
Series | hw/i2c: smbus: Reset fixes | expand |
Hi Joe, On 20/2/24 22:11, Joe Komlodi wrote: > Changelog: > This series adds some resets for SMBus and for the I2C core. Along with > it, we make SMBus slave error printing a little more helpful. > > These reset issues were very infrequent, they would maybe occur in 1 out > of hundreds of resets in our testing, but the way they happen is pretty > straightforward. > > Basically as long as a reset happens in the middle of a transaction, the > state of the old transaction would still partially be there after the > reset. Once a new transaction comes in, the partial stale state can > cause the new transaction to incorrectly fail. Sorry for jumping late, at v4. I'm a bit confused by this series. - AFAICT there is no in-band or RESET line with I2C, but the AN10216 document mentions: I2C Bus recovery • Typical case is when masters fails when doing a read operation in a slave • SDA line is then non usable anymore because of the “Slave-Transmitter” mode. • Methods to recover the SDA line are: – Reset the slave device (assuming the device has a Reset pin) – Use a bus recovery sequence to leave the “Slave- Transmitter” mode • Bus recovery sequence is done as following: 1 - Send 9 clock pulses on SCL line 2 - Ask the master to keep SDA High until the “Slave- Transmitter” releases the SDA line to perform the ACK operation 3 - Keeping SDA High during the ACK means that the “Master-Receiver” does not acknowledge the previous byte receive 4 - The “Slave-Transmitter” then goes in an idle state 5 - The master then sends a STOP command initializing completely the bus - For SMBus Specification Version 2.0: 3.1.4.2 Power-on reset SMBus devices detect a power-on event in one of three ways: • By detecting that power is being applied to the device, • By an external reset signal that is being asserted or • For self-powered or always powered devices, by detecting that the SMBus is active (clock and data lines have gone high after being low for more than 2 1/2 seconds). Questions: - Is the first patch "hw/i2c: core: Add reset" really for I2C? Otherwise we could expand smbus form i2cbus, and have this reset only for smbus. - Should we model the "I2C bus recovery sequence" before triggering reset? - Shouldn't we model the smbus 2.5s timeout before triggering the reset? Thanks, Phil.