On Fri, Feb 01, 2019 at 07:37:45PM +0000, Sowjanya Komatineni wrote: > > > > BYTES_PER_FIFO_WORD 4 > > > > > > #define I2C_CNFG 0x000 > > > @@ -893,8 +892,9 @@ static int tegra_i2c_issue_bus_clear(struct > > > tegra_i2c_dev *i2c_dev) > > > i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG); > > > tegra_i2c_unmask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE); > > > > > > - time_left = wait_for_completion_timeout(&i2c_dev->msg_complete, > > > - TEGRA_I2C_TIMEOUT); > > > + time_left = wait_for_completion_timeout( > > > + &i2c_dev->msg_complete, > > > + msecs_to_jiffies(1000)); > > > > So potentially tegra_i2c_xfer_msg() could take more than 1 second > > and then fail with -EAGAIN, correct? In that case we should set > > adapter.timeout in probe to a larger value: > > > Bus clear pulse threshold we are setting is 9 (default as per spec) so > bus clear should happen after finishing sending of 9 pulses. > So 1sec is very long time for bus to get released and in case of ARB > LOST whole transfer to return EAGAIN will be much less then 1sec
What if for example we have a very long transfer, say some 64 KiB on Tegra194 and about 95% through the transfer something causes the bus to lock up. The transfer so far would've taken something on the order of 5 seconds, but we'd still fail, potentially with -EAGAIN, right? Or is there some other mechanism that would prevent the above from happening? Thierry
signature.asc
Description: PGP signature
