u-blox LKM Timemark driver

[MLewis]

Achim,

On 21/08/2018 2:43 PM, Achim Gratz via devel wrote:
> There's no official documentation that I'm aware of, but from the bits 
> and pieces scattered about the uBlox forum I guess you'd be wrong. I'm 
> almost certain that the timemark feature is implemented using a 
> hardware timer, specifically using the same free-running counter that 
> produces the local clock and then four capture registers triggered by 
> the rising and falling edges of the two possible inputs. 
That would mean the trigger lag should be close to the rise time of the 
port and the timemark should be extremely close to the time captured 
back in the kernel?
A case for making the leads as short as possible, or just not stupidly long?
I've got leads from the Pi to the com breakout board that are 140 mm, 
and the com cable to the GPS board is ~180 mm. Or does the resolution in 
the kernel mean these lengths aren't relevant?
>  There's a counter that tells you how many edges have been seen as 
> well (that will enable you to use much higher frequency signals 
> provided the frequency stays stable over one second and just measure 
> the last edge for the fractional timing)
Interesting. I hadn't realized why they did that. And I'm sure I don't 
understand the significance of that, but it sounds intriguing.
>
>> We may get less jitter using the offsets from the two
>> rises. Or the two falls. Or only the second fall. Until we have data,
>> we won't know. Will it matter? Not likely, but what if it does. And
>> it's cheap to know. Code for that is already done; add a lead for the
>> PPS pin.
> You'd get the same effect much cheaper is you simply set the period
> slightly longer than one second.
>
> Regards,
> Achim.
I'll worry about why that is later.

Thanks,

Michael