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@xxxxxxxxxx>
> > ---
> > 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
