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

[Sascha Hauer]

On Mon, Jan 30, 2023 at 11:24:55PM +1100, John Watts wrote:
> On Mon, Jan 30, 2023 at 01:17:52PM +0100, Sascha Hauer wrote:
> > On Mon, Jan 30, 2023 at 09:42:53PM +1100, John Watts wrote:
> > > On Mon, Jan 30, 2023 at 11:27:27AM +0100, Sascha Hauer wrote:
> > > > 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.
> > > 
> > > Yikes! I'm glad I broke this in to its own patch then. :)
> > > 
> > > I did copy this code from these boards:
> > > 
> > > arch/arm/boards/cm-fx6/lowlevel.c
> > > arch/arm/boards/skov-imx6/lowlevel.c
> > > arch/arm/boards/technexion-wandboard/lowlevel.c
> > > arch/arm/mach-imx/xload-gpmi-nand.c
> > > arch/arm/mach-imx/imx6-mmdc.c (uses 1000 loops)
> > > 
> > > Maybe it's time for an i.MX6-wide early udelay?
> > 
> > i.MX6 is not enough, the code could run on other i.MX SoCs as well.
> 
> Do you think a patch that implements udelay in PBL using the code below with
> a fixed base and drops these implementations would be a good idea?

As said, the code is also for other i.MX SoCs, so a fixed base address
won't do it. You would first have to detect the SoC type, but we can
only get this from the device tree.

I'm afraid there is no good solution for this problem, at least we
haven't found any over the years.

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 |