Hi Antti 2011/7/23 Antti Palosaari <crope@xxxxxx>: > On 07/23/2011 02:01 AM, HoP wrote: >> >> 2011/7/23 Antti Palosaari<crope@xxxxxx>: >>> >>> On 07/23/2011 01:47 AM, HoP wrote: >>>> >>>> 2011/7/23 Antti Palosaari<crope@xxxxxx>: >>>>> >>>>> On 07/23/2011 01:18 AM, HoP wrote: >>>>>> >>>>>> In case of i2c write operation there is only one element in msg[] >>>>>> array. >>>>>> Don't access msg[1] in that case. >>>>> >>>>> NACK. >>>>> I suspect you confuse now local msg2 and msg that is passed as function >>>>> parameter. Could you double check and explain? Can you confirm your NACK? As I wrote before, my patch was about read access out of msg[] array parameter of function cxd2820r_tuner_i2c_xfer() in case when msg[] array has only one element (what should be case when using tda18271_write_regs() for example). Or am I still missed something? [snip] > And one point more for I2C implementations, i2c_transfer() should implement > repeated start sequence to messages given. But I am almost sure there is > rather none I2C adapter HW which can do that really. Whole i2c_transfer() Strange enought. Or may better say that linux/i2c.h must fool if you are right, because there you can read: --- linux/i2c.h --- * An i2c_msg is the low level representation of one segment of an I2C * transaction. It is visible to drivers in the @i2c_transfer() procedure, * to userspace from i2c-dev, and to I2C adapter drivers through the * @i2c_adapter.@master_xfer() method. * * Except when I2C "protocol mangling" is used, all I2C adapters implement * the standard rules for I2C transactions. Each transaction begins with a * START. That is followed by the slave address, and a bit encoding read * versus write. Then follow all the data bytes, possibly including a byte * with SMBus PEC. The transfer terminates with a NAK, or when all those * bytes have been transferred and ACKed. If this is the last message in a * group, it is followed by a STOP. Otherwise it is followed by the next * @i2c_msg transaction segment, beginning with a (repeated) START. --- It says quite the reverse - all multimessage transfers have using repeated START. Very annoying. At least for kernel newbies. Regards Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html