[PATCH 0/4] i3c: mipi-i3c-hci: Functional update

[PATCH 0/4] i3c: mipi-i3c-hci: Functional update

[Jarkko Nikula]

Hi

These are v6.8-rc1 material and not for current cycle.

With these and handful of local patches [1] I'm able probe this driver
successfully with an I3C device on the bus and without.

Also able to communicate with I3C and I2C device from their corresponding
device drivers. I'm using in my test setup an LSM6DSO sensor (forced to
I3C mode) and at24c02 I2C EEPROM instantiated from userspace.

Patches are from top of commit 9fd00df05e81 ("i3c: master: handle IBIs
in order they came").

1. Glue code and minor hacks for early MIPI I3C HCI version compatible
   controller on our development HW.

Jarkko Nikula (4):
  i3c: mipi-i3c-hci: Report NACK response from CCC command to core
  i3c: mipi-i3c-hci: Do not overallocate transfers in hci_cmd_v1_daa()
  i3c: mipi-i3c-hci: Handle I3C address header error in hci_cmd_v1_daa()
  i3c: mipi-i3c-hci: Add DMA bounce buffer for private transfers

 drivers/i3c/master/mipi-i3c-hci/cmd_v1.c |  7 ++--
 drivers/i3c/master/mipi-i3c-hci/core.c   | 49 +++++++++++++++++++++++-
 drivers/i3c/master/mipi-i3c-hci/dma.c    |  4 +-
 drivers/i3c/master/mipi-i3c-hci/hci.h    |  1 +
 4 files changed, 56 insertions(+), 5 deletions(-)

-- 
2.42.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH 1/4] i3c: mipi-i3c-hci: Report NACK response from CCC command to core

[Jarkko Nikula]

Currently probe of mipi-i3c-hci will fail if bus doesn't have any I3C
devices connected. This happens when CCC commands that are sent during
i3c_master_bus_init() are not ACKed by any device and controller responds
with an error status set.

The controller can detect NACK both during I3C address header
transmission (broadcast address 0x7e is not ACKed) and when target
device address or dynamic address assignment is NACKed. Former as error
status 0x4: Address Header Error and latter as 0x5: NACK.

Difference between those two NACK statuses were not described explicitly
until MIPI I3C HCI Specification v1.1. Earlier versions share the same
error status code though.

Report both of those as I3C_ERROR_M2 to I3C core code.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
 drivers/i3c/master/mipi-i3c-hci/core.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index 1ae56a5699c6..8471a1fe1dad 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -245,7 +245,14 @@ static int i3c_hci_send_ccc_cmd(struct i3c_master_controller *m,
 		if (ccc->rnw)
 			ccc->dests[i - prefixed].payload.len =
 				RESP_DATA_LENGTH(xfer[i].response);
-		if (RESP_STATUS(xfer[i].response) != RESP_SUCCESS) {
+		switch (RESP_STATUS(xfer[i].response)) {
+		case RESP_SUCCESS:
+			continue;
+		case RESP_ERR_ADDR_HEADER:
+		case RESP_ERR_NACK:
+			ccc->err = I3C_ERROR_M2;
+			fallthrough;
+		default:
 			ret = -EIO;
 			goto out;
 		}
-- 
2.42.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH 2/4] i3c: mipi-i3c-hci: Do not overallocate transfers in hci_cmd_v1_daa()

[Jarkko Nikula]

Function hci_cmd_v1_daa() uses only single transfer at a time so no need
to allocate two transfers and access can be simplified.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
 drivers/i3c/master/mipi-i3c-hci/cmd_v1.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c b/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
index 2b2323aa6714..31f03cb22489 100644
--- a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
+++ b/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
@@ -298,7 +298,7 @@ static int hci_cmd_v1_daa(struct i3c_hci *hci)
 	unsigned int dcr, bcr;
 	DECLARE_COMPLETION_ONSTACK(done);
 
-	xfer = hci_alloc_xfer(2);
+	xfer = hci_alloc_xfer(1);
 	if (!xfer)
 		return -ENOMEM;
 
@@ -339,12 +339,12 @@ static int hci_cmd_v1_daa(struct i3c_hci *hci)
 			ret = -ETIME;
 			break;
 		}
-		if (RESP_STATUS(xfer[0].response) == RESP_ERR_NACK &&
+		if (RESP_STATUS(xfer->response) == RESP_ERR_NACK &&
 		    RESP_DATA_LENGTH(xfer->response) == 1) {
 			ret = 0;  /* no more devices to be assigned */
 			break;
 		}
-		if (RESP_STATUS(xfer[0].response) != RESP_SUCCESS) {
+		if (RESP_STATUS(xfer->response) != RESP_SUCCESS) {
 			ret = -EIO;
 			break;
 		}
-- 
2.42.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH 3/4] i3c: mipi-i3c-hci: Handle I3C address header error in hci_cmd_v1_daa()

[Jarkko Nikula]

Handle also I3C address header error response status as the end of DAA
process in hci_cmd_v1_daa().

According to MIPI I3C HCI Specification v1.1 the NACK error during DAA
process comes when the device does not accept the dynamic address.
Currently code uses it for successful exit from the process and fails
with any other error response.

I'm unsure is this MIPI I3C HCI version specific difference or
specification misunderstanding but on an early MIPI I3C HCI version
compatible controller responds always with I3C address header error and
not with NACK error when there is no device on the bus or no more devices
participating to DAA process.

Handle now both response statuses as the end of DAA.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
 drivers/i3c/master/mipi-i3c-hci/cmd_v1.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c b/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
index 31f03cb22489..638b054d6c92 100644
--- a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
+++ b/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c
@@ -339,7 +339,8 @@ static int hci_cmd_v1_daa(struct i3c_hci *hci)
 			ret = -ETIME;
 			break;
 		}
-		if (RESP_STATUS(xfer->response) == RESP_ERR_NACK &&
+		if ((RESP_STATUS(xfer->response) == RESP_ERR_ADDR_HEADER ||
+		     RESP_STATUS(xfer->response) == RESP_ERR_NACK) &&
 		    RESP_DATA_LENGTH(xfer->response) == 1) {
 			ret = 0;  /* no more devices to be assigned */
 			break;
-- 
2.42.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH 4/4] i3c: mipi-i3c-hci: Add DMA bounce buffer for private transfers

[Jarkko Nikula]

Implement a local bounce buffer for private I3C SDR and I2C transfers
when using DMA and the buffer attached to the transfer is not DMA safe.

Otherwise the DMA transfer will fail and with following warning:

[   11.411059] i3c mipi-i3c-hci.0: rejecting DMA map of vmalloc memory
[   11.417313] WARNING: CPU: 3 PID: 357 at include/linux/dma-mapping.h:332 hci_dma_queue_xfer+0x2e2/0x300 [mipi_i3c_hci]

Strictly speaking private I3C SDR transfers are expected to pass a
DMA-able buffer. However I fear this requirement may easily be slipped
or go unnoticed when I3C interface support is added into a existing
device driver that use regmap API to read/write stack variables.

For example this is the case with the commit 2660b0080bb2 ("iio: imu:
st_lsm6dsx: add i3c basic support for LSM6DSO and LSM6DSR").

Buffer of an I2C message is not required to be DMA safe and the I2C core
provides i2c_(get|put)_dma_safe_msg_buf() helpers for the host
controllers that do DMA and that is also recommendation for the
i2c_xfers() callback from the I3C core.

However due to above I3C private transfers reason I decided to implement
a bounce buffer for them and reuse the same code for the I2C transfers
too. Since this driver is currently the only I3C host controller driver
that can do DMA the implementation is done here and not in I3C core.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
 drivers/i3c/master/mipi-i3c-hci/core.c | 40 ++++++++++++++++++++++++++
 drivers/i3c/master/mipi-i3c-hci/dma.c  |  4 ++-
 drivers/i3c/master/mipi-i3c-hci/hci.h  |  1 +
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index 8471a1fe1dad..d7e966a25583 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -276,6 +276,34 @@ static int i3c_hci_daa(struct i3c_master_controller *m)
 	return hci->cmd->perform_daa(hci);
 }
 
+static int i3c_hci_alloc_safe_xfer_buf(struct i3c_hci *hci,
+				       struct hci_xfer *xfer)
+{
+	if (hci->io != &mipi_i3c_hci_dma ||
+	    xfer->data == NULL || !is_vmalloc_addr(xfer->data))
+		return 0;
+
+	if (xfer->rnw)
+		xfer->bounce_buf = kzalloc(xfer->data_len, GFP_KERNEL);
+	else
+		xfer->bounce_buf = kmemdup(xfer->data,
+					   xfer->data_len, GFP_KERNEL);
+
+	return xfer->bounce_buf == NULL ? -ENOMEM : 0;
+}
+
+static void i3c_hci_free_safe_xfer_buf(struct i3c_hci *hci,
+				       struct hci_xfer *xfer)
+{
+	if (hci->io != &mipi_i3c_hci_dma || xfer->bounce_buf == NULL)
+		return;
+
+	if (xfer->rnw)
+		memcpy(xfer->data, xfer->bounce_buf, xfer->data_len);
+
+	kfree(xfer->bounce_buf);
+}
+
 static int i3c_hci_priv_xfers(struct i3c_dev_desc *dev,
 			      struct i3c_priv_xfer *i3c_xfers,
 			      int nxfers)
@@ -309,6 +337,9 @@ static int i3c_hci_priv_xfers(struct i3c_dev_desc *dev,
 		}
 		hci->cmd->prep_i3c_xfer(hci, dev, &xfer[i]);
 		xfer[i].cmd_desc[0] |= CMD_0_ROC;
+		ret = i3c_hci_alloc_safe_xfer_buf(hci, &xfer[i]);
+		if (ret)
+			goto out;
 	}
 	last = i - 1;
 	xfer[last].cmd_desc[0] |= CMD_0_TOC;
@@ -332,6 +363,9 @@ static int i3c_hci_priv_xfers(struct i3c_dev_desc *dev,
 	}
 
 out:
+	for (i = 0; i < nxfers; i++)
+		i3c_hci_free_safe_xfer_buf(hci, &xfer[i]);
+
 	hci_free_xfer(xfer, nxfers);
 	return ret;
 }
@@ -357,6 +391,9 @@ static int i3c_hci_i2c_xfers(struct i2c_dev_desc *dev,
 		xfer[i].rnw = i2c_xfers[i].flags & I2C_M_RD;
 		hci->cmd->prep_i2c_xfer(hci, dev, &xfer[i]);
 		xfer[i].cmd_desc[0] |= CMD_0_ROC;
+		ret = i3c_hci_alloc_safe_xfer_buf(hci, &xfer[i]);
+		if (ret)
+			goto out;
 	}
 	last = i - 1;
 	xfer[last].cmd_desc[0] |= CMD_0_TOC;
@@ -378,6 +415,9 @@ static int i3c_hci_i2c_xfers(struct i2c_dev_desc *dev,
 	}
 
 out:
+	for (i = 0; i < nxfers; i++)
+		i3c_hci_free_safe_xfer_buf(hci, &xfer[i]);
+
 	hci_free_xfer(xfer, nxfers);
 	return ret;
 }
diff --git a/drivers/i3c/master/mipi-i3c-hci/dma.c b/drivers/i3c/master/mipi-i3c-hci/dma.c
index c805a8497319..4e01a95cc4d0 100644
--- a/drivers/i3c/master/mipi-i3c-hci/dma.c
+++ b/drivers/i3c/master/mipi-i3c-hci/dma.c
@@ -362,6 +362,7 @@ static int hci_dma_queue_xfer(struct i3c_hci *hci,
 	struct hci_rh_data *rh;
 	unsigned int i, ring, enqueue_ptr;
 	u32 op1_val, op2_val;
+	void *buf;
 
 	/* For now we only use ring 0 */
 	ring = 0;
@@ -390,9 +391,10 @@ static int hci_dma_queue_xfer(struct i3c_hci *hci,
 
 		/* 2nd and 3rd words of Data Buffer Descriptor Structure */
 		if (xfer->data) {
+			buf = xfer->bounce_buf ? xfer->bounce_buf : xfer->data;
 			xfer->data_dma =
 				dma_map_single(&hci->master.dev,
-					       xfer->data,
+					       buf,
 					       xfer->data_len,
 					       xfer->rnw ?
 						  DMA_FROM_DEVICE :
diff --git a/drivers/i3c/master/mipi-i3c-hci/hci.h b/drivers/i3c/master/mipi-i3c-hci/hci.h
index f109923f6c3f..f94d95e024be 100644
--- a/drivers/i3c/master/mipi-i3c-hci/hci.h
+++ b/drivers/i3c/master/mipi-i3c-hci/hci.h
@@ -90,6 +90,7 @@ struct hci_xfer {
 		struct {
 			/* DMA specific */
 			dma_addr_t data_dma;
+			void *bounce_buf;
 			int ring_number;
 			int ring_entry;
 		};
-- 
2.42.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

Re: [PATCH 0/4] i3c: mipi-i3c-hci: Functional update

[Alexandre Belloni]

On Thu, 09 Nov 2023 15:37:04 +0200, Jarkko Nikula wrote:
> These are v6.8-rc1 material and not for current cycle.
> 
> With these and handful of local patches [1] I'm able probe this driver
> successfully with an I3C device on the bus and without.
> 
> Also able to communicate with I3C and I2C device from their corresponding
> device drivers. I'm using in my test setup an LSM6DSO sensor (forced to
> I3C mode) and at24c02 I2C EEPROM instantiated from userspace.
> 
> [...]

Applied, thanks!

[1/4] i3c: mipi-i3c-hci: Report NACK response from CCC command to core
      commit: 9e0e9e85e74e4893dc5a2c5a6da54f64cf45290e
[2/4] i3c: mipi-i3c-hci: Do not overallocate transfers in hci_cmd_v1_daa()
      commit: 0be1a06c66c9522abc264bd9cb4df7e676b13ae3
[3/4] i3c: mipi-i3c-hci: Handle I3C address header error in hci_cmd_v1_daa()
      commit: f83f86e506e6b776ba5dd70f919f7e2856f9e061
[4/4] i3c: mipi-i3c-hci: Add DMA bounce buffer for private transfers
      commit: 4afd72876942f2ab1e97e79082464a46ab40a485

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c