multiplexing setstatclockrate through fdt logic

Yuri Honegger <[email protected]> Fri, 24 Apr 2026 08:17:44 +0200
Newsgroups gmane.os.netbsd.ports.arm
Message-ID <[email protected]>
Hi everyone,
FDT-based clock drivers need to expose a setstatclockrate function. =
Currently, this function is global and there can only be one function =
per build configuration, even if there are multiple timer drivers. =
Additionally, the function is optional in the sense that you can leave =
it empty and it will work just fine (internally, it will use hardclock() =
instead of a dedicated statclock).

Right now, there are only two configurations with more than one driver, =
GENERIC and GENERIC_V5. Each takes a different approach to only being =
able to expose a single implementation for all timers: GENERIC declares =
setstatclockrate in gtmr.c as normal symbol and in a9tmr.c as a weak =
symbol. The linker then picks the gtmr variant. GENERIC_V5 solves the =
problem by having some logic in the "wrong" driver: imx23_timrot.c =
handles setstatclockrate for am18xx_timer.c.

I think both solutions are ugly. Therefore, I propose introducing an =
arm_fdt_timer_register_setstatclockrate function for drivers to register =
their setstatclockrate implementation so that it can be called from =
setstatclockrate. This is very similar to the solution for =
cpu_initclocks with arm_fdt_timer_register.

Since it is fine (and common) to have an empty setstatclockrate, I've =
made it that not providing an implementation to =
arm_fdt_timer_register_setstatclockrate is okay. In that case, nothing =
is done on setstatclockrate.

One open question for me is if we should keep it arm-only or if other =
FDT-based ports could benefit of it too. For now, I've kept it arm-only =
because it feels like a natural companion to arm_fdt_timer_register, =
which is arm only. Additionally, only arm has that high of a timer =
diversity, so it is unlikely to provide as many benefits on other =
platforms.

Multiplexed setstatclockrate is only really beneficial on configurations =
with more than two timer types. As far as I know, this is just GENERIC =
and GENERIC_V5. Enabling it on other platforms doesn't hurt, but it =
doesn't really bring a benefit either. To avoid accidentally breaking =
things, I've only enabled it on the configurations that benefit from it. =
Configurations without device trees or with the multiplexed =
setstatclockrate disabled get a setstatclockrate using an ifdef in each =
timer as before.

The code is on github, or as patch:
=
https://github.com/NetBSD/src/compare/trunk...recursivetree:netbsd-src:set=
statclockrate?expand=3D1=20
https://yurix.ch/netbsd/setstatclockrate.patch=20

Unless I hear something, I'll merge it in a few days.

- yuri