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 call. If anyone has an experience with the dib0700 and has some insight as to why it does this, I would appreciate it. Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb