[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F967089.3050004@nvidia.com>
Date: Tue, 24 Apr 2012 14:51:13 +0530
From: Laxman Dewangan <ldewangan@...dia.com>
To: Jean Delvare <khali@...ux-fr.org>
CC: "w.sang@...gutronix.de" <w.sang@...gutronix.de>,
"ben-linux@...ff.org" <ben-linux@...ff.org>,
"swarren@...dotorg.org" <swarren@...dotorg.org>,
"olof@...om.net" <olof@...om.net>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol
mangling
On Tuesday 24 April 2012 02:25 PM, Jean Delvare wrote:
> On Tue, 24 Apr 2012 12:49:36 +0530, Laxman Dewangan wrote:
>> Adding support for protocol mangling I2C_M_NOSTART.
>> When multiple message transfer request made through i2c
>> and if any message is flagged with I2C_M_NOSTART then
>> it will not send the start/repeat start/address of that
>> message i.e. send the data directly.
>>
>> Signed-off-by: Laxman Dewangan<ldewangan@...dia.com>
>> ---
>> drivers/i2c/busses/i2c-tegra.c | 32 +++++++++++++++++++++++++++-----
>> 1 files changed, 27 insertions(+), 5 deletions(-)
> What do you need this for?
>
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.
Including Mark B here for more comment/insight.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists