Re: [PATCH 0/2] clocksource/drivers/arm_arch_timer_mmio: Restore support for early init

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Thu, Jun 11, 2026 at 08:59:19AM +0100, Marc Zyngier wrote:
> On Wed, 10 Jun 2026 18:53:09 +0100,
> Stephan Gerhold <stephan.gerhold@linaro.org> wrote:
> > 
> > Jack reported a regression for some single-core Qualcomm platforms (e.g.
> > MDM9625, MDM9607) that no longer boot because no timers can be found during
> > early boot [1].
> 
> Again, this is *not* a regression. These machines were *never*
> supported upstream.
> 

Sorry, I'll reword this next time. MDM9607 does have all required
drivers and compatibles upstream already and is just missing the actual
DT so it does feel somewhat supported to me, but I'm fine treating this
as a feature extension without stable backporting etc.

> > These platforms rely on an obscure timer setup where the
> > global Arm MMIO timer (arm,armv7-timer-mem) is used as the only available
> > timer for the CPU. This setup used to work fine until commit 0f67b56d84b4
> > ("clocksource/drivers/arm_arch_timer_mmio: Switch over to standalone
> > driver") when the early timer initialization using TIMER_OF_DECLARE() was
> > removed when moving to the standalone MMIO driver.
> > 
> > There doesn't seem to be any other usable CPU timer on those platforms, so
> > this series restores the early timer support using TIMER_OF_DECLARE()
> > inside the new standalone arm_arch_timer_mmio driver. This is pretty ugly,
> > but I could not think of a better solution so far. I tried to keep the
> > ugliness for the two probe paths as limited as possible. :-)
> > 
> > If someone has a better idea how to solve this, I would be happy to try it.
> 
> I would suggest finding out what is the latest point in the init
> sequence where the timer can be probed without preventing boot.
> 

It doesn't get far without having any timer:

[    0.000000] timer_probe: no matching timers found
[    0.000000] entering initcall level: console
[    0.000000] calling  con_init+0x0/0x354 @ 0
[    0.000000] Console: colour dummy device 80x30
[    0.000000] initcall con_init+0x0/0x354 returned 0 after 0 usecs
[    0.000000] sched_clock: 32 bits at 300 Hz, resolution 3333333ns, wraps every 7158278824300949ns
[    0.000000] Calibrating delay loop... 
<board hangs>

If you look at start_kernel() in init/main.c it's basically time_init()
that would normally probe the TIMER_OF_DECLARE() timers and
calibrate_delay() that needs some timer to finish. There is also
random_init() that comes directly after time_init(), which already wants
to have access to timestamp counters. I don't see any other suitable
place to hook into. :-/

I also don't see any other timer we could use, at least for MDM9625.
It's a single-core Cortex-A5 and the downstream kernel defines only the
arm,armv7-timer-mem, which seems to be used for everything... (The
situation for MDM9607 is a bit different, but not any less messy,
unfortunately.)

Thanks,
Stephan