[linux-dvb] Pinnacle PCTV (Dazzle) 300i maybe i2c problems with newer code?

[Hartmut Hackmann]

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