On 09/11/11 10:52, Jean Delvare wrote:
On Wed, 09 Nov 2011 12:41:36 +0200, Antti Palosaari wrote:
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.
Also, some adapters _or slaves_ won't support more than one repeated
start in a given transaction, so splitting block reads in continuous
chunks won't always work either. Which makes some sense if you think
about it: if both the slave and the controller supported larger blocks
then there would be no need to split the transfer into multiple
messages in the first place.
Yes, I can immediately think of the stv0288 which can receive up to 108
bytes continuous write of its register map, but using the lme2510c
controller won't write more than 16, probably beyond the limit of the
firmwares buffer.
I think mostly, you are at the mercy of the controller firmware and not
really the host i2c controller abilities.
Regards
Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
