On 2/28/2012 7:25 PM, Salvatore DE DOMINICIS wrote: > What happens if the bus is still stuck? > Do we need to check also for a change in SDA line? > I mean, if some device is not behaving correctly and does not change the SDA > (as mandated by standard) then we don't solve the issue. > I also wanted to ask this question over list, so that experienced people can suggest what should we do here. Following is mentioned in: UM10204: I2C-bus specification and user manual http://www.nxp.com/documents/user_manual/UM10204.pdf "3.1.16 Bus clear In the unlikely event where the clock (SCL) is stuck LOW, the preferential procedure is to reset the bus using the HW reset signal if your I2C devices have HW reset inputs. If the I2C devices do not have HW reset inputs, cycle power to the devices to activate the mandatory internal Power-On Reset (POR) circuit. If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks. If not, then use the HW reset or cycle power to clear the bus." It says that the hang situation is "SDA is stuck LOW" and 9 clock pulses should be enough to get it out of hang (Can somebody tell me how this figure of "9" derived?) SDA will become High, but what guarantees that this will not be low immediately after that, while we are reading SDA line? Or Is reading SDA line after 9 pulses sufficient? > static int i2c_device_probe(struct device *dev) >> { > > + /* bus recovery specific initialization */ >>+ if (!adap->recover_bus) { >>+ if (!adap->clock_cnt || !adap->clock_rate) >>+ goto warn_no_recovery; I will also change this code to something like: if (!adap->recover_bus) { if (!adap->clock_cnt) adap->clock_cnt = 9; if (!adap->clock_rate) goto warn_no_recovery; -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
