On Mon, 15 Mar 2010 11:43:48 +0200, Felix Rubinstein wrote:
> Hi Jean,
>
> On Fri, Mar 12, 2010 at 6:24 PM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> > FWIW, testing on my ICH3-M (SMBus block read), I get a delay between
> > bytes of 460 us. This is a maximum bus speed of 19.6 kHz. Same test on
> > an ICH5 reports a delay of 670 us, which would be 13.5 kHz max. I have
> > a hard time believing that you got delays below 100 us on your ICH9...
> >
> > Also note that, in both cases, the first delay is always much larger,
> > as the controller must send the beginning of the transaction up to the
> > second data byte. The SMBus block read is the worst case scenario, as
> > it must first send an address byte, the command byte, then the address
> > byte again (direction change), then it reads the block length and
> > finally the first data byte. This is 45 bits on the wire, not counting
> > the start conditions. I get a ~2380 us delay on ICH3-M and ~3420 us
> > delay on ICH5.
> >
> > So changing the code the way you suggested isn't trivial. Busy-waiting
> > for up to 3500 us for the first transaction isn't very appealing.
> > Busy-waiting for a total of 3500 + 670 * 31 (worst case) = 24270 us or
> > almost 25 ms, is hardly pleasant either, latency will suffer, it's
> > almost worse than software bit-banging. Now I have to agree that the
> > current implementation ("long" sleeps) isn't good either. Maybe the
> > msleep(0) approach would be the least evil... Oh well, at some point we
> > really want to switch to interrupts.
>
> Thanks for prompt reply :)
> I'll provided more number later on, once I get to it in the lab.
> I have it in my mind to dig into ICH9 data sheet (for the start) to
> add interrupt support.
> Btw, have anyone started it?
Oh yes, twice. Mark M. Hoffman tried first, with a brand new driver.
Then Ivo Manca (Cc'd) gave it a try, this time modifying the existing
driver.
The problem with Mark's implementation was that it lacked support for
block transactions, so we couldn't replace the original driver with
his. We did not want to maintain two drivers in parallel, and block
support was never added to the new driver, so Mark's driver did not go
anywhere.
The problem with Ivo's work was that the driver would lock up the bus in
some cases (I can't remember the details any longer, sorry) and we did
not manage to solve this bug. This issue blocked further integration,
and once again the efforts were lost. I can provide Ivo's latest
patches if you want to see what they looked like. With some work, it
should be possible to get them to apply again. I would much prefer
fixing Ivo's patches than starting from scratch again.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
