multiplexing setstatclockrate through fdt logic

[Yuri Honegger <yuri.honegger%icloud.com@localhost>]

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:setstatclockrate?expand=1 
https://yurix.ch/netbsd/setstatclockrate.patch 

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

- yuri