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

Hartmut Hackmann hartmut.hackmann at t-online.de
Thu Jan 12 00:48:49 CET 2006

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

More information about the linux-dvb mailing list