On 12-04-06 12:25 PM, Jean Delvare wrote:
On Fri, 06 Apr 2012 12:16:19 -0400, Douglas Gilbert wrote:
Yes again, the modified i2c-at91.c driver that I am using does not
have support for I2C_M_RECV_LEN.
Did you try my patch?
No. I didn't realize it was on top of my patches to the
i2c-at91 driver, sorry.
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.
I picked this patch from your website already, and forward ported it,
my own patch was on top of yours.
So I have now applied your patch over my patch to the i2c-at91
driver and tested it. The result is the same as the previous
iteration: only two non-zero bytes: "08 81".
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.
I'm not into embedded devices, so this isn't my call.
A pity. I checked lk 3.4-rc1 and the bad old driver is still there.
Doug Gilbert
--
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
