[LinuxPPS] PPS on Raspberry Pi - with device tree

[tlhackque]

On 10-Aug-16 03:55, Jan Lübbe wrote:
> On Di, 2016-08-09 at 18:46 -0400, tlhackque wrote:
>> Add assert_falling_edge=true to config.txt, e.g.:
>>
>> dtoverlay=pps-gpio,gpiopin=24,assert_falling_edge=true
>>
>> Reboot, and you're in business.
>>
>> In debugging this, I noticed that the driver doesn't have a
>> "capture_clear" parameter for the device tree.
>> I think one should be added - there is code for this on the "pdata"
>> path.  Something like:
>> if (of_get_property(np, "capture-clear", NULL))
>>             data->capture_clear = true;
>> at line 122 should do it.  Then the DT and pdata paths should be equivalent.
>>
>> For reference, the RPi issue for this is
>> https://github.com/raspberrypi/linux/issues/1590
> No. As the DT should describe the hardware, it only describes which edge
> is the assert. Which edge is captured at is configured by userspace at
> runtime.
>
> NTPd can configure the PPS capture itself or you can use pps-tools.
>
> Regards,
> Jan
NTPd isn't the only client.

The driver (drivers/pps/clients/pps-gpio.c) is what captures the
timestamp at interrupt level.
*It* is the code which calls pps_register_source().  The PPS userspace
tools will not see
capture_clear events unless the capture_clear flag is asserted. 
(Neither will ntpd, though in
most configurations it doesn't care.  So the default reduces event
generation by 1/2.) The flag
allows both edges to be captured.

The driver provides the ability to configure capture_clear on the
traditional configuration code path.
Since DT is the new way to configure the driver, DT should too.   With
the Raspbian implementation,
there is no explicit modprobe; DT (proper, or the config.txt overlay)
triggers driver loading and is the
only way to pass parameters.

I don't think 2 lines of code is too high a price for consistency with
past practice.

If you look at the overlays/README, you will see other driver
configuration parameters that aren't
strictly hardware configuration.  E.g. "debug=n", "rotate=n", dma
threshold...
Note that the next release of the RPi kernel will require DT.

That said, I don't require capture-clear at the moment, so I'll leave
further arguments on the merits
for when I do - or someone else does.