> > Really? READ_DATA looks like 8 clock pulses, but you need 9. > > This is why I have used word 'similar' :) Unfortunately chip does not > provide method to send exactly 9 pulses. Pity :( > But according to [1] it is the worst case scenario, usually less than 9 > pulses is enough. The I2C specification says "should send nine clock pulses". A recovery mechanism which "usually works" doesn't sound very attractive. > Another solution I see is to READ_DATA twice, this way we will have 16 > pulses. Can't you clock a single pulse when requesting an ACK? Or does READ_DATE clock an ACK so we might end up with 9 pulses after all? > > Bus recovery is only defined for stalled busses, i.e. when SDA is stuck > > low. It is not a suitable method to deal with general timeouts. > > You are right, I though I do not have precise info that SDA is stuck > low, but I guess status HSI2C_MASTER_ST_LOSE indicates is, I will check it. Thank you! > >> + i2c_lock_adapter(adap); > >> + clk_enable(i2c->clk); > >> + exynos5_i2c_recovery(i2c); > >> + clk_disable(i2c->clk); > >> + i2c_unlock_adapter(adap); > > Why do you need to lock? Aren't you protected by the call to master_xfer > > which then detected a problem? > > If the problem is detected in master_xfer driver uses internal function > exynos5_i2c_recovery, > but function exynos5_i2c_recover_bus is called by i2c_recover_bus, and > the latter can be called from any context, > this is why I have added locking. But the wrong one? The adapter lock is for serializing access to the adapter using the I2C API. If you need to protect register access within your driver, then you need the lock within struct exynos5_i2c.
Attachment:
signature.asc
Description: PGP signature
