[i2c] [PATCH 2 of 2] Adding an abort function to unwedge MCP51/55

Jean Delvare khali at linux-fr.org
Mon Oct 8 19:24:39 CEST 2007


Hi Oleg,

On Sun, 7 Oct 2007 02:21:52 -0400, Oleg Ryjkov wrote:
> Hi Jean,
> > On Fri, 31 Aug 2007 00:21:33 -0700, Oleg Ryjkov wrote:
> > > This patch is to add an abort function that will bring back the MCP51/55
> > > controller if it was blocked by a block-read operation, in particular.
> > > (When a slave sends a wrong byte count on a byte read, the host gets
> > > locked up). I've only tested it on an MCP51 and MCP55. However, I'm
> > > almost certain it will also work on MCP65, I just did not have the board
> > > to test it on. Thus I for now the abort function will only be called
> > > if an MCP51/55 was detected.
> > 
> > Given that we currently allow block transactions only for the MCP51/55
> > (why, BTW?) it's fine to only implement the abort capability for these
> > chips. When we support block transactions for other chips, we will have
> > to support abort for these as well.
> The reason that I only do the abort on MCP51/55 is that I had to way of
> testing this feature on other controllers. Though I am fairly sure that
> it is implemented on most of nvidia chips.

> (...)
> > Do you think there's any chance that the abort feature will work on my
> > nForce2? I could test your patch there.
>
> As I said above, I definitely think that it is worth a shot. If you do
> try it, please let me know of the results.

I did. My nForce2 reacts fine with your patch. As you know, I can
trigger a SMBus timeout with a 32-byte SMBus block read. Previously
this was locking the SMBus controller, now I can go on with other
commands. So I think that we can add the nForce2 (10de:0064) to the
list of adapters that support abort. Given that this is the older
chipset supported by the i2c-nforce2 driver, my guess now is that all
chipsets support abort, meaning that we don't even need the can_abort
flag. What do you think?

Another thing worth noting is that the message "Transaction failed
(received block size: 0x%02x)" never shows. The high 3 bits of the
length byte are seemingly discarded, so for example a length byte of
0x65 results in 5 bytes being read. This means that the received length
is always between 0 and 31. This probably explains why 32-byte block
reads are a problem: they are in fact 0-byte block reads, which aren't
valid. Design flaw... Not sure if it's fixed in the latest chipsets?

-- 
Jean Delvare



More information about the i2c mailing list