[PATCH] I2C: i.MX: early: Use a custom delay on i.MX6

[PATCH] I2C: i.MX: early: Use a custom delay on i.MX6

[John Watts]

The i.MX early I2C code requires waiting for the controller to settle
after configuration. This is currently done using udelay which is
supported on ARMv8 but not on ARMv7.

For the i.MX6 we will have to use a custom delay. This was only
tested on the i.MX6Q but should work on all other i.MX6 chips.

Signed-off-by: John Watts <contact@jookia.org>
---
 drivers/i2c/busses/i2c-imx-early.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx-early.c b/drivers/i2c/busses/i2c-imx-early.c
index 6c8bdc7904..30cc65ca86 100644
--- a/drivers/i2c/busses/i2c-imx-early.c
+++ b/drivers/i2c/busses/i2c-imx-early.c
@@ -90,6 +90,28 @@ static int i2c_fsl_acked(struct fsl_i2c *fsl_i2c)
 	return i2c_fsl_poll_status(fsl_i2c, 0, I2SR_RXAK);
 }
 
+static void i2c_fsl_settle(struct fsl_i2c *fsl_i2c)
+{
+#ifdef CPU_ARCH_ARMv8
+	udelay(100);
+#else
+	/*
+	 * We lack udelay on the i.MX6 prebootloader, so delay
+	 * manually: On an i.MX6 with a 66Mhz I2C peripheral clock
+	 * one cycle of this loop takes 1.30us,
+	 * this means we have to wait for 76.9 microseconds.
+	 *
+	 * This clock may be 44Mhz if the BT_FREQ eFUSE is set,
+	 * this just means it will take 150 microseconds.
+	 */
+
+	volatile int i = 0;
+
+	for (i = 0; i < 77; i++)
+		fsl_i2c_read_reg(fsl_i2c, FSL_I2C_I2SR);
+#endif
+}
+
 static int i2c_fsl_start(struct fsl_i2c *fsl_i2c)
 {
 	unsigned int temp = 0;
@@ -104,7 +126,7 @@ static int i2c_fsl_start(struct fsl_i2c *fsl_i2c)
 			  fsl_i2c, FSL_I2C_I2CR);
 
 	/* Wait controller to be stable */
-	udelay(100);
+	i2c_fsl_settle(fsl_i2c);
 
 	/* Start I2C transaction */
 	temp = fsl_i2c_read_reg(fsl_i2c, FSL_I2C_I2CR);
-- 
2.39.1

Re: [PATCH] I2C: i.MX: early: Use a custom delay on i.MX6

[Sascha Hauer]

On Wed, Feb 01, 2023 at 08:44:35PM +1100, John Watts wrote:
> The i.MX early I2C code requires waiting for the controller to settle
> after configuration. This is currently done using udelay which is
> supported on ARMv8 but not on ARMv7.
> 
> For the i.MX6 we will have to use a custom delay. This was only
> tested on the i.MX6Q but should work on all other i.MX6 chips.
> 
> Signed-off-by: John Watts <contact@jookia.org>
> ---
>  drivers/i2c/busses/i2c-imx-early.c | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-early.c b/drivers/i2c/busses/i2c-imx-early.c
> index 6c8bdc7904..30cc65ca86 100644
> --- a/drivers/i2c/busses/i2c-imx-early.c
> +++ b/drivers/i2c/busses/i2c-imx-early.c
> @@ -90,6 +90,28 @@ static int i2c_fsl_acked(struct fsl_i2c *fsl_i2c)
>  	return i2c_fsl_poll_status(fsl_i2c, 0, I2SR_RXAK);
>  }
>  
> +static void i2c_fsl_settle(struct fsl_i2c *fsl_i2c)
> +{
> +#ifdef CPU_ARCH_ARMv8
> +	udelay(100);
> +#else
> +	/*
> +	 * We lack udelay on the i.MX6 prebootloader, so delay
> +	 * manually: On an i.MX6 with a 66Mhz I2C peripheral clock
> +	 * one cycle of this loop takes 1.30us,
> +	 * this means we have to wait for 76.9 microseconds.
> +	 *
> +	 * This clock may be 44Mhz if the BT_FREQ eFUSE is set,
> +	 * this just means it will take 150 microseconds.
> +	 */

I rounded up to 100 cycles and rephrased this to be a little less i.MX6
centric:

	/*
	 * We lack udelay on the 32bit i.MX SoCs, so delay manually: On an
	 * i.MX6 with a 66Mhz I2C peripheral clock one cycle of this loop
	 * takes 1.30us. Let's be generous and round up to 100 cycles. Other
	 * i.MX SoCs do not have a higher peripheral clock, so we should be
	 * safe here as well.
	 */

In the end it doesn't hurt when it takes a little longer.

Applied, thanks

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] I2C: i.MX: early: Use a custom delay on i.MX6

[John Watts]

On Thu, Feb 02, 2023 at 08:35:27AM +0100, Sascha Hauer wrote:
> I rounded up to 100 cycles and rephrased this to be a little less i.MX6
> centric:
> 
> 	/*
> 	 * We lack udelay on the 32bit i.MX SoCs, so delay manually: On an
> 	 * i.MX6 with a 66Mhz I2C peripheral clock one cycle of this loop
> 	 * takes 1.30us. Let's be generous and round up to 100 cycles. Other
> 	 * i.MX SoCs do not have a higher peripheral clock, so we should be
> 	 * safe here as well.
> 	 */
> 
> In the end it doesn't hurt when it takes a little longer.

Makes sense. Thanks!

> Applied, thanks
> 
> Sascha

John.