> > If it is known during device tree creation that only a single > > I2C master will be present on the bus, this deadlock of the > > I2C bus could be avoided in the driver by ignoring the > > bus_is_busy register of the xiic, since bus can never be > > reserved by any other master. > You could even initiate a recovery procedure if it is a device pulling > SDA low. In the case we actually observed xiic got permanently stuck, when I2C bus was temporarily and indirectly affected by external voltage pulse. This can happen in single-master or multi-master bus. It does seem that no extra recovery behavior is needed in this case. If we are able to determine that bus is not actually busy, we can start using it. Indicating that bus is single-master was a handy way to determine that. This issue was bad for us because even if SDA was not grounded anymore, bus was still indicated to be busy by FPGA register and driver would not continue. In multi-master case you would need some kind of timeout after which bus bus_is_busy is ignored and recovery attempted. This is ugly since it would be a non-standard behavior and intrusive to other masters on bus. In single-master case, if some slave device on bus would spontaneously pull SDA to ground when clock line is not pulsed, bus_is_busy could be triggered. In this case we could attempt some kind of recovery behavior. I guess this often means attempting to pulse the clock line to get the slave to release SDA. In my knowledge pulsing the clock line can help if slave device on bus has missed some clock signal edges (or is answering with more bits than expected for some reason) and is holding SDA down in an attempt to communicate a data bit to i2c -master. Extra pulses in clock line can then allow the slave to finish transmission and stop pulling SDA low. I however doubt that this type of recovery would be likely to help if I2C -slave spontaneously pulls SDA low. This would however be a very badly misbehaving slave -device, so it´s hard to speculate what it will do and what specific recovery might help. There is too much speculation for me to attempt or test bus recovery in this case, so I would leave it out of this change. If somebody notices and is able to test a case, where some specific extra recovery would be helpful, I would suggest to considered it later. -Jaakko
