Re: [PATCH V7 1/2] i2c/adapter: Add bus recovery infrastructure

["Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

Hello Viresh,

On Mon, Nov 26, 2012 at 06:21:25PM +0530, Viresh Kumar wrote:
> On 26 November 2012 17:15, Paul Carpenter
> <paul-YHLC2tV1sDlxR4N9A70vTlRxknfHcPLb9dF7HbQ/qKg@public.gmane.org> wrote:
> > Unless you know why the bus is stuck, how can you reset reminder this
> > method ONLY works if SCL is high and SDA probably was low and the slave
> > device is what is stuck in wrong state. NOTE SCL and SDA high can be
> > considered as BUS IDLE or having passed SDA = 1 waiting next clock edge
> > or state transition without other state information.
> >
> > From i2c protocol Rev. 03 section 3.1.16 titled "Bus clear" first bit -
> >
> >   "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."
> >
> > So if you do not check that SCL is NOT stuck Low the rest will just do
> > nothing, it wont clear the bus and the fault will not be reported.
> > The open drain nature of the bus means that you may attempt to toggle it
> > but if SCL is stuck low nothing will happen on the bus.
> >
> > Attempting to configure an SCL drive as any form of high driving output
> > will create a situation that when the SCL is driven high a high driver
> > on the GPIO will be driving into a stuck low situation potentially
> > creating a short between a power source and a power sink, that in most
> > cases will damage or shorten life of one or both ends.
> >
> > In over 10 years of using I2C in various forms the only times I have
> > seen bus stuck or device in wrong state
> >
> > 1/ Some code changed a bus switch when Bus was NOT idle
> >         i.e mid transaction
not sure what you mean here. Does it include a (SoC i.e. i2c master)
reset while the bus is not idle? That's the problem I was faced with
some time ago.

> > 2/ Bit-banged I2C software was wrong incomplete transaction
> > 3/ Short on bus
> > 4/ Faulty device
> > 5/ Faulty design so 1 and 0 thresholds were compromised
I can add:
6/ device does clock stretching which is not detected/supported by the
   bus master
7/ clock frequency too high for a device

In reply to a more detailed problem report that should be addressed by
this series on spear-devel I asked a few questions to rule out 6/ and
7/. I cannot find it in an public accessible archive though. It's about
a sta529 codec. When switching sample rates the codec then holds down
SDA. After an additional clock pulse the device and bus are OK again.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |