Re: [PATCH] I2C: i.MX: early: Use internal udelay

[Sascha Hauer <sha@pengutronix.de>]

On Fri, Jan 27, 2023 at 05:56:43AM +1100, John Watts wrote:
> udelay isn't provided in the PBL, so use our own definition.
> 
> This avoids boards having to define udelay in their code.
> 
> Signed-off-by: John Watts <contact@jookia.org>
> ---
>  drivers/i2c/busses/i2c-imx-early.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-early.c b/drivers/i2c/busses/i2c-imx-early.c
> index 6c8bdc7904..fcf279eff8 100644
> --- a/drivers/i2c/busses/i2c-imx-early.c
> +++ b/drivers/i2c/busses/i2c-imx-early.c
> @@ -90,6 +90,13 @@ static int i2c_fsl_acked(struct fsl_i2c *fsl_i2c)
>  	return i2c_fsl_poll_status(fsl_i2c, 0, I2SR_RXAK);
>  }
>  
> +static void __udelay(int us)
> +{
> +	volatile int i;
> +
> +	for (i = 0; i < us * 1000; i++);
> +}

This takes around 5 times too long on a i.MX8MM and around 50 times too
long on a i.MX6Q. This was measured under a regular barebox on the
shell. In an early environment with MMU disabled it takes 730 times too
long.

Maybe we could do this:

static void __udelay(void *base, int us)
{
	int i;

	for (i = 0; i < us * 4; i++)
		readb(base);
}

The time spent for a register read depends on the bus clock which
doesn't change that much between the different SoCs.

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 |