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@xxxxxxxxxxxxxxx
Signed-off-by: Chuong Tran <chuong@xxxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Tam Nguyen <tamnguyenchi@xxxxxxxxxxxxxxxxxxxxxx>
---
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
