Johannes Stezenbach wrote: > On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: >> Johannes Stezenbach wrote: >>> According to linux/Documentation/i2c/i2c-protocol.txt the correct >>> way to get a STOP condition between two I2C messages is send them >>> in seperate I2C transactions. >> I don't find this description in i2c-protocol. > > It's not written explicitly, but it says > you need to use a "Simple send transaction" and/or > a "Simple receive transaction" instead of a > "Combined transaction" if you want a STOP bit > in between. That's how i2c-core is designed. > >> IMHO, it isn't possible >> to split a read request into a single write and a single read request >> outside of the core device. The device must be locked during both >> transfers. If the device isn't locked, it is possible that another >> transfer will change the slave offset before the content is read. This >> may occur with the current implementation. > > If locking is necessary the drivers would need to > handle this explicitely (I think it isn't unless ou start > messing mith /dev/i2c concurrently). even if you do a concurrent operation with /dev/i2c, the i2c bus driver read/write provides concurrency locks, afiacs. Or am i missing something ? > Or you could propose a change to i2c-core to add > a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which > then would have to be implemented by all i2c bus drivers. can't we do this by specifying the length ? say if length = 1 there will be a STOP bit after that transaction with length = 1 (which is the same as I2C_M_NOSTART), so obviously there wouldn't be a repeated start. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb