diff mbox series

[v1] i2c: designware: Disable TX_EMPTY irq while waiting for block length byte

Message ID 20230929035356.6435-1-tamnguyenchi@os.amperecomputing.com
State New
Headers show
Series [v1] i2c: designware: Disable TX_EMPTY irq while waiting for block length byte | expand

Commit Message

Tam Nguyen Sept. 29, 2023, 3:53 a.m. UTC 
During SMBus block data read process, we have seen high interrupt rate
because of TX_EMPTY irq status while waiting for block length byte (the
first data byte after the address phase). The interrupt handler does not
do anything because the internal state is kept as STATUS_WRITE_IN_PROGRESS.
Hence, we should disable TX_EMPTY irq until I2C DW receives first data
byte from I2C device, then re-enable it.

It takes 0.789 ms for host to receive data length from slave.
Without the patch, i2c_dw_isr is called 99 times by TX_EMPTY interrupt.
And it is none after applying the patch.

Cc: stable@vger.kernel.org
Signed-off-by: Chuong Tran <chuong@os.amperecomputing.com>
Signed-off-by: Tam Nguyen <tamnguyenchi@os.amperecomputing.com>
---
 drivers/i2c/busses/i2c-designware-master.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Andy Shevchenko Oct. 3, 2023, 8:57 a.m. UTC | #1 
On Fri, Sep 29, 2023 at 10:53:56AM +0700, Tam Nguyen wrote:
> During SMBus block data read process, we have seen high interrupt rate
> because of TX_EMPTY irq status while waiting for block length byte (the
> first data byte after the address phase). The interrupt handler does not
> do anything because the internal state is kept as STATUS_WRITE_IN_PROGRESS.
> Hence, we should disable TX_EMPTY irq until I2C DW receives first data

IRQ
DesignWare

> byte from I2C device, then re-enable it.
> 
> It takes 0.789 ms for host to receive data length from slave.
> Without the patch, i2c_dw_isr is called 99 times by TX_EMPTY interrupt.

i2c_dw_isr()

> And it is none after applying the patch.

> Cc: stable@vger.kernel.org
> Signed-off-by: Chuong Tran <chuong@os.amperecomputing.com>

Who is this guy? Do you need Co-developed-by tag?

> Signed-off-by: Tam Nguyen <tamnguyenchi@os.amperecomputing.com>

Other than that, agree with Serge's points.
Tam Chi Nguyen Oct. 16, 2023, 2:47 a.m. UTC | #2 
On 9/29/2023 23:08, Serge Semin wrote:
> On Fri, Sep 29, 2023 at 10:53:56AM +0700, Tam Nguyen wrote:
>> During SMBus block data read process, we have seen high interrupt rate
>> because of TX_EMPTY irq status while waiting for block length byte (the
>> first data byte after the address phase). The interrupt handler does not
>> do anything because the internal state is kept as STATUS_WRITE_IN_PROGRESS.
>> Hence, we should disable TX_EMPTY irq until I2C DW receives first data
>> byte from I2C device, then re-enable it.
>>
>> It takes 0.789 ms for host to receive data length from slave.
>> Without the patch, i2c_dw_isr is called 99 times by TX_EMPTY interrupt.
>> And it is none after applying the patch.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Chuong Tran <chuong@os.amperecomputing.com>
>> Signed-off-by: Tam Nguyen <tamnguyenchi@os.amperecomputing.com>
>> ---
>>   drivers/i2c/busses/i2c-designware-master.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c
>> index 55ea91a63382..2152b1f9b27c 100644
>> --- a/drivers/i2c/busses/i2c-designware-master.c
>> +++ b/drivers/i2c/busses/i2c-designware-master.c
>> @@ -462,6 +462,13 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
>>   		if (buf_len > 0 || flags & I2C_M_RECV_LEN) {
>>   			/* more bytes to be written */
>>   			dev->status |= STATUS_WRITE_IN_PROGRESS;
>> +			/*
>> +			 * In I2C_FUNC_SMBUS_BLOCK_DATA case, there is no data
>> +			 * to send before receiving data length from slave.
>> +			 * Disable TX_EMPTY while waiting for data length byte
>> +			 */
>> +			if (flags & I2C_M_RECV_LEN)
>> +				intr_mask &= ~DW_IC_INTR_TX_EMPTY;
> Is it possible to reduce the indentations level? Like this:
>
> 		/*
> 		 * Because we don't know the buffer length in the
> 		 * I2C_FUNC_SMBUS_BLOCK_DATA case, we can't stop the
> 		 * transaction here. Also disable the TX_EMPTY IRQ
> 		 * while waiting for the data length byte to avoid the
> 		 * bogus interrupts flood.
> 		 */
> 		if (flags & I2C_M_RECV_LEN) {
>    			dev->status |= STATUS_WRITE_IN_PROGRESS;
> 			intr_mask &= ~DW_IC_INTR_TX_EMPTY;
> 			break;
> 		} else if (buf_len > 0) {
>    			/* more bytes to be written */
>    			dev->status |= STATUS_WRITE_IN_PROGRESS;
> 			break;
> 		} else {
> 			dev->status &= ~STATUS_WRITE_IN_PROGRESS;
> 		}
Thank you very much for your advice. I will update in V2.
>>   			break;
>>   		} else
>>   			dev->status &= ~STATUS_WRITE_IN_PROGRESS;
>> @@ -485,6 +492,7 @@ i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
>>   {
>>   	struct i2c_msg *msgs = dev->msgs;
>>   	u32 flags = msgs[dev->msg_read_idx].flags;
>> +	u32 intr_mask;
>>   
>>   	/*
>>   	 * Adjust the buffer length and mask the flag
>> @@ -495,6 +503,11 @@ i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
>>   	msgs[dev->msg_read_idx].len = len;
>>   	msgs[dev->msg_read_idx].flags &= ~I2C_M_RECV_LEN;
>>   
>> +	/* Re-enable TX_EMPTY interrupt. */
>> +	regmap_read(dev->map, DW_IC_INTR_MASK, &intr_mask);
>> +	intr_mask |= DW_IC_INTR_TX_EMPTY;
>> +	regmap_write(dev->map, DW_IC_INTR_MASK, intr_mask);
> 1. What about just:
> 	regmap_update_bits(dev->map, DW_IC_INTR_MASK, DW_IC_INTR_TX_EMPTY,
> 			   DW_IC_INTR_TX_EMPTY);
Right, much better with this update. I'll update it in v2.
> 2. The in-situ comment is pointless because the statement already
> implies the IRQ re-enabling. I suggest to add more details of _why_
> the IRQ needs to be re-enabled (what is supposed to be done after it's
> re-enabled?).

Got that. I will add more context here. Thank for the advice.

Best regards,
Tam Nguyen

> -Serge(y)
>
>> +
>>   	return len;
>>   }
>>   
>> -- 
>> 2.25.1
>>
Tam Chi Nguyen Oct. 16, 2023, 2:51 a.m. UTC | #3 
On 10/3/2023 15:57, Andy Shevchenko wrote:
> On Fri, Sep 29, 2023 at 10:53:56AM +0700, Tam Nguyen wrote:
>> During SMBus block data read process, we have seen high interrupt rate
>> because of TX_EMPTY irq status while waiting for block length byte (the
>> first data byte after the address phase). The interrupt handler does not
>> do anything because the internal state is kept as STATUS_WRITE_IN_PROGRESS.
>> Hence, we should disable TX_EMPTY irq until I2C DW receives first data
> IRQ
> DesignWare
Got that. I will update in V2.
>> byte from I2C device, then re-enable it.
>>
>> It takes 0.789 ms for host to receive data length from slave.
>> Without the patch, i2c_dw_isr is called 99 times by TX_EMPTY interrupt.
> i2c_dw_isr()
Will update in V2.
>
>> And it is none after applying the patch.
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Chuong Tran <chuong@os.amperecomputing.com>
> Who is this guy? Do you need Co-developed-by tag?
Right, that's my bad. I will update it with "Co-developed-by" tag
>> Signed-off-by: Tam Nguyen <tamnguyenchi@os.amperecomputing.com>
> Other than that, agree with Serge's points.
Thanks both of you. I totally agree with Serge's points and will update 
them in v2.
>
Tam Chi Nguyen Oct. 16, 2023, 2:52 a.m. UTC | #4 
On 10/3/2023 15:11, Yann Sionneau wrote:
> Hi Tam,
>
> On 9/29/23 05:53, Tam Nguyen wrote:
>> During SMBus block data read process, we have seen high interrupt rate
>> because of TX_EMPTY irq status while waiting for block length byte (the
>> first data byte after the address phase). The interrupt handler does not
>> do anything because the internal state is kept as 
>> STATUS_WRITE_IN_PROGRESS.
>> Hence, we should disable TX_EMPTY irq until I2C DW receives first data
>> byte from I2C device, then re-enable it.
>>
>> It takes 0.789 ms for host to receive data length from slave.
>> Without the patch, i2c_dw_isr is called 99 times by TX_EMPTY interrupt.
>> And it is none after applying the patch.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Chuong Tran <chuong@os.amperecomputing.com>
>> Signed-off-by: Tam Nguyen <tamnguyenchi@os.amperecomputing.com>
>> ---
>>   drivers/i2c/busses/i2c-designware-master.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-master.c 
>> b/drivers/i2c/busses/i2c-designware-master.c
>> index 55ea91a63382..2152b1f9b27c 100644
>> --- a/drivers/i2c/busses/i2c-designware-master.c
>> +++ b/drivers/i2c/busses/i2c-designware-master.c
>> @@ -462,6 +462,13 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
>>           if (buf_len > 0 || flags & I2C_M_RECV_LEN) {
>>               /* more bytes to be written */
>>               dev->status |= STATUS_WRITE_IN_PROGRESS;
>> +            /*
>> +             * In I2C_FUNC_SMBUS_BLOCK_DATA case, there is no data
>> +             * to send before receiving data length from slave.
>> +             * Disable TX_EMPTY while waiting for data length byte
>> +             */
>> +            if (flags & I2C_M_RECV_LEN)
>> +                intr_mask &= ~DW_IC_INTR_TX_EMPTY;
>>               break;
>>           } else
>>               dev->status &= ~STATUS_WRITE_IN_PROGRESS;
>> @@ -485,6 +492,7 @@ i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
>>   {
>>       struct i2c_msg *msgs = dev->msgs;
>>       u32 flags = msgs[dev->msg_read_idx].flags;
>> +    u32 intr_mask;
>>         /*
>>        * Adjust the buffer length and mask the flag
>> @@ -495,6 +503,11 @@ i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
>>       msgs[dev->msg_read_idx].len = len;
>>       msgs[dev->msg_read_idx].flags &= ~I2C_M_RECV_LEN;
>>   +    /* Re-enable TX_EMPTY interrupt. */
>> +    regmap_read(dev->map, DW_IC_INTR_MASK, &intr_mask);
>> +    intr_mask |= DW_IC_INTR_TX_EMPTY;
>> +    regmap_write(dev->map, DW_IC_INTR_MASK, intr_mask);
>> +
>>       return len;
>>   }
>
> I tested this patch on Kalray k200 and k200lp boards (Coolidge SoC, 
> kvx arch). With this patch all our CI pipelines are green.
>
Thank you for your time to test this patch.

> Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
>
diff mbox series

Patch

diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c
index 55ea91a63382..2152b1f9b27c 100644
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -462,6 +462,13 @@  i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
 		if (buf_len > 0 || flags & I2C_M_RECV_LEN) {
 			/* more bytes to be written */
 			dev->status |= STATUS_WRITE_IN_PROGRESS;
+			/*
+			 * In I2C_FUNC_SMBUS_BLOCK_DATA case, there is no data
+			 * to send before receiving data length from slave.
+			 * Disable TX_EMPTY while waiting for data length byte
+			 */
+			if (flags & I2C_M_RECV_LEN)
+				intr_mask &= ~DW_IC_INTR_TX_EMPTY;
 			break;
 		} else
 			dev->status &= ~STATUS_WRITE_IN_PROGRESS;
@@ -485,6 +492,7 @@  i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
 {
 	struct i2c_msg *msgs = dev->msgs;
 	u32 flags = msgs[dev->msg_read_idx].flags;
+	u32 intr_mask;
 
 	/*
 	 * Adjust the buffer length and mask the flag
@@ -495,6 +503,11 @@  i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
 	msgs[dev->msg_read_idx].len = len;
 	msgs[dev->msg_read_idx].flags &= ~I2C_M_RECV_LEN;
 
+	/* Re-enable TX_EMPTY interrupt. */
+	regmap_read(dev->map, DW_IC_INTR_MASK, &intr_mask);
+	intr_mask |= DW_IC_INTR_TX_EMPTY;
+	regmap_write(dev->map, DW_IC_INTR_MASK, intr_mask);
+
 	return len;
 }