Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol mangling

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

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