Re: [PATCH 3/8 v3] i2c: i801: check INTR after every transaction

[Jean Delvare]

On Mon, 2 Jul 2012 09:19:24 +0800, Daniel Kurtz wrote:
> On Mon, Jul 2, 2012 at 5:20 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> > I've done some performance measurements, and it turns out that, with the
> > version of this patch modified by me, all short transactions are twice
> > as slow as before. This is because i801_transaction waits twice now:
> > once for BUSY to be clear, and then again once for INTR to be set.
> 
> Does a fast sequence of such transactions actually take any longer? Or
> just a single short transaction?

Both are affected, this is the problem. See:

Original driver:

# time i2cdump -y 8 0x2f b >/dev/null

real	0m0.157s
user	0m0.000s
sys	0m0.010s

After this patch:

# time i2cdump -y 8 0x2f b >/dev/null

real	0m0.279s
user	0m0.003s
sys	0m0.011s

This is on a fast machine with recent kernel. On my ICH3-M laptop with
kernel 2.6.32, the slowdown for a full register dump is from 2 seconds
to 4 seconds. Big performance regression.

> My understanding is that the INTR wait is really waiting for the
> entire transaction to complete (ie., including i2c STOP condition),
> not just the byte transfer phase.

This is my understanding as well, but I'm fairly certain that this is
the case of the BUSY flag as well. I think BUSY gets cleared at the
same time INTR (or any of the error status bits) gets set. Which is why
I think checking BUSY is redundant. As a matter of fact, we ignore BUSY
completely in i801_block_transaction_byte_by_byte(), so I see no reason
why we couldn't do the same in i2c_transaction().

> By waiting here at the end of a transaction, we make sure the status
> bits are actually clear before starting the next transaction.

I have no objection to clearing the status bits, simply I think the
sequence is wrong. I'll write and post a RFC patch later today
illustrating what I think should be done.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/