This introduces the '-a' option in ts2phc, an option inspired from
phc2sys that puts the clocks in "automatic" mode. In this mode, ts2phc
listens, as a PMC, to port state change events from ptp4l, and detects
which port state machine, if any, has transitioned to PS_SLAVE. That
port's clock will become the synchronization master for the hierarchy
described by ts2phc.
The use case is a multi-switch DSA setup with boundary_clock_jbod, where
there is only one grandmaster, connected to one switch's port. The other
switches, connected together through a PPS signal, must adapt themselves
to this new source of time, while the switch connected to the GM must
not be synchronized by ts2phc because it is already synchronized by
ptp4l.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
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".
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Eliminate the ad-hoc use of global variables in the ts2phc program by
introducing one data structure that incorporates them. This might make
the code more understandable to people coming from a kernel background,
since it resembles the type of data organization used there. It is also
now closer to the data organization of phc2sys, a similar program in
both purpose and implementation.
The reason why this is needed has to do with the ts2phc polymorphism for
a PPS master.
In the next patches, PPS masters will expose a struct clock, which will
be synchronized from the main ts2phc.c.
Not all PPS masters will expose a clock, only the PHC kind will. So the
current object encapsulation model needs to be loosened up little bit,
because the main ts2phc.c needs to synchronize a list of clocks, list
which is populated by the slaves and the masters which are capable of
being synchronized.
So instead of having the translation modules of ts2phc communicate
through global variables, let's make struct ts2phc_private the common
working space for the entire program, which is a paradigm that is more
natural.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Vladimir Oltean