[LinuxPPS] linuxpps and devicetree support

[tlhackque]

On 26-Apr-13 04:37, Jan Lübbe wrote:
> On Fri, 2013-04-26 at 17:37 +1000, Damien Dusha wrote:
>> My hack-up had the following for an i.mx53-based board, but I am yet
>> to test it:
>>
>>      pps at gps0 {
>>          compatible = "pps-gpio";
>>          gpios = <&gpio0 2 0>;
>>          assert-falling-edge = 1;
>>          capture-clear = 1;
>>      };
>>
>>
>> What's your opinion on explicit values for the flags vs the mere
>> existance of the flags?
> Usually in DT, boolean options are defined simply by existence.
>
> Is there a preexisting terminology for things like which edge to
> capture, polarity, assert/clear in the PPS area? Do we really need more
> than whether the rising or falling edge is aligned to the second?
>
> Regards,
> Jan

Yes, capture and assert have different meanings and effects.  There are 
actually four major implementation considerations, though they're folded 
into two here.  Software: which edges to record. Hardware: Assertion 
level (is a low voltage represented as a '0' or a '1' to software.  
Interrupt: what causes interrupts (level or edge) and when (true or false).

Because neither the documentation conventions nor the hardware 
implementations of GPIO have been standardized, this tends to get 
confusing very fast.

Usually, the hardware definitions are with respect to the voltage levels 
on the pin - they don't take into account the assertion.  But one has to 
read carefully.  If a manual says '0 to 1 transition', that's usually 
AFTER the assertion has been taken into account.  If it says 'rising 
edge' - it could be either way, and you have to study carefully.

A typical (simplified) GPIO pin will look like:

/-->[current state register] 1 or 0
External signal--->receiver-->[Invert if asserted-low]-->
\-->[edge detector]-->Interrupt

The edge detector may or may not be programmable, as may the interrupt 
level.  And [edge detector] may be
pure hardware (edge-triggered) or a combination of hardware and software 
(level-sensitive).

kernel/Documentation/gpio.txt is in introduction to the Linux 
abstractions and lists more variables.

capture {clear,assert} tells PPS software which edge(s) to record and 
deliver to userspace.

assert {rising,falling} edge tells GPIO which edge(s) it should program 
to interrupt, and which logic level is the asserted (true, '1') state.  
PPS only cares about edges, so hardware level-sensitive lines are turned 
into edges by the driver stack.

If the hardware won't interrupt on the correct edge, the driver has to 
poll for the transition after receiving the interrupt on the wrong 
edge.  This is a waste of CPU cycles, and usually adds jitter.

Consider the Garmin 18xLVC.  The PPS rising edge is controlled 
(triggered by hardware in the receiver); the falling edge is not (it's 
programmable width, has high jitter).  Most interfaces have a level 
shifter, which inverts the signal.

So you want assert-falling to capture the controlled edge.  (rising edge 
in the garmin doc, but falling after the inversion in the interface.)  
capture-assert tells PPS to record the assertion (controlled edge).

capture-clear would tell PPS to record the deassertion (falling in the 
garmin doc) - which you might want to do if you are verifying the pulse 
width.

Also, you DON'T want to tell NTP's PPS (via fudge) to sync to the wrong 
edge by inverting the capture - although it will appear to work, the 
effect is to use the uncontrolled edge of the pulse.  And you 
(correctly) see large jitter.

If your interface doesn't have an inverting level shifter, assert-rising 
+ capture assert.

-- 
This communication may not represent my employer's views,
if any, on the matters discussed.