[linux-dvb] Possible bug in dib0700_core.c i2c transfer function

Devin Heitmueller devin.heitmueller at gmail.com
Thu Aug 14 20:57:34 CEST 2008

Sent this to Patrick Boettcher last week and didn't hear anything
back.  Figured it might be worth sending to the list to see if anyone
else had any ideas:


I have been doing some work on the Pinnacle PCTV HD Pro USB Stick,
which uses the dib0700/s5h1411/xc5000 combination.  I'm making good
progress but I think I might have run into a bug.

The dib0700_i2c_xfer() function appears to have a problem where it
converts i2c read calls into i2c write calls in certain cases.  In
particular, if you send a single i2c read message, the function always
treats it as a write request.

if (i+1 < num && (msg[i+1].flags & I2C_M_RD)) {
} else {
 buf[0] = REQUEST_I2C_WRITE;

I would assume this would also fail if you sent multiple read messages
(read/read/read as opposed to write/read/write/read).

Was there some design limitation that prevents i2c read calls without
being preceded by a write call?  The dib0700_ctrl_rd() function only
seems to support a read in response to a write call.

The issue manifests itself in xc5000.c in the following case:

static int xc5000_readregs(struct xc5000_priv *priv, u8 *buf, u8 len)
 struct i2c_msg msg = { .addr = priv->cfg->i2c_address,
    .flags = I2C_M_RD, .buf = buf, .len = len };

 if (i2c_transfer(priv->i2c, &msg, 1) != 1) {
   printk(KERN_ERR "xc5000 I2C read failed (len=%i)\n",(int)len);
   return -EREMOTEIO;
 return 0;

I can probably work around it in the xc5000 driver, but this seems
like a pretty fundamental issue with i2c handing.  If this was a
limitation of the hardware design, it might make sense to at least
make the call fail in this case instead of turning it into a write

If anyone has an experience with the dib0700 and has some insight as
to why it does this, I would appreciate it.



Devin J. Heitmueller
AIM: devinheitmueller

More information about the linux-dvb mailing list