Kernel PPS processing

[Gary E. Miller]

Yo Achim!

On Tue, 05 Jul 2016 21:58:12 +0200
Achim Gratz <Stromeko at nexgo.de> wrote:

> 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).

Well, early it was asserted that such a thing did exist.  I'm glad 
that is now put to rest.

> > 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.

Some ARM kernel guru would have to do that.  NTPsec is portable code.

> > 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.

Reduce, not eliminate.  The VC4 has its own context switching and latency.

>  Plus there's a 19.2MHz clock on that side of
> the SoC that could potentially be used to get better resolution
> timestamps.

Which can provdie 38.4MHz resolution.

But we are still trying to get the simple GPIO fix to read both PPS
edges in the kernel.  I would enjoy watching someone try to work this
idea in.

> > 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.

Who mentioned VC4?  That is the video part of the BCM2837.  We were
talking about the linux kernel on ARM.  When you add swap the virtual
memory size goes way past 1GB.

And as I said, I expected this to lead to more RAM, I did not say it
already had that much 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.

Citation please?  I know that addresses and math are only slightly
related, but even the Intel can't do 64 bit math with a 32 bit kernel.
Unless something changed recently.

When doing a context switch a 32 bit kernel does not know how to save
64 bit registers.  I've watched people try this on Intel and fail.

> > 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.

I'm more interested in the 64 bit math for NTPsec and gpsd.  That alone
would be worth it for me.

> > 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.

Sad...

> > 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.

I don't care why it is going away, but the fact it is going away will
mean fewer eyes on the code, thus declining code quality.

Same thing happened in the 8 to 16, and 16 to 32 bit tranistioned.  The
older code bit tatted.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160705/486bcdf8/attachment.bin>