On 12-04-06 02:37 AM, Jean Delvare wrote:
> On Thu, 05 Apr 2012 20:01:43 -0400, Douglas Gilbert wrote:
>> On 12-04-05 03:24 AM, Jean Delvare wrote:
>>> As the bus driver side implementation of I2C_M_RECV_LEN is heavily
>>> tied to SMBus, we can't support received length over 32 bytes, but
>>> let's at least support that.
>>>
>>> In practice, the caller will have to setup a buffer large enough to
>>> cover the case where received length byte has value 32, so minimum
>>> 32 + 1 = 33 bytes, possibly more if there is a fixed number of bytes
>>> added for the specific slave (for example a checksum.)
>>
>> Either I am misunderstanding how to use this new patch or it is
>> broken. After replacing the original patch with this one, setting
>> msg->buf[0] to 2, my test program only sees the first two bytes
>> of expected data:
>>     08 81
>> That is down from 8 bytes from the previous patch and 10 bytes
>> expected from the SM130.
>
> Does your I2C bus driver process I2C_M_RECV_LEN at all? I bet not.
> You'll have to fix that. It's fairly easy, see the reference
> implementation in i2c-algo-bit.c:readbytes(). The completely untested
> attempt below may do, if not you'll have to fix my code:

Jean,
Yes again, the modified i2c-at91.c driver that I am using does not
have support for I2C_M_RECV_LEN.

However stepping back from the minor I2C_M_RECV_LEN issue and looking
directly at the i2c-at91 driver itself. My patch to this broken
driver is included below and applies clean against lk 3.2.8
(but I note that it needs work to apply against lk 3.3). My patch
works for the AT91SAM9G20 and I have positive feedback from
the users of board-foxg20 based on that MCU.

However I see that Nikolaus Voss has submitted a replacement driver
for the i2c-at91 that works for the G45 which has two TWI units.
Is that driver going into the mainline? Surely it is much better
than the broken i2c-at91 driver that has been sitting broken for
way too long. Atmel are bringing out new MCUs in that family which
have 3 TWI units (e.g. AT91SAM9G25). Apart from the limitations
about repeated starts surely Atmel have fixed the problems referred
to in existing mainline i2c-at91.c driver from circa 2006.

My vote would be to add Nikolaus Voss's driver ASAP.

Doug Gilbert