Re: [PATCH 1/2] dt-bindings: document renesas-ostm timer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux