chao
/
linuxptp
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
linuxptp/ts2phc.h

65 lines
1.4 KiB
C
Raw Normal View History

ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
/**
* @file ts2phc.h
* @brief Structure definitions for ts2phc
* @note Copyright 2020 Vladimir Oltean <olteanv@gmail.com>
* @note SPDX-License-Identifier: GPL-2.0+
*/
#ifndef HAVE_TS2PHC_H
#define HAVE_TS2PHC_H
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
#include <sys/queue.h>
#include <time.h>
ts2phc: instantiate a pmc node 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>
2020-07-28 07:48:06 +08:00
#include "pmc_common.h"
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
#include "servo.h"
ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
struct ts2phc_slave_array;
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
#define SERVO_SYNC_INTERVAL 1.0
struct clock {
LIST_ENTRY(clock) list;
LIST_ENTRY(clock) dst_list;
clockid_t clkid;
int phc_index;
int state;
int new_state;
struct servo *servo;
enum servo_state servo_state;
char *name;
int no_adj;
int is_destination;
ts2phc: split slave poll from servo loop Since it has been argued that: - a ts2phc slave deals with extts events - a clock deals with synchronization via a servo loop then the code for synchronization should not be part of the implementation of a ts2phc slave. Move it to the main ts2phc.c. Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
2020-08-01 22:45:00 +08:00
int is_ts_available;
tmv_t last_ts;
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
};
ts2phc: instantiate a pmc node 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>
2020-07-28 07:48:06 +08:00
struct port {
LIST_ENTRY(port) list;
unsigned int number;
int state;
struct clock *clock;
};
ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
struct ts2phc_private {
struct ts2phc_master *master;
STAILQ_HEAD(slave_ifaces_head, ts2phc_slave) slaves;
unsigned int n_slaves;
struct ts2phc_slave_array *polling_array;
ts2phc_phc_master: make use of new kernel API for perout waveform This API was introduced for 2 reasons: 1. Some hardware can emit PPS signals but not starting from arbitrary absolute times, but rather phase-aligned to the beginning of a second. We _could_ patch ts2phc to always specify a start time of 0.000000000 to PTP_PEROUT_REQUEST, but in practice, we would never know whether that would actually work with all in-tree PHC drivers. So there was a need for a new flag that only specifies the phase of the periodic signal, and not the absolute start time. 2. Some hardware can, rather unfortunately, not distinguish between a rising and a falling extts edge. And, since whatever rises also has to fall before rising again, the strategy in ts2phc is to set a 'large' pulse width (half the period) and ignore the extts event corresponding to the mid-way between one second and another. This is all fine, but currently, ts2phc.pulsewidth is a read-only property in the config file. The kernel is not instructed in any way to use this value, it is simply that must be configured based on prior knowledge of the PHC's implementation. This API changes that. The introduction of a phase adjustment for the master PHC means we have to adjust our approximation of the precise perout timestamp. We put that code into a common function and convert all call sites to call that. We also need to do the same thing for the edge ignoring logic. Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
2020-05-25 15:57:44 +08:00
tmv_t perout_phase;
ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
struct config *cfg;
ts2phc: instantiate a pmc node 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>
2020-07-28 07:48:06 +08:00
struct pmc_node node;
int state_changed;
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
struct clock *source;
ts2phc: instantiate a pmc node 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>
2020-07-28 07:48:06 +08:00
LIST_HEAD(port_head, port) ports;
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
LIST_HEAD(clock_head, clock) clocks;
ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
};
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
struct servo *servo_add(struct ts2phc_private *priv, struct clock *clock);
struct clock *clock_add(struct ts2phc_private *priv, const char *device);
ts2phc: split slave poll from servo loop Since it has been argued that: - a ts2phc slave deals with extts events - a clock deals with synchronization via a servo loop then the code for synchronization should not be part of the implementation of a ts2phc slave. Move it to the main ts2phc.c. Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
2020-08-01 22:45:00 +08:00
void clock_add_tstamp(struct clock *clock, tmv_t ts);
ts2phc: instantiate a full clock structure for every slave PHC 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>
2020-07-28 07:51:28 +08:00
void clock_destroy(struct clock *clock);
ts2phc: create a private data structure 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>
2020-06-29 03:02:38 +08:00
#include "ts2phc_master.h"
#include "ts2phc_slave.h"
#endif