[PATCH v2 2/2] i2c: xiic: Support forcing single-master in DT

[Laine Jaakko EXT]

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