Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

[Viresh Kumar <viresh.kumar-qxv4g6HH51o@public.gmane.org>]

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