i2c: imx: fix i2c issues when reading messages

From: Stefan Eichenberger <[email protected]>

When reading multiple messages, meaning a repeated start is required, polling the bus busy bit must be avoided. This must only be done for the last message. Otherwise, the driver will timeout.

Here an example of such a sequence that fails with an error:
i2ctransfer -y -a 0 w1@0x00 0x02 r1 w1@0x00 0x02 r1
Error: Sending messages failed: Connection timed out

Fixes 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")

Cc <[email protected]> # v6.13+

Signed-off-by Stefan Eichenberger <[email protected]>

---

 drivers/i2c/busses/i2c-imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/busses/i2c-imx.c +1 -2

index 85f554044cf1e..56e2a14495a9a 100644
@@ -1522,7 +1522,7 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs,
 		dev_err(&i2c_imx->adapter.dev, "<%s> read timedout\n", __func__);
 		return -ETIMEDOUT;
 	}
-	if (!i2c_imx->stopped)
+	if (i2c_imx->is_lastmsg && !i2c_imx->stopped)
 		return i2c_imx_bus_busy(i2c_imx, 0, false);
 
 	return 0;
--

2.51.0

From: Stefan Eichenberger <[email protected]>

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

only read from I2DR after the bus is not busy anymore. Because this requires polling, the read of the last byte is moved outside of the interrupt handler.

An example for such a failing transfer is this:
i2ctransfer -y -a 0 w1@0x00 0x02 r1
Error: Sending messages failed: Connection timed out
It does not happen with every device because not all devices react to the additional clock cycle.

Fixes 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")

Cc <[email protected]> # v6.13+

Signed-off-by Stefan Eichenberger <[email protected]>

---
 drivers/i2c/busses/i2c-imx.c | 51 ++++++++++++++++++++++--------------
 1 file changed, 32 insertions(+), 19 deletions(-)

drivers/i2c/busses/i2c-imx.c +32 -20

index 56e2a14495a9a..452d120a210b1 100644
@@ -1018,8 +1018,9 @@ static inline int i2c_imx_isr_read(struct imx_i2c_struct *i2c_imx)
 	return 0;
 }
 
-static inline void i2c_imx_isr_read_continue(struct imx_i2c_struct *i2c_imx)
+static inline enum imx_i2c_state i2c_imx_isr_read_continue(struct imx_i2c_struct *i2c_imx)
 {
+	enum imx_i2c_state next_state = IMX_I2C_STATE_READ_CONTINUE;
 	unsigned int temp;
 
 	if ((i2c_imx->msg->len - 1) == i2c_imx->msg_buf_idx) {

@@ -1033,18 +1034,20 @@ static inline void i2c_imx_isr_read_continue(struct imx_i2c_struct *i2c_imx)
 				i2c_imx->stopped =  1;
 			temp &= ~(I2CR_MSTA | I2CR_MTX);
 			imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
-		} else {
-			/*
-			 * For i2c master receiver repeat restart operation like:
-			 * read -> repeat MSTA -> read/write
-			 * The controller must set MTX before read the last byte in
-			 * the first read operation, otherwise the first read cost
-			 * one extra clock cycle.
-			 */
-			temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
-			temp |= I2CR_MTX;
-			imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+			return IMX_I2C_STATE_DONE;
 		}
+		/*
+		 * For i2c master receiver repeat restart operation like:
+		 * read -> repeat MSTA -> read/write
+		 * The controller must set MTX before read the last byte in
+		 * the first read operation, otherwise the first read cost
+		 * one extra clock cycle.
+		 */
+		temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+		temp |= I2CR_MTX;
+		imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+		next_state = IMX_I2C_STATE_DONE;
 	} else if (i2c_imx->msg_buf_idx == (i2c_imx->msg->len - 2)) {
 		temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
 		temp |= I2CR_TXAK;

@@ -1052,6 +1055,7 @@ static inline void i2c_imx_isr_read_continue(struct imx_i2c_struct *i2c_imx)
 	}
 
 	i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+	return next_state;
 }
 
 static inline void i2c_imx_isr_read_block_data_len(struct imx_i2c_struct *i2c_imx)

@@ -1088,11 +1092,9 @@ static irqreturn_t i2c_imx_master_isr(struct imx_i2c_struct *i2c_imx, unsigned i
 		break;
 
 	case IMX_I2C_STATE_READ_CONTINUE:
-		i2c_imx_isr_read_continue(i2c_imx);
-		if (i2c_imx->msg_buf_idx == i2c_imx->msg->len) {
-			i2c_imx->state = IMX_I2C_STATE_DONE;
+		i2c_imx->state = i2c_imx_isr_read_continue(i2c_imx);
+		if (i2c_imx->state == IMX_I2C_STATE_DONE)
 			wake_up(&i2c_imx->queue);
-		}
 		break;
 
 	case IMX_I2C_STATE_READ_BLOCK_DATA:

@@ -1490,6 +1492,7 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs,
 			bool is_lastmsg)
 {
 	int block_data = msgs->flags & I2C_M_RECV_LEN;
+	int ret = 0;
 
 	dev_dbg(&i2c_imx->adapter.dev,
 		"<%s> write slave address: addr=0x%x\n",

@@ -1522,10 +1525,20 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs,
 		dev_err(&i2c_imx->adapter.dev, "<%s> read timedout\n", __func__);
 		return -ETIMEDOUT;
 	}
-	if (i2c_imx->is_lastmsg && !i2c_imx->stopped)
-		return i2c_imx_bus_busy(i2c_imx, 0, false);
+	if (i2c_imx->is_lastmsg) {
+		if (!i2c_imx->stopped)
+			ret = i2c_imx_bus_busy(i2c_imx, 0, false);
+		/*
+		 * Only read the last byte of the last message after the bus is
+		 * not busy. Else the controller generates another clock which
+		 * might confuse devices.
+		 */
+		if (!ret)
+			i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = imx_i2c_read_reg(i2c_imx,
+										     IMX_I2C_I2DR);
+	}
 
-	return 0;
+	return ret;
 }
 
 static int i2c_imx_xfer_common(struct i2c_adapter *adapter,
--

2.51.0

Quoted 5 lines · Stefan Eichenberger

From: Stefan Eichenberger <[email protected]>

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Hi Frank,

Quoted 9 lines · Frank Li

Quoted 5 lines · Stefan Eichenberger

From: Stefan Eichenberger <[email protected]>

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Yes exactly. We were able to capture the waveform when the issue happens. It doesn't always happen though, it depends on how much time passes between clearing MSTA and MTX and reading from I2DR.

If you want to see the waveform, I uploaded it to our server:
https://share.toradex.com/dwnhcrl6b9toib6
You can see the additional clock at the right end, after "0x17 + NAK".

Hi Frank,

Quoted 17 lines · Stefan Eichenberger

Hi Frank,

Quoted 9 lines · Frank Li

Quoted 5 lines · Stefan Eichenberger

From: Stefan Eichenberger <[email protected]>

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Yes exactly. We were able to capture the waveform when the issue happens. It doesn't always happen though, it depends on how much time passes between clearing MSTA and MTX and reading from I2DR.

Quoted 3 lines

If you want to see the waveform, I uploaded it to our server:
https://share.toradex.com/dwnhcrl6b9toib6
You can see the additional clock at the right end, after "0x17 + NAK".

Have you had a chance to look at the waveform? Do you have any concerns about the proposed solution?

Best regards,
Stefan

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, March 3, 2026 11:54 PM
To: Stefan Eichenberger <[email protected]>; Carlos Song <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Francesco Dolcini <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH v1 2/2] i2c: imx: ensure no clock is generated after last read

Quoted 25 lines · Stefan Eichenberger

Hi Frank,

Quoted 21 lines · Stefan Eichenberger

Hi Frank,

Quoted 10 lines · Frank Li

Quoted 6 lines · Stefan Eichenberger

From: Stefan Eichenberger <[email protected]>

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Yes exactly. We were able to capture the waveform when the issue happens. It doesn't always happen though, it depends on how much time passes between clearing MSTA and MTX and reading from I2DR.

If you want to see the waveform, I uploaded it to our server:
https://share.toradex.com/dwnhcrl6b9toib6
You can see the additional clock at the right end, after "0x17 + NAK".

Quoted 2 lines

Have you had a chance to look at the waveform? Do you have any concerns about the proposed solution?

I am fine. Add carlos, who did many work about I2C.

Frank

Quoted 3 lines

Best regards,
Stefan

Quoted 16 lines

Quoted 16 lines

Quoted 15 lines

Quoted 7 lines

Quoted 4 lines

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Yes exactly. We were able to capture the waveform when the issue happens. It doesn't always happen though, it depends on how much time passes between clearing MSTA and MTX and reading from I2DR.

If you want to see the waveform, I uploaded it to our server:
https://share.toradex.com/dwnhcrl6b9toib6
You can see the additional clock at the right end, after "0x17 + NAK".

Quoted 6 lines

Quoted 2 lines

Have you had a chance to look at the waveform? Do you have any concerns about the proposed solution?

I am fine. Add carlos, who did many work about I2C.

Frank

Hi,

Just review this series, looks this series patch make this fix for the limitation[1] safer:
"It must generate STOP before read I2DR to prevent controller from generating another clock cycle".

Previous patch[2] has done this to avoid the limitation. However according to the waveform, I2C controller still generated an additional clock cycle sometime.

The key of patch is ensure to read the last bytes after the bus is not busy anymore to avoid this another clock cycle.So these patches are fine to me also.

[1] 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
[2] 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")

-----Original Message-----
From: Andi Shyti <[email protected]>
Sent: Friday, March 20, 2026 7:10 AM
To: Carlos Song <[email protected]>
Cc: Frank Li <[email protected]>; Stefan Eichenberger <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Francesco Dolcini <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: [EXT] Re: [PATCH v1 2/2] i2c: imx: ensure no clock is generated after last read

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

Hi Carlos,

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to

Do you means SCL have additional toggle? You capture waveform?

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Yes exactly. We were able to capture the waveform when the issue happens. It doesn't always happen though, it depends on how much time passes between clearing MSTA and MTX and reading from I2DR.

If you want to see the waveform, I uploaded it to our server:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%

2Fshare.toradex.com%2Fdwnhcrl6b9toib6&data=05%7C02%7Ccarlos.song

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

%40nxp.com%7C9567b791c35345a75eba08de860c9954%7C686ea1d

3bc2b4c6f

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

a92cd99c5c301635%7C0%7C0%7C639095585800985569%7CUnknown%7CT WFpbG

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AK6DGztAek

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

8Dq0M8G98PO%2F68UhcwfJPxsLSJQZ4jumE%3D&reserved=0
You can see the additional clock at the right end, after "0x17 + NAK".

Have you had a chance to look at the waveform? Do you have any concerns about the proposed solution?

Quoted 7 lines

Quoted 3 lines

I am fine. Add carlos, who did many work about I2C.

Frank

Hi,

Just review this series, looks this series patch make this fix for the limitation[1]

safer:

Quoted 1 line

"It must generate STOP before read I2DR to prevent controller from

generating another clock cycle".

Quoted 2 lines

Previous patch[2] has done this to avoid the limitation. However according to

the waveform, I2C controller still generated an additional clock cycle sometime.

Quoted 2 lines

The key of patch is ensure to read the last bytes after the bus is not busy

anymore to avoid this another clock cycle.So these patches are fine to me also.

Quoted 4 lines

[1] 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart") [2] 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")

Sorry, I'm not understanding your point here. Are you suggesting to change the Fixes tag to [1]?

Thanks,
Andi

Stefan Eichenberger (2):
i2c: imx: fix i2c issue when reading multiple messages
i2c: imx: ensure no clock is generated after last read