Gary E. Miller writes: > I looked for any GPIO timestamp counter in those docs. I could not find > it. Got a page number? Or maybe see where the gpio driver reads such a > thing?
There is no hardware timestamping, the GPIO just raise interrupts. But there is one single system time counter on the VC4 side (STC) that is used to create all timestamps (even those on the ARM side), advancing each microsecond (it could be run at different speeds, but 1MHz it is when running Linux). >> On another tangent back to NTP, I'm wondering if it wouldn't make >> sense to offload the timestamp filtering at least to the VC4. Most >> NTP boxes would run headless anyway, so there'd be 16 processors >> sitting idle for that sort of thing. > > Gack. It would be non-portable and very host specific. Once the > timestamp is put on the PPS pulse by the kernel driver there > is no time critical task left to do, and the PPS thread is pretty > small. The idea would be to timestamp at the VC4 side entirely, then use a new PPS kernel module to read the results back into ARM for ntpd to use. > Maybe if once gcc gets a good generic GPU offloading mode, but I suspect > the context switching would swamp any benefits. You'd cut out the context switches and the interrupt latency from the critical timing path. Plus there's a 19.2MHz clock on that side of the SoC that could potentially be used to get better resolution timestamps. > On the flip side, it makes it a lot easier for the kernel to deal > with RAM over 2 GB, so maybe Pi's would get more RAM. Sorry to burst your bubble, but the VC4 is architecturally limited to exactly one single GB of RAM. > The big thing for NTP and gpsd would be the 64 bit math. Both do a lot > of 64 bit math. You can already do that, the length of the addresses doesn't have anything to do with that. > Going to native A53 mode from A7 would also buy us better floating > point, better SIMD, more GP registers, crypto extensions and security > extensions. You can already target neon. The crypto and security extensions may not even be implemented. > And maybe even hope for big.LITTLE mode, which would likely > not help the time keeping application Not implemented either, both the BCM2836 and the BCM2837 have a symmetric quad-core cluster. > Linux is trying to kill off x86 (32bit) mode. So I expect 32 bit will > get less love in the future. That's an entirely different kettle of fish, mainly going away because such hardware is hard to come by these days. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
