On 11/09/2011 11:56 AM, Mauro Carvalho Chehab wrote:
Due to the way I2C locks are bound, doing something like the above and something like:
struct i2c_msg msg[2] = {
{
.addr = i2c_cfg->addr,
.flags = 0,
.buf = buf,
},
{
.addr = i2c_cfg->addr,
.flags = 0,
.buf = buf2,
}
};
ret = i2c_transfer(i2c_cfg->adapter, msg, 2);
Produces a different result. In the latter case, I2C core avoids having any other
transaction in the middle of the 2 messages.
In my understanding adding more messages than one means those should be
handled as one I2C transaction using REPEATED START.
I see one big problem here, it is our adapters. I think again, for the
experience I have, most of our I2C-adapters can do only 3 different
types of I2C xfers;
* I2C write
* I2C write + I2C read (combined with REPEATED START)
* I2C read (I suspect many adapters does not support that)
That means, I2C REPEATED writes are not possible.
I like the idea of having some functions to help handling those cases where a single
transaction needs to be split into several messages.
Yet, I agree with Michael: I would add such logic inside the I2C subsystem, and
being sure that the lock is kept during the entire I2C operation.
Jean,
Thoughts?
regards
Antti
--
http://palosaari.fi/
--
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
