On Fri, Feb 24, 2023 at 02:09:10PM +0000, Renaud Barbier wrote:
>
> > On Thu, Feb 23, 2023 at 01:58:46PM +0000, Renaud Barbier wrote:
> > > diff --git a/arch/arm/lib32/pbl.c b/arch/arm/lib32/pbl.c new file mode
> > > 100644 index 0000000000..f4be7b57dc
> > > --- /dev/null
> > > +++ b/arch/arm/lib32/pbl.c
> > > @@ -0,0 +1,21 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include <asm/system.h>
> > > +#include <clock.h>
> > > +#include <common.h>
> > > +
> > > +void udelay(unsigned long us)
> > > +{
> > > + unsigned long long ticks, cntfrq = get_cntfrq();
> > > + unsigned long long start = get_cntpct();
> > > +
> > > + ticks = us * cntfrq + 999999;
> > > + do_div(ticks, 1000000);
> > > +
> > > + while ((long)(start + ticks - get_cntpct()) > 0); }
> > > +
> > > +void mdelay(unsigned long ms)
> > > +{
> > > + udelay(ms * 1000);
> > > +}
> >
> > This will be compiled for every arm32 build, but the architected timer is not
> > generally available, only a small fraction of CPUs actually have it. I just tested
> > this on a i.MX6 and it just answers with an illegal instruction abort when
> > get_cntfrq() is called.
> >
> > We could name this arm_architected_timer_udelay() or similar.
> >
> > This change should be in a separate patch.
> >
> And then you would add a udelay/mdelay wrapper at the board or machine level?
For now you could create a wrapper at SoC level. However, I have plans
for building multiple arch/arm/mach-*/ in the same barebox, then that
won't work anymore.
I would recommend calling arm_architected_timer_udelay() directly, but
that won't work with code used in multiple SoCs, like drivers/ddr/fsl/.
It would be great to have a general udelay() usable in PBL code, but I
still have no idea how this could be implemented. That's not your
problem though, so a wrapper at SoC level is fine.
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 |
