On Tue, Aug 18, 2020 at 02:19:33AM +0300, Vladimir Oltean wrote: > Slaves in ts2phc are PHC devices that implement the extts kernel API. > They are slaves just in the sense that they timestamp a pulse emitted by > somebody else. > > Currently in ts2phc, PPS slaves are also the only candidates for the > clocks that get synchronized. There are 2 aspects that make this too > restrictive: > > - Not all PPS slaves may be synchronization slaves. Consider a dynamic > environment of multiple DSA switches using boundary_clock_jbod, and > only one port is in the PS_SLAVE state. In that case, the clock of > that port should be the synchronization master (called the "source > clock" from now on, as far as ts2phc is concerned), regardless of > whether it supports the extts API or not. > > - Not all synchronization slaves may be PPS slaves. Specifically, the > "PHC" type of PPS master in ts2phc can also be, fundamentally, > disciplined. The code should be prepared to handle this by recognizing > that things that can be disciplined by a servo should be represented > by a "struct clock", and things that can timestamp external events > should be represented by a "struct ts2phc_slave".
A while back there were patches for the TI am335x (aka Beagle Bone) that enabled a PPS output on a PWM pin based on the feedback from the signal back into the MAC's external time stamp unit. Did you see those patches? And if so, do you think that your new framework could support that operations? (I'm asking because the PWM patch series had an ad-hoc user space utility that I disliked. It would be much better to add that mode to ts2phc if we can make it fit.) Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
