Hi Viresh, Il 29/02/2012 05:58, Viresh KUMAR ha scritto: > 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; > I think this is ok. It covers the standard situation and the experimental foundings. Regards, Vincenzo -- 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
