[i2c] problem with DS1337 RTC connected to Cirrus Logic EP93XX
Jean Delvare
khali at linux-fr.org
Sat May 5 19:00:24 CEST 2007
Hi Lennert,
On Fri, 4 May 2007 17:25:26 +0200, Lennert Buytenhek wrote:
> On Fri, May 04, 2007 at 03:39:35PM +0200, Jean Delvare wrote:
> > > The latest one I have is:
> > >
> > > http://svn.wantstofly.org/kernel/ep93xx-i2c-bus.diff
> > >
> > > This seems like a nice opportunity to pimp the driver for
> > > upstream inclusion. I've attached it below. How does it look?
> > > (...)
> > > I2C bus driver using ep93xx GPIOs.
> >
> > We will have a brand new generic I2C-over-GPIO driver in 2.6.22. As
> > the i2c-ep93xx driver relies on GPIO as well, I'd like you to look
> > into the generic driver and see how you could use it instead.
>
> Well, for one, the generic i2c gpio driver seems to use the generic
> GPIO API, which was broken to begin with, and should never have been
> merged. There have been valid arguments against its inclusion, and
> I don't want to promote use of this broken API on ep93xx.
I wasn't aware of any problem with the generic GPIO API. Care to point
me to the objections? Can't they be addressed?
> Another issue is that the ep93xx i2c driver supports sharing the i2c
> bus with non-i2c agents (this is required for several ep93xx boards),
> while the generic i2c gpio driver doesn't seem to support this.
What a weird design decision :( Hardware people seem to always come up
with weirder design, it's hardly believable.
Either way, you're right that i2c-gpio wouldn't support that, but your
implementation looks rather hackish and inefficient. Granted,
i2c-algo-bit doesn't offer you the possibility of a cleaner
implementation at the moment, but this could be discussed.
What about adding pre-xfer and post-xfer callbacks to struct
i2c_algo_bit_data? When defined, these could be called at the beginning
and end of i2c-algo-bit:bit_xfer(), respectively. Then I guess it
wouldn't be too hard to add support to i2c-gpio, too.
> If having upstream i2c support on ep93xx requires adapting the
> code to a broken API, then no thanks, I'll maintain ep93xx i2c
> support out-of-tree then.
--
Jean Delvare
More information about the i2c
mailing list