Hi Laxman, Mark, On Tue, 24 Apr 2012 14:51:13 +0530, Laxman Dewangan wrote: > The primary use-case here is scatter-gather of multiple I2C messages; > the first message will contain the START and perhaps some transfers, > then subsequent messages will continue with more data transfers. This > removes the need to put all the data transfers into a single message, > and hence avoids some copying of commands/data. > > Mark Brown says this is important for regmap. This feature is implement > gather support for I2C transfers - the resulting I2C transfer is > entirely normal but this ends up being implemented by the controller > doing two transfers back to back with no start on the second transfer. > To the outside world it looks like a perfectly normal transfer. This > behaviour can be emulated by allocating a buffer and coalescing the data > into that buffer before sending it to the hardware but this introduces > an avoidable and sometimes noticeable overhead. Please keep in mind that support for I2C_M_NOSTART at the bus driver level is optional. This means that device drivers are encouraged to not rely on it unconditionally. Originally the flag was meant to workaround bogus hardware (the infamous Matrox Maven if memory serves) which changed the transfer direction without a repeated start in the middle (which is not allowed by the I2C specification.) It wasn't meant to be implemented and used widely (as written in Documentation/i2c/i2c-protocol), which is why it is one of the I2C_FUNC_PROTOCOL_MANGLING features rather than having its own I2C functionality flag. If you want to do scatter-gather for I2C messages, I understand the benefit and I have no objection, and I agree that I2C_M_NOSTART lets you do that, but then: * We should allocate a new functionality flag for it. * We should update the documentation to reflect the two use cases. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
