[lkml]   [2012]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol mangling
    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.

    Jean Delvare

     \ /
      Last update: 2012-04-24 14:35    [W:0.026 / U:7.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site