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

[Vincenzo Frascino <vincenzo.frascino@xxxxxx>]

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