On Tuesday, September 11, 2018 1, Rob Herring wrote: > Well before we get to initcalls, the kernel calls the arch specific > time_init() which (on ARM) calls of_clk_init (for all the reasons > above) and then timer_probe(). When timer_probe returns, it is > expected that you have setup a clocksource and clockevent. If you > haven't, then at some point before we get to initcalls we should hang > because we're not getting any timer interrupts and time is not > advancing.
What I get now is: [ 0.000000] timer_probe: no matching timers found ... ... [ 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns ... ... But then later on in boot, I'll get (with my subsys_initcall timer fix) ... ... [ 0.000000] SCSI subsystem initialized [ 0.000000] usbcore: registered new interface driver usbfs [ 0.000000] usbcore: registered new interface driver hub [ 0.000000] usbcore: registered new device driver usb [ 0.000000] clocksource: ostm: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 28958491609 ns [ 0.000619] sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 32537631224ns [ 0.008599] ostm: used for clocksource [ 0.018926] ostm: used for clock events [ 0.133339] clocksource: Switched to clocksource ostm [ 0.821474] NET: Registered protocol family 2 [ 0.840624] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes) [ 0.850549] TCP established hash table entries: 1024 (order: 0, 4096 bytes) ... ... > Maybe you > just get lucky and it works as long as no thread blocks (e.g. on a > msleep). You're right. If I put in a msleep() before my timer is up and running, it hangs. As far as I can tell, nothing before device_initcall seems to call anything like msleep. > If things changed and you can setup a timer in an initcall, > then why are folks still trying to do things like early platform > drivers. Regular drivers would work and we should be able to > completely remove CLK_OF_DECLARE and TIMER_OF_DECLARE. I wonder if the reason is because you can't assign a priority to your driver when you declare it with xxx_initcall( ). So, your driver ends up in the same table as all the other drivers and you are not guaranteed the order in which they probe. So, the answer was to make a NEW table and register it using TIMER_OF_DECLARE and CLOCK_OF_DECLARE. I wonder they just didn't make a clock_initcall() and timer_initcall() instead. Chris
