Firstly, I apologise, Mark. I tried (and failed) to obtain a suitable parallel port interface device, but to no avail (I thought I had access to one, but it appears to have been commandeered by another recently). I'm ordering a similar PCIe card which is based on the Oxford OXPCIe952 chip (a PCIe to Dual Serial and Single Parallel Port Bridge IC, which is a common component on such PCIe interface devices).
The Github project https://github.com/twteamware/raspberrypi-ptp is, unsurprisingly, for a Raspberry Pi. The Github project https://github.com/topics/pps-generator is for a BeagleBoard. Both have some measure of discussion of DeviceTree files, neither has any DKMS support.
The link you posted for the Beaglebone
GPIO PPS generator project is for a Github topic page which may vary in time, potentially becoming less useful to future readers of this post (we all know how Microsoft likes to 'fix' working products). The URL to the Beaglebone GPIO PPS generator project is as follows: https://github.com/jsln/pps-gen-gpio
Irrespective of the merits and pitfalls of the method used to generate a PPS output on a GPIO pin within the Beaglebone kernel module, the kernel module itself should be useable across a range of platforms. All that would be required is to ensure that any pin control settings are defined as appropriate for the target GPIO pin (platform specific) and the relevant settings for the driver (mostly platform-agnostic) are defined within the Device Tree for the target system.
Both the Raspberry Pi and Beaglebone GPIO PPS generator projects make use of Device Tree for the very reasons you'd expect them too - to decouple the kernel module from the platform hardware. And regarding DKMS, not everyone makes use of it. In fact, a lot of individuals and companies don't. To be honest, I could do with learning more about DKMS myself.
As regards the original pps_gen_parport, there are three sets of patches applied to (a) update the time API, (b) select polarity, and (c) add a safety timeout. These have long been public but none has been applied to the implementations using GPIO.
Well, the first patch in your repo (
0-timespec64.patch) replaces data structures and function calls for obtaining system time via now deprecated components of the in-kernel API. From the PPS kernel module perspective, this patch doesn't really affect any functional change. If it were down to me, I'd add some conditional compilation such that the kernel module can be built for old and new kernels alike (the deprecated API was removed in Linux v5.6). This addition could be one potential improvement to both the Raspberry Pi and Beaglebone GPIO PPS projects. After some testing, I might even submit a pull request with these changes incorporated.
However, the latter two patches (
1-polarity.patch and
2-iterations.patch) *do* affect a functional change to the kernel module, as both patches add a new feature.
In the words of the original author, Alexander GQ Gerasiov <gq@cs.msu.su>, the second patch (
1-polarity.patch) adds the following functionality:
On some devices it may be necessary to transmit inverted data. This commit simply adds polarity parameter to define which state represents presence of signal: it equals 0 if signal is on the low level (default), or 1 if signal is on the high level (inverted signal).
In my opinion, this functionality is not essential, but is nice to have. It gives more flexibility to the user of the kernel module without any real cost. Hence, it could also be useful to apply a similar change to the GPIO PPS kernel modules.
The third patch (
2-iterations.patch) adds functionality to prevent a hard-lock situation within the two busy looping sections of the high-resolution timer callback which generates the PPS output (in the event of the system real-time clock not progressing as expected). The absolute value and update frequency offset of this clock, etc, may be adjusted from within both kernel-space and user-space (by applications with the right capabilities - see
man adjtimex(2)). So the failure mode this patch aims to provide some protection against is a very real risk. As the
hrtimer event callback is executed within a hard interrupt context on both standard and real-time (
PREEMPT_RT) Linux kernels, you want to avoid this kind of lock-up from occurring. Hence, I would say that a similar change ought to be applied to all PPS generator kernel modules where this failure mode applies (which will likely be most of those in existence).
Regarding the 'core algorithm' changes, as you called them, I am still undertaking static analysis of the different kernel modules' source. If time permits, I'd also like to undertake some dynamic analysis/testing of the different kernel modules (likely with and without some modifications applied). I'll look to provide separate feedback from static and dynamic analysis, such that I can trickle back my findings a bit at a time. As always, this kind of stuff falls under the category of Your Mileage May Vary (YMMV), so I'd also recommend that any testing undertaken on my systems be repeated on yours.
Do you have a drop-dead date to get this work completed? I'm currently doing this in my spare time (of which I have very little), but I'd like to be able to help you in the required timescales if practicable.
Note that after June, I'll also be available to provide professional support on these matters via consultancy.
Jack