[PATCH V1 0/2] i2c: tegra: 10 bit and M_NOSTART support

[PATCH V1 0/2] i2c: tegra: 10 bit and M_NOSTART support

[Laxman Dewangan]

Adding support for i2c protocoal mangling M_NOSTART and
fixes bug for 10 bit address configuration.

Laxman Dewangan (2):
  i2c: tegra: fix 10bit address configuration
  i2c: tegra: support for I2C_M_NOSTART protocol mangling

 drivers/i2c/busses/i2c-tegra.c |   41 ++++++++++++++++++++++++++++++++-------
 1 files changed, 33 insertions(+), 8 deletions(-)

[PATCH V1 0/2] i2c: tegra: 10 bit and M_NOSTART support

[Laxman Dewangan]

Adding support for i2c protocoal mangling M_NOSTART and
fixes bug for 10 bit address configuration.

Laxman Dewangan (2):
  i2c: tegra: fix 10bit address configuration
  i2c: tegra: support for I2C_M_NOSTART protocol mangling

 drivers/i2c/busses/i2c-tegra.c |   41 ++++++++++++++++++++++++++++++++-------
 1 files changed, 33 insertions(+), 8 deletions(-)

[PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Laxman Dewangan]

The slave address of device to be configured in packet
header as follows:
    7 bit address: PacketHeader3[7:1]
    10 bit address: PacketHeader3[9:0]

Fixing the code to make packet header3 properly.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/i2c/busses/i2c-tegra.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 55e5ea6..18067b3 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -476,12 +476,15 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
 	packet_header = msg->len - 1;
 	i2c_writel(i2c_dev, packet_header, I2C_TX_FIFO);
 
-	packet_header = msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
-	packet_header |= I2C_HEADER_IE_ENABLE;
+	packet_header = I2C_HEADER_IE_ENABLE;
 	if (!stop)
 		packet_header |= I2C_HEADER_REPEAT_START;
-	if (msg->flags & I2C_M_TEN)
+	if (msg->flags & I2C_M_TEN) {
+		packet_header |= msg->addr;
 		packet_header |= I2C_HEADER_10BIT_ADDR;
+	} else {
+		packet_header |= msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
+	}
 	if (msg->flags & I2C_M_IGNORE_NAK)
 		packet_header |= I2C_HEADER_CONT_ON_NAK;
 	if (msg->flags & I2C_M_RD)
@@ -557,7 +560,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 
 static u32 tegra_i2c_func(struct i2c_adapter *adap)
 {
-	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
 }
 
 static const struct i2c_algorithm tegra_i2c_algo = {
-- 
1.7.1.1

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Jean Delvare]

On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
> The slave address of device to be configured in packet
> header as follows:
>     7 bit address: PacketHeader3[7:1]
>     10 bit address: PacketHeader3[9:0]
> 
> Fixing the code to make packet header3 properly.
> 
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> ---
>  drivers/i2c/busses/i2c-tegra.c |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 55e5ea6..18067b3 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -476,12 +476,15 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
>  	packet_header = msg->len - 1;
>  	i2c_writel(i2c_dev, packet_header, I2C_TX_FIFO);
>  
> -	packet_header = msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
> -	packet_header |= I2C_HEADER_IE_ENABLE;
> +	packet_header = I2C_HEADER_IE_ENABLE;
>  	if (!stop)
>  		packet_header |= I2C_HEADER_REPEAT_START;
> -	if (msg->flags & I2C_M_TEN)
> +	if (msg->flags & I2C_M_TEN) {
> +		packet_header |= msg->addr;
>  		packet_header |= I2C_HEADER_10BIT_ADDR;
> +	} else {
> +		packet_header |= msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
> +	}
>  	if (msg->flags & I2C_M_IGNORE_NAK)
>  		packet_header |= I2C_HEADER_CONT_ON_NAK;
>  	if (msg->flags & I2C_M_RD)
> @@ -557,7 +560,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
>  
>  static u32 tegra_i2c_func(struct i2c_adapter *adap)
>  {
> -	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> +	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
>  }
>  
>  static const struct i2c_algorithm tegra_i2c_algo = {

Looks good.

Acked-by: Jean Delvare <khali@linux-fr.org>

Not that 10-bit address devices are immensely popular though...

-- 
Jean Delvare

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Jean Delvare]

On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
> The slave address of device to be configured in packet
> header as follows:
>     7 bit address: PacketHeader3[7:1]
>     10 bit address: PacketHeader3[9:0]
> 
> Fixing the code to make packet header3 properly.
> 
> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/i2c/busses/i2c-tegra.c |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 55e5ea6..18067b3 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -476,12 +476,15 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
>  	packet_header = msg->len - 1;
>  	i2c_writel(i2c_dev, packet_header, I2C_TX_FIFO);
>  
> -	packet_header = msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
> -	packet_header |= I2C_HEADER_IE_ENABLE;
> +	packet_header = I2C_HEADER_IE_ENABLE;
>  	if (!stop)
>  		packet_header |= I2C_HEADER_REPEAT_START;
> -	if (msg->flags & I2C_M_TEN)
> +	if (msg->flags & I2C_M_TEN) {
> +		packet_header |= msg->addr;
>  		packet_header |= I2C_HEADER_10BIT_ADDR;
> +	} else {
> +		packet_header |= msg->addr << I2C_HEADER_SLAVE_ADDR_SHIFT;
> +	}
>  	if (msg->flags & I2C_M_IGNORE_NAK)
>  		packet_header |= I2C_HEADER_CONT_ON_NAK;
>  	if (msg->flags & I2C_M_RD)
> @@ -557,7 +560,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
>  
>  static u32 tegra_i2c_func(struct i2c_adapter *adap)
>  {
> -	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> +	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
>  }
>  
>  static const struct i2c_algorithm tegra_i2c_algo = {

Looks good.

Acked-by: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>

Not that 10-bit address devices are immensely popular though...

-- 
Jean Delvare

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Laxman Dewangan]

On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
> On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
>> The slave address of device to be configured in packet
>> header as follows:
>>      7 bit address: PacketHeader3[7:1]
>>      10 bit address: PacketHeader3[9:0]
>>
>> Fixing the code to make packet header3 properly.
>>
>> Signed-off-by: Laxman Dewangan<ldewangan@nvidia.com>
>> ---
>>
>>   
> Looks good.
>
> Acked-by: Jean Delvare<khali@linux-fr.org>
>
Hi Wolfram Sang,
Can it be apply? This is independent of other change in this series 
which is under discussion/review.

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Laxman Dewangan]

On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
> On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
>> The slave address of device to be configured in packet
>> header as follows:
>>      7 bit address: PacketHeader3[7:1]
>>      10 bit address: PacketHeader3[9:0]
>>
>> Fixing the code to make packet header3 properly.
>>
>> Signed-off-by: Laxman Dewangan<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>
>>   
> Looks good.
>
> Acked-by: Jean Delvare<khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
>
Hi Wolfram Sang,
Can it be apply? This is independent of other change in this series 
which is under discussion/review.

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Thu, May 03, 2012 at 11:43:14AM +0530, Laxman Dewangan wrote:
> On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
> >On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
> >>The slave address of device to be configured in packet
> >>header as follows:
> >>     7 bit address: PacketHeader3[7:1]
> >>     10 bit address: PacketHeader3[9:0]
> >>
> >>Fixing the code to make packet header3 properly.
> >>
> >>Signed-off-by: Laxman Dewangan<ldewangan@nvidia.com>
> >>---
> >>
> >Looks good.
> >
> >Acked-by: Jean Delvare<khali@linux-fr.org>
> >
> Can it be apply? This is independent of other change in this series
> which is under discussion/review.

Applied to next. Or do you need it in 3.4?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Thu, May 03, 2012 at 11:43:14AM +0530, Laxman Dewangan wrote:
> On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
> >On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
> >>The slave address of device to be configured in packet
> >>header as follows:
> >>     7 bit address: PacketHeader3[7:1]
> >>     10 bit address: PacketHeader3[9:0]
> >>
> >>Fixing the code to make packet header3 properly.
> >>
> >>Signed-off-by: Laxman Dewangan<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >>---
> >>
> >Looks good.
> >
> >Acked-by: Jean Delvare<khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> >
> Can it be apply? This is independent of other change in this series
> which is under discussion/review.

Applied to next. Or do you need it in 3.4?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Laxman Dewangan]

On Thursday 03 May 2012 01:48 PM, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
> On Thu, May 03, 2012 at 11:43:14AM +0530, Laxman Dewangan wrote:
>> On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
>>> On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
>>>> The slave address of device to be configured in packet
>>>> header as follows:
>>>>      7 bit address: PacketHeader3[7:1]
>>>>      10 bit address: PacketHeader3[9:0]
>>>>
>>>> Fixing the code to make packet header3 properly.
>>>>
>>>> Signed-off-by: Laxman Dewangan<ldewangan@nvidia.com>
>>>> ---
>>>>
>>> Looks good.
>>>
>>> Acked-by: Jean Delvare<khali@linux-fr.org>
>>>
>> Can it be apply? This is independent of other change in this series
>> which is under discussion/review.
> Applied to next. Or do you need it in 3.4?
>
I dont need it on 3.4. It is fine to apply for next only.

Re: [PATCH V1 1/2] i2c: tegra: fix 10bit address configuration

[Laxman Dewangan]

On Thursday 03 May 2012 01:48 PM, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
> On Thu, May 03, 2012 at 11:43:14AM +0530, Laxman Dewangan wrote:
>> On Tuesday 24 April 2012 02:28 PM, Jean Delvare wrote:
>>> On Tue, 24 Apr 2012 12:49:35 +0530, Laxman Dewangan wrote:
>>>> The slave address of device to be configured in packet
>>>> header as follows:
>>>>      7 bit address: PacketHeader3[7:1]
>>>>      10 bit address: PacketHeader3[9:0]
>>>>
>>>> Fixing the code to make packet header3 properly.
>>>>
>>>> Signed-off-by: Laxman Dewangan<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>>
>>> Looks good.
>>>
>>> Acked-by: Jean Delvare<khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
>>>
>> Can it be apply? This is independent of other change in this series
>> which is under discussion/review.
> Applied to next. Or do you need it in 3.4?
>
I dont need it on 3.4. It is fine to apply for next only.

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

[Laxman Dewangan]

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@nvidia.com>
---
 drivers/i2c/busses/i2c-tegra.c |   32 +++++++++++++++++++++++++++-----
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 18067b3..a50e4c4 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -97,8 +97,21 @@
 #define I2C_HEADER_10BIT_ADDR			(1<<18)
 #define I2C_HEADER_IE_ENABLE			(1<<17)
 #define I2C_HEADER_REPEAT_START			(1<<16)
+#define I2C_HEADER_CONTINUE_XFER		(1<<15)
 #define I2C_HEADER_MASTER_ADDR_SHIFT		12
 #define I2C_HEADER_SLAVE_ADDR_SHIFT		1
+/*
+ * msg_end_type: The bus control which need to be send at end of transfer.
+ * @MSG_END_STOP: Send stop pulse at end of transfer.
+ * @MSG_END_REPEAT_START: Send repeat start at end of transfer.
+ * @MSG_END_CONTINUE: The following on message is coming and so do not send
+ *		stop or repeat start.
+ */
+enum msg_end_type {
+	MSG_END_STOP,
+	MSG_END_REPEAT_START,
+	MSG_END_CONTINUE,
+};
 
 /**
  * struct tegra_i2c_dev	- per device i2c context
@@ -450,7 +463,7 @@ err:
 }
 
 static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
-	struct i2c_msg *msg, int stop)
+	struct i2c_msg *msg, enum msg_end_type end_state)
 {
 	u32 packet_header;
 	u32 int_mask;
@@ -477,7 +490,9 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
 	i2c_writel(i2c_dev, packet_header, I2C_TX_FIFO);
 
 	packet_header = I2C_HEADER_IE_ENABLE;
-	if (!stop)
+	if (end_state == MSG_END_CONTINUE)
+		packet_header |= I2C_HEADER_CONTINUE_XFER;
+	else if (end_state == MSG_END_REPEAT_START)
 		packet_header |= I2C_HEADER_REPEAT_START;
 	if (msg->flags & I2C_M_TEN) {
 		packet_header |= msg->addr;
@@ -549,8 +564,14 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 
 	clk_enable(i2c_dev->clk);
 	for (i = 0; i < num; i++) {
-		int stop = (i == (num - 1)) ? 1  : 0;
-		ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], stop);
+		enum msg_end_type end_type = MSG_END_STOP;
+		if (i < (num - 1)) {
+			if (msgs[i + 1].flags & I2C_M_NOSTART)
+				end_type = MSG_END_CONTINUE;
+			else
+				end_type = MSG_END_REPEAT_START;
+		}
+		ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type);
 		if (ret)
 			break;
 	}
@@ -560,7 +581,8 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 
 static u32 tegra_i2c_func(struct i2c_adapter *adap)
 {
-	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
+			I2C_FUNC_PROTOCOL_MANGLING;
 }
 
 static const struct i2c_algorithm tegra_i2c_algo = {
-- 
1.7.1.1

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

[Laxman Dewangan]

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 drivers/i2c/busses/i2c-tegra.c |   32 +++++++++++++++++++++++++++-----
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 18067b3..a50e4c4 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -97,8 +97,21 @@
 #define I2C_HEADER_10BIT_ADDR			(1<<18)
 #define I2C_HEADER_IE_ENABLE			(1<<17)
 #define I2C_HEADER_REPEAT_START			(1<<16)
+#define I2C_HEADER_CONTINUE_XFER		(1<<15)
 #define I2C_HEADER_MASTER_ADDR_SHIFT		12
 #define I2C_HEADER_SLAVE_ADDR_SHIFT		1
+/*
+ * msg_end_type: The bus control which need to be send at end of transfer.
+ * @MSG_END_STOP: Send stop pulse at end of transfer.
+ * @MSG_END_REPEAT_START: Send repeat start at end of transfer.
+ * @MSG_END_CONTINUE: The following on message is coming and so do not send
+ *		stop or repeat start.
+ */
+enum msg_end_type {
+	MSG_END_STOP,
+	MSG_END_REPEAT_START,
+	MSG_END_CONTINUE,
+};
 
 /**
  * struct tegra_i2c_dev	- per device i2c context
@@ -450,7 +463,7 @@ err:
 }
 
 static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
-	struct i2c_msg *msg, int stop)
+	struct i2c_msg *msg, enum msg_end_type end_state)
 {
 	u32 packet_header;
 	u32 int_mask;
@@ -477,7 +490,9 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
 	i2c_writel(i2c_dev, packet_header, I2C_TX_FIFO);
 
 	packet_header = I2C_HEADER_IE_ENABLE;
-	if (!stop)
+	if (end_state == MSG_END_CONTINUE)
+		packet_header |= I2C_HEADER_CONTINUE_XFER;
+	else if (end_state == MSG_END_REPEAT_START)
 		packet_header |= I2C_HEADER_REPEAT_START;
 	if (msg->flags & I2C_M_TEN) {
 		packet_header |= msg->addr;
@@ -549,8 +564,14 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 
 	clk_enable(i2c_dev->clk);
 	for (i = 0; i < num; i++) {
-		int stop = (i == (num - 1)) ? 1  : 0;
-		ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], stop);
+		enum msg_end_type end_type = MSG_END_STOP;
+		if (i < (num - 1)) {
+			if (msgs[i + 1].flags & I2C_M_NOSTART)
+				end_type = MSG_END_CONTINUE;
+			else
+				end_type = MSG_END_REPEAT_START;
+		}
+		ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type);
 		if (ret)
 			break;
 	}
@@ -560,7 +581,8 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 
 static u32 tegra_i2c_func(struct i2c_adapter *adap)
 {
-	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
+			I2C_FUNC_PROTOCOL_MANGLING;
 }
 
 static const struct i2c_algorithm tegra_i2c_algo = {
-- 
1.7.1.1

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

[Jean Delvare]

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@nvidia.com>
> ---
>  drivers/i2c/busses/i2c-tegra.c |   32 +++++++++++++++++++++++++++-----
>  1 files changed, 27 insertions(+), 5 deletions(-)

What do you need this for?

-- 
Jean Delvare

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

[Jean Delvare]

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/i2c/busses/i2c-tegra.c |   32 +++++++++++++++++++++++++++-----
>  1 files changed, 27 insertions(+), 5 deletions(-)

What do you need this for?

-- 
Jean Delvare

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

[Laxman Dewangan]

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@nvidia.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.

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

[Laxman Dewangan]

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>   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.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Tue, Apr 24, 2012 at 02:51:13PM +0530, Laxman Dewangan wrote:
> On Tuesday 24 April 2012 02:25 PM, Jean Delvare 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.

> >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.

I'm sure I've seen that block of text somewhere before :)

This is it, you've got some big blob like a firmware image somewhere 
or perhaps even just a small block of data to write in one and you want
to put a register address on the front and send it.  It's much easier
and slightly faster if you can avoid having to allocate a temporary
buffer - not so much for I2C per se (it's generally very slow after all)
as for the overall system, often when you're doing this stuff when the
system is generally very busy so it's helpful to avoid introducing
needless extra work.

In the grand scheme it's not the end of the world if it's missing but
if the hardware supports it we may as well use it, it's usually just
setting a single register bit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Tue, Apr 24, 2012 at 02:51:13PM +0530, Laxman Dewangan wrote:
> On Tuesday 24 April 2012 02:25 PM, Jean Delvare 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.

> >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.

I'm sure I've seen that block of text somewhere before :)

This is it, you've got some big blob like a firmware image somewhere 
or perhaps even just a small block of data to write in one and you want
to put a register address on the front and send it.  It's much easier
and slightly faster if you can avoid having to allocate a temporary
buffer - not so much for I2C per se (it's generally very slow after all)
as for the overall system, often when you're doing this stuff when the
system is generally very busy so it's helpful to avoid introducing
needless extra work.

In the grand scheme it's not the end of the world if it's missing but
if the hardware supports it we may as well use it, it's usually just
setting a single register bit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jean Delvare]

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

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

[Jean Delvare]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Tue, Apr 24, 2012 at 02:32:41PM +0200, Jean Delvare wrote:

> 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

Yeah, for regmap we certainly have a fallback to kmalloc() a buffer as
needed in there already.  Like I say it's just an optimisation.

> 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.

That sounds like a good plan.  I'll try to get round to it if nobody
beats me to it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Tue, Apr 24, 2012 at 02:32:41PM +0200, Jean Delvare wrote:

> 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

Yeah, for regmap we certainly have a fallback to kmalloc() a buffer as
needed in there already.  Like I say it's just an optimisation.

> 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.

That sounds like a good plan.  I'll try to get round to it if nobody
beats me to it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

> > * We should allocate a new functionality flag for it.
> > * We should update the documentation to reflect the two use cases.
> 
> That sounds like a good plan.  I'll try to get round to it if nobody
> beats me to it.

Would it make sense to make all four I2C_M_* mangling features seperate
I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all
four (seperately) exposed mangling features ORed. That's what I was
wondering when looking at the patch.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

> > * We should allocate a new functionality flag for it.
> > * We should update the documentation to reflect the two use cases.
> 
> That sounds like a good plan.  I'll try to get round to it if nobody
> beats me to it.

Would it make sense to make all four I2C_M_* mangling features seperate
I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all
four (seperately) exposed mangling features ORed. That's what I was
wondering when looking at the patch.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jean Delvare]

On Tue, 24 Apr 2012 15:01:18 +0200, Wolfram Sang wrote:
> > > * We should allocate a new functionality flag for it.
> > > * We should update the documentation to reflect the two use cases.
> > 
> > That sounds like a good plan.  I'll try to get round to it if nobody
> > beats me to it.
> 
> Would it make sense to make all four I2C_M_* mangling features seperate
> I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all
> four (seperately) exposed mangling features ORed. That's what I was
> wondering when looking at the patch.

The problem is that the functionality is stored in a 32-bit integer,
and we already use 17 bits in it, so every use of extra bits must be
pondered. OK, we have 15 free at the moment, but we could need some in
the future for new SMBus-style transactions, for example multi-byte
addressed block reads and writes.

I think the assumption was that mangling requires full control of the
bus lines, so a driver would either support all quirks (i2c-algo-bit)
or none (everybody else), thus having a single functionality flag. As
it seems I2C_M_NOSTART no longer fits the "quirky" category, having a
separate flag for it would make sense. But I would leave the rest alone
for the time being.

-- 
Jean Delvare

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

[Jean Delvare]

On Tue, 24 Apr 2012 15:01:18 +0200, Wolfram Sang wrote:
> > > * We should allocate a new functionality flag for it.
> > > * We should update the documentation to reflect the two use cases.
> > 
> > That sounds like a good plan.  I'll try to get round to it if nobody
> > beats me to it.
> 
> Would it make sense to make all four I2C_M_* mangling features seperate
> I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all
> four (seperately) exposed mangling features ORed. That's what I was
> wondering when looking at the patch.

The problem is that the functionality is stored in a 32-bit integer,
and we already use 17 bits in it, so every use of extra bits must be
pondered. OK, we have 15 free at the moment, but we could need some in
the future for new SMBus-style transactions, for example multi-byte
addressed block reads and writes.

I think the assumption was that mangling requires full control of the
bus lines, so a driver would either support all quirks (i2c-algo-bit)
or none (everybody else), thus having a single functionality flag. As
it seems I2C_M_NOSTART no longer fits the "quirky" category, having a
separate flag for it would make sense. But I would leave the rest alone
for the time being.

-- 
Jean Delvare

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]


> I think the assumption was that mangling requires full control of the
> bus lines, so a driver would either support all quirks (i2c-algo-bit)
> or none (everybody else), thus having a single functionality flag. As
> it seems I2C_M_NOSTART no longer fits the "quirky" category, having a
> separate flag for it would make sense. But I would leave the rest alone
> for the time being.

OK. We can still do what I proposed just in case the other mangling
features should ever become equally important ;)

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]


> I think the assumption was that mangling requires full control of the
> bus lines, so a driver would either support all quirks (i2c-algo-bit)
> or none (everybody else), thus having a single functionality flag. As
> it seems I2C_M_NOSTART no longer fits the "quirky" category, having a
> separate flag for it would make sense. But I would leave the rest alone
> for the time being.

OK. We can still do what I proposed just in case the other mangling
features should ever become equally important ;)

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Laxman Dewangan]

Jean,
On Tuesday 24 April 2012 12:49 PM, 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.
>

Now the framework/core changes for making M_NOSTART as a separate flag 
is already part of your tree.
So do I need to re-send the patch for having that change?
1/1 is already part of Wolfram's tree and so not sure that how do I go 
i.e. from where I take the base i2c-tegra driver.
It may create the problem in integration on main if they are not sync.
Also I have some couple of changes which will be on top of this.

Thanks,
Laxman

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

[Laxman Dewangan]

Jean,
On Tuesday 24 April 2012 12:49 PM, 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.
>

Now the framework/core changes for making M_NOSTART as a separate flag 
is already part of your tree.
So do I need to re-send the patch for having that change?
1/1 is already part of Wolfram's tree and so not sure that how do I go 
i.e. from where I take the base i2c-tegra driver.
It may create the problem in integration on main if they are not sync.
Also I have some couple of changes which will be on top of this.

Thanks,
Laxman

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

[Jean Delvare]

Hi Laxman,

On Thu, 10 May 2012 16:54:53 +0530, Laxman Dewangan wrote:
> Jean,
> On Tuesday 24 April 2012 12:49 PM, 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.
> 
> Now the framework/core changes for making M_NOSTART as a separate flag 
> is already part of your tree.
> So do I need to re-send the patch for having that change?
> 1/1 is already part of Wolfram's tree and so not sure that how do I go 
> i.e. from where I take the base i2c-tegra driver.
> It may create the problem in integration on main if they are not sync.
> Also I have some couple of changes which will be on top of this.

I'm not sure I read you correctly so, for clarity: the patch
introducing I2C_FUNC_NOSTART finally landed in my tree [1], not
Wolfram's. It will be merged in kernel 3.5.

[1] http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/

If you don't want to depend on that, then just use
I2C_FUNC_PROTOCOL_MANGLING for now and you can switch to
I2C_FUNC_NOSTART later.

-- 
Jean Delvare

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

[Jean Delvare]

Hi Laxman,

On Thu, 10 May 2012 16:54:53 +0530, Laxman Dewangan wrote:
> Jean,
> On Tuesday 24 April 2012 12:49 PM, 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.
> 
> Now the framework/core changes for making M_NOSTART as a separate flag 
> is already part of your tree.
> So do I need to re-send the patch for having that change?
> 1/1 is already part of Wolfram's tree and so not sure that how do I go 
> i.e. from where I take the base i2c-tegra driver.
> It may create the problem in integration on main if they are not sync.
> Also I have some couple of changes which will be on top of this.

I'm not sure I read you correctly so, for clarity: the patch
introducing I2C_FUNC_NOSTART finally landed in my tree [1], not
Wolfram's. It will be merged in kernel 3.5.

[1] http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/

If you don't want to depend on that, then just use
I2C_FUNC_PROTOCOL_MANGLING for now and you can switch to
I2C_FUNC_NOSTART later.

-- 
Jean Delvare

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

[Laxman Dewangan]

On Thursday 10 May 2012 05:24 PM, Jean Delvare wrote:
> Hi Laxman,
>
> On Thu, 10 May 2012 16:54:53 +0530, Laxman Dewangan wrote:
>> Jean,
>> On Tuesday 24 April 2012 12:49 PM, 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.
>> Now the framework/core changes for making M_NOSTART as a separate flag
>> is already part of your tree.
>> So do I need to re-send the patch for having that change?
>> 1/1 is already part of Wolfram's tree and so not sure that how do I go
>> i.e. from where I take the base i2c-tegra driver.
>> It may create the problem in integration on main if they are not sync.
>> Also I have some couple of changes which will be on top of this.
> I'm not sure I read you correctly so, for clarity: the patch
> introducing I2C_FUNC_NOSTART finally landed in my tree [1], not
> Wolfram's. It will be merged in kernel 3.5.
>
> [1] http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/
>
> If you don't want to depend on that, then just use
> I2C_FUNC_PROTOCOL_MANGLING for now and you can switch to
> I2C_FUNC_NOSTART later.
>
It is fine. So this change can go in to Wolfram's tree as it is and 
after k3.5, I will post another change which will use I2C_FUNC_NOSTART.

Thanks,
Laxman

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

[Laxman Dewangan]

On Thursday 10 May 2012 05:24 PM, Jean Delvare wrote:
> Hi Laxman,
>
> On Thu, 10 May 2012 16:54:53 +0530, Laxman Dewangan wrote:
>> Jean,
>> On Tuesday 24 April 2012 12:49 PM, 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.
>> Now the framework/core changes for making M_NOSTART as a separate flag
>> is already part of your tree.
>> So do I need to re-send the patch for having that change?
>> 1/1 is already part of Wolfram's tree and so not sure that how do I go
>> i.e. from where I take the base i2c-tegra driver.
>> It may create the problem in integration on main if they are not sync.
>> Also I have some couple of changes which will be on top of this.
> I'm not sure I read you correctly so, for clarity: the patch
> introducing I2C_FUNC_NOSTART finally landed in my tree [1], not
> Wolfram's. It will be merged in kernel 3.5.
>
> [1] http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/
>
> If you don't want to depend on that, then just use
> I2C_FUNC_PROTOCOL_MANGLING for now and you can switch to
> I2C_FUNC_NOSTART later.
>
It is fine. So this change can go in to Wolfram's tree as it is and 
after k3.5, I will post another change which will use I2C_FUNC_NOSTART.

Thanks,
Laxman