Re: [PATCH 2/3] sunxi: spl: initialise timer before clocks

["Jernej Škrabec" <jernej.skrabec@gmail.com>]

Dne ponedeljek, 11. avgust 2025 ob 17:52:25 Srednjeevropski poletni čas je Andre Przywara napisal(a):
> On Mon, 11 Aug 2025 17:34:47 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> 
> > Dne sobota, 2. avgust 2025 ob 01:49:17 Srednjeevropski poletni čas je Andre Przywara napisal(a):
> > > Recent changes in the H6 clock code added delay() calls into the SPL clock
> > > setup routine, which requires the timers to work. When compiling for
> > > AArch64, we are always using the Arm Generic Timer (aka. arch timer),
> > > which does not require further setup, hence having an empty timer_init()
> > > routine.
> > > However for 32-bit SoCs we use the Allwinner timers, which require some
> > > setup routine, and hence we need timer_init() to be called before
> > > clock_init().
> > > 
> > > Swap the order of the two calls, to be more robust when compiling the H6
> > > clock code for AArch32 or when using the Allwinner timers for whatever
> > > reason.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > >  arch/arm/mach-sunxi/board.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> > > index fb4837c2082..432b1c10f92 100644
> > > --- a/arch/arm/mach-sunxi/board.c
> > > +++ b/arch/arm/mach-sunxi/board.c
> > > @@ -476,8 +476,8 @@ void board_init_f(ulong dummy)
> > >  	/* Enable non-secure access to some peripherals */
> > >  	tzpc_init();
> > >  
> > > -	clock_init();
> > >  	timer_init();
> > > +	clock_init();  
> > 
> > I contemplated similar change in past. It works fine for 64-bit architectures,
> > but I'm unsure for 32-bit. If you take a look at A83t clock code, it uses
> > sdelay() exactly because timer is not initialized at that time.
> > 
> > So, are you sure that this change has no unwanted side effects?
> 
> No, I am not ;-)
> I was about to test this on some more boards. But I think with the
> change in that direction, the only issue would be if the timer_init() code
> relies on the clocks being set up already. And since timer_init() is only
> *one* rather small function, just doing MMIO accesses, I think the risk is
> quite low.

As long as clock function doesn't need to enable bus or module clock,
everything should be fine. Quick check didn't show any such code so
it is probably safe to switch.

Best regards,
Jernej

> 
> Thanks for having a look anyway, I will report back how the test goes.
> 
> Cheers,
> Andre
> 
> > 
> > >  	gpio_init();
> > >  
> > >  	spl_init();
> > >   
> > 
> > 
> > 
> > 
> 
>