Hi, Tim
Tim Small wrote:
> Hartmut Hackmann wrote:
>
>> I know the I2C bus and have saa7134 documentation. But i have no
>> experience
>> with the MT352. The errata sheet does not mention a I2C bug. But the lost
>> arbitration is interesting. Assuming there is only one master on the bus,
>
>
> I have had a quick look at the 7134 I2C driver - I might not have time
> to do more work on it soon, so I thought I'd better share a couple of
> possible problems that I've noticed:
>
> I haven't checked this against the 7134 datasheet, but:
>
> Line 258 : if (!(msgs[i].flags & I2C_M_NOSTART) || 0 ==
> i) {
>
> Seems to say that "START", "ADDRESS" should only be sent on the first
> message of an i2c transaction (0 == i), this would seem to disagree with
> Documentation/i2c/i2c_protocol (maybe the 7134 does something clever
> automatically, I didn't check).
>
That's correct. A transaction continues until a stop or a new start condition
is transferred. Gaps between transaction fragments don't matter.
> Also, the transfer is not restarted in a lost arbitration condition (not
> sure if this is a bug or not - maybe it's the job of the client driver
> to do this - I'm not sure)
>
Indeed. But an arbiration loss can only occur when there is more than one
master on the bus. This normally is not the case. But if the MT352 can
act as a master, this is a problem. If you turn i2c_debug on, do you see
arbitration losses?
> The first problem might possibly cause trouble if the 352 driver
> switched to using multi-message i2c transactions, rather than single
> message
>
I haven't read the doc yet, what is this?
>> this indicates that there either is wild oscillation or a protocol
>> problem
>> with the MT352 resp. the card. Did somebody try to slow down the bus?
>
>
> The 7134 only seems to support 100kHz, or 400kHz operation. I haven't
> yet verified that the driver is always using 100kHz mode at the moment
> tho', or seen if there is a way to to force the i2c hardware to wait
> around. I'll try and do some more on this in the next couple of days.
>
Yep i meanwhile found this myself, it runs at 100kHz.
BTW: I inserted a msleep between 2 transactions some months ago to ensure
a sufficient time between stop and next start condition. you might try
to replace the msleep by a 10usec udelay...
Best regards
Hartmut
