Re: [PATCH] Bitbanging i2c bus driver using the GPIO API

[David Brownell <david-b@pacbell.net>]

On Friday 09 March 2007 12:08 pm, Russell King wrote:
> On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote:
> > On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
> > > This is a very simple bitbanging i2c bus driver utilizing the new
> > > arch-neutral GPIO API. Useful for chips that don't have a built-in
> > > i2c controller, additional i2c busses, or testing purposes.
> > 
> > That's the right idea!  But remember that not all GPIOs support
> > reading back the actual value on SCL (it's an OUT pin, so lacking
> > multidrive capability the values "should" be what you wrote), so
> > getscl() support should depend on a flag in platform data.  In
> > the same vein, if SCL is an output-only pin, you won't be able
> > to change its direction ... but then, I'm not sure why you were
> > changing its direction in setscl() rather than just its value.
> 
> That's a more correct I2C implementation.  If you read the specs, the
> SDA and SCL signals are supposed to be driven by open-collector or
> open-drain drivers, such that devices only pull the bus low.  Pull-up
> resistors pull the signals high when undriven.

Exactly as I had mentioned:

> > I2C has another interesting special case.  at91_set_multi_drive()
> > would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best
> > support both clock stretching and multi-master configurations.

Where "multi-drive" == open-drain.  You're saying it should also be
used on SDA too ... OK, I was focussing on clock stretching but it
applies there too.

 
> This avoids the possibility of damage caused when one device drives
> a signal low and another device tries to drive it high.
> 
> Therefore, the correct I2C GPIO implementation is one where you drive
> both SDA and SCL low by using a combination of the data direction
> register and the output level register, but avoid driving the output
> high.

I see your point -- it does answer my question -- but you seem to have
overlooked a highly relevant one of mine.  :)

Regardless, those nuances should be captured in comments in that
driver:  that for GPIOs that don't support open drain output (only
push/pull drivers), that it's faked by otherwise-unnecessary
tweaking of GPIO direction.

- Dave