[i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
xyzzy at speakeasy.org
Mon Apr 21 19:20:17 CEST 2008
On Mon, 21 Apr 2008, Wolfram Sang wrote:
> Trent Piepho wrote:
> > Oh, of course. I had ignored the retries because it seemed like a bad
> > idea. If the timeout is based on time, why does it matter how many tries
> > there were?
> Because then you have a guaranteed number of tries, even if the timeout
> value was reached due to some reason.
Is there a reason to always try at least a certain number of times?
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.
> > 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
> > And on a HZ=100 system, you'll wait at least 60 ms when
> > the timeout only needed to be 25 ms.
> Yes, because there is this policy to retry at least three times. Maybe
> it is an idea to introduce a module parameter which lets the user select
> a suitable retry parameter?
I wouldn't have extra retries. It's part of the chip's specs that there
has to be some delay, exactly how much we don't know, between writes. But
is there an eeprom that says in its specs that writes are unreliable? That
they may fail for no reason and should be tried multiple times?
More information about the i2c