> > >Even if R-Car I2C received NACK, after that it might receive ACK > > >by HW auto restart. In case of that, driver would continue process. > > >If R-Car I2C didn't receive ACK, the driver would detect timeout > > >and would report NACK as -ENXIO. > > > > > >Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@xxxxxxxxxxx> > > >Signed-off-by: Yoshihiro Kaneko <ykaneko0929@xxxxxxxxx> > > > > Excuse me, but what exactly is HW auto restart in this case? Is it a feature > > of the I2C slave? > > I asked Kataoka-san about this and his response was as follows: > > It is a feature of the i2c-rcar(H/W) master. > > If system(CPU) is busy, NACK procedure may have interrupt latency. > Since the clear of ICMCR.ESG bit is delayed, i2c-rcar(H/W) may auto-restart > after NACK. Please refer to ESG bit of H/W UM section 55.3.5. > > For example, this is I2C write transmitting. > 1.Start / 2.SlaveAddr,ACK / 3.RegAddr,ACK / 4.RegData,ACK / 5.Stop > > If No.2 has NACK and interruption has delay, this transmitting is as follows. > 1.Start / 2.SlaveAddr,NACK/ 1x.auto-restart / 2x.SlaveAddr,ACK > / 3.RegAddr,ACK / 4.RegData,ACK / 5.Stop > > NACK of No.2 is invalidated by ACK of No.2x. It means recover. Does this make some I2C device work which did not work before? Most I2C devices always ack their address, so NACK very often means "nothing is there". I think it makes sense that the rcar driver returns ENXIO in this case which is documented to be used for NACK after address phase. Then, the i2c client driver should know if this means "not there" or "currently busy". And it should know when is a good time for another try. As I read the patch, the driver would use the auto-restart feature until the timeout is reached. That would make bus scanning pretty slow, too.
Attachment:
signature.asc
Description: Digital signature
