Perfect :)
Btw, you mentioned to disable block buffer for I2C block writes in
2.6.24 but I don't see any change regarding it. Is it in
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git
Thanks,
Felix R.
On Mon, Mar 15, 2010 at 12:06 PM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> 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
>
--
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
