[i2c] [PATCH] Add a new-style driver for most I2C EEPROMs

[Wolfram Sang]

On Mon, Apr 21, 2008 at 10:20:17AM -0700, Trent Piepho wrote:

> If it hasn't been long enough since the last write, the next write
> isn't suppose to work.  That's the expected operation of the device.
> But if it has been long enough, and the write still fails, then it
> seems to me that the behavior has changed from normal operation to an
> error.
I think you got a point there (unless someone gained experience that
retries do help for some quirky chips or other cases).

> > > Still, if you want to wait at least 25 ms, on a HZ=1000 system you
> > > might wait only 3 ms.
> > I'm sorry, I fail to see this. If there are more than three retries,
> > then there is still the time_before-condition which keeps the loop
> > running until the timeout is reached, no?
> Except for the timing problem I pointed out before.  The timeout is
> checked before the write takes place.  So if after the 3rd attempt the
> msleep(), or kernel preemption, etc., delays for 22 ms or more, the
> next write will never happen.
Got it now, I misunderstood you before. We do wait 25ms in total, it is
just that the last write-try happened at 3ms. This is indeed bad. The
following code should handle it better. (Skipping retries for now)

---
	timeout = jiffies + msecs_to_jiffies(write_timeout);
	do {
		keep_trying = time_before(jiffies, timeout);

		transfer();

		if (success)
			return count;

		msleep(1);
	} while (keep_trying);

	return -ETIMEDOUT;
---

Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.lm-sensors.org/pipermail/i2c/attachments/20080424/f9d56f2e/attachment.bin