tags:

views:

611

answers:

2

The lackluster response here made me wonder this.

I've been saddled with a device (Analog Devices 525x) that (from the data sheet, pg 16):

disables the I2C interface during the internal [EEPROM] write cycle.

That doesn't seem fair, as in "I'm getting off the couch now, so don't use it for a while because I let one rip in the seat cushion". Honestly, why should that be my problem?

Anyway, the data sheet suggests that acknowledge polling is the answer - enter the Linux kernel... does the Linux GPIO bit bashed I2C driver provide a mechanism for doing this? Essentially send a address with the write bit set and keep doing so until an ACK appears.

I'm using 2.6.14 on an ARM with back ported GPIO bit bashing driver (from 2.6.19 I think).

A: 

Sounds like you need to rewrite the kernel driver for the I2C system to allow this?

Also, what about upgrading the kernel and see what has happened since 2.6.14 which is a pretty old kernel version by now.

jakobengblom2
It's a proprietary thing shipped with the platform; it'd be quite an effort to forward port all the discrete changes. 2.6.14.++ is behaving reasonably so there isn't much incentive beyond what's posted here.
Jamie
+1  A: 

It doesn't seem too off the shelf, but

You probably will need to look at having a protocol modification flag like Flag I2C_M_NOSTART only different, in your patches. At least there is a way to do it (admittedly a messy way)

I hope for your sake you don't need to put a normal i2c device on the same bus.

Honestly, hardware vendors do stuff like this all the time. They consider the problem "solved" as long as it becomes yours.

I see lots of broken I2C out there and you could make life nicer for other people.

Tim Williscroft