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

[Jules Maselbas <jmaselbas@kalray.eu>]

Hi John and Sascha,

On Mon, Jan 30, 2023 at 11:27:27AM +0100, Sascha Hauer wrote:
> 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.
> 

Some arm devices have an architecture timer, isn't it possible to use
the udelay defined in arch/arm/lib64/pbl.c on i.MX ? I am not very
experienced on ARM cpus, is this only possible on armv7/armv8, and not
on every i.MX SoCs ?

Cheers,
-- Jules