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