Hi Chris, On Fri, Jan 20, 2017 at 4:56 AM, Chris Brandt <Chris.Brandt@xxxxxxxxxxx> wrote: > On Monday, January 16, 2017, Geert Uytterhoeven wrote: >> As they're independent channels, it doesn't matter which one is used for >> which function, right? >> >> You could use the first probed channel for the most important function >> (clocksource?), and the second one for the other function (clockevent). >> So there's no need for specifying this in DT. >> >> Does that make sense? > > So I changed the driver, and it works good. I now have 2 independent nodes > in the DT. The first one becomes a clocksource, and anything after that is > a clockevent. > > > > If you don't mind, I have a couple clock questions before I submit V2 of > my patch series. > > > You can see that the resolution of time keeping is better with OSTM as > opposed to the default MTU2: > > MTU2: > [ 0.000000] sh_mtu2 fcff0000.timer: ch0: used for clock events > [ 0.000000] sh_mtu2 fcff0000.timer: ch0: used for periodic clock events > [ 0.260000] NET: Registered protocol family 2 > [ 0.270000] TCP established hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.270000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.280000] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.290000] UDP hash table entries: 256 (order: 0, 4096 bytes) > [ 0.300000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) > [ 0.300000] NET: Registered protocol family 1 > [ 0.320000] RPC: Registered named UNIX socket transport module. > [ 0.320000] RPC: Registered udp transport module. > [ 0.330000] RPC: Registered tcp transport module. > [ 0.330000] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 0.350000] futex hash table entries: 256 (order: -1, 3072 bytes) > [ 0.370000] workingset: timestamp_bits=30 max_order=13 bucket_order=0 > [ 0.380000] squashfs: version 4.0 (2009/01/31) Phillip Lougher > > > OSTM: > [ 0.000000] sh_mtu2 fcff0000.timer: ch0: used for clock events > [ 0.000000] sh_mtu2 fcff0000.timer: ch0: used for periodic clock events > [ 0.000000] clocksource: ostm: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 57352151442 ns > [ 0.010071] sched_clock: 32 bits at 33MHz, resolution 30ns, wraps every 64440619504ns > [ 0.018536] ostm fcfec000.ostm: used for clocksource > [ 0.025272] ostm fcfec400.ostm: used for clock events > [ 0.052944] sh_mtu2 fcff0000.timer: PM domain cpg_clocks will not be powered off > [ 0.079591] clocksource: Switched to clocksource ostm > [ 0.333650] NET: Registered protocol family 2 > [ 0.342142] TCP established hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.349994] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.356885] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.364618] UDP hash table entries: 256 (order: 0, 4096 bytes) > [ 0.371175] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) > [ 0.378885] NET: Registered protocol family 1 > [ 0.389405] RPC: Registered named UNIX socket transport module. > [ 0.396103] RPC: Registered udp transport module. > [ 0.401092] RPC: Registered tcp transport module. > [ 0.406201] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 0.421042] futex hash table entries: 256 (order: -1, 3072 bytes) > [ 0.441390] workingset: timestamp_bits=30 max_order=13 bucket_order=0 > [ 0.451111] squashfs: version 4.0 (2009/01/31) Phillip Lougher Good! It takes longer to boot, though. I guess due to more kernel output? > My questions: > > #1. > Early in boot, I see this: > > [ 0.000000] clocksource_probe: no matching clocksources found > [ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns > > So how am I supposed to enable earlytimer? (MTU2 or OSTM)? > > I see from this commit that you've been changing things around: > https://patchwork.kernel.org/patch/6943101/ > > > > #2. > Now I have mtu2 and ostm for clocksource and clockevents, but OSTM has a much > better resolution, so in a real system, would I just remove the mtu2 node in > the board's DT file? (r7s72100-rskrza1.dts) > > Basically, it just sits there because I assume the kernel will always go for > the higher rated clock. Sorry, I'm no timer expert. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds