Re: [Linuxptp-users] How to use common (v)clock for physically different PHCs?

Hi Vladimir,

I had a look at the clock distribution internal and external of SoC, as far as understood, both PHCs use clocks which are phase locked to each other.
Also run a test for several days, repeatedly sampled the PHCs and it shows they are in sync, without the need to re-sync.

In current development phase, just to evaluate the options, we have direct register access from user space, not changed the ocelot ptp driver.

Thanks for your info, which helped a lot.






> Hi Vladimir,
>
> thanks for your answer.
>
> We do not have a connection between EC1_1588_PULSE_OUT1 and SWITCH_1588_DAT0 on our board, so this option is not possible for us.
>
> But we use this trigger signal, which actually is EC1_1588_TRIG_IN1 and SWITCH_1588_DAT1. Both pins are connected together to a GPIO pin.
> In ES_DEVCPU_PTP_PTP_PINS_PTP_PIN_CFG register, SWITCH_1588_DAT1 is configured for STORE action.
> Generating an edge on these trigger signals is latching a timestamp of the ENETC (aka /dev/ptp0) and SWITCH (aka /dev/ptp1).
> As the input clocks of ENETC and SWITCH is derived from the same clock source, the PHCs always run at the same speed (with period configured in ENETC TMR_CTRL and ES_DEVCPU_PTP_PTP_CFG_PTP_SYS_CLK_CFG).

Have you studied the clock distribution trees for the ENETC and the Felix switch IPs before drawing the conclusion that their input clocks are derived from the same source? As far as I see, ENETC, through HWA_CGA_M4_CLK_SEL, uses Cluster Group A PLL 2 divided by 3 as clock
(400 MHz), whereas Felix has its sys_clk at 156.25 MHz and it comes from one of the SerDes PLLs, depending on the particular RCW configuration.

> When latching the timestamps of ENETC and SWITCH, we can calculate the offset between them, which in turn we use to clock_adjtime(ADJ_SETOFFSET|ADJ_NANO) one PHC to the other.
> Doing this in the startup phase, we can guarantee that /dev/ptp0 and /dev/ptp1 is synchronized, but yes, PHC subsystem does not know that they are now actually equivalent.

Aha, so you've implemented the extts API in the ocelot ptp driver?
Do you plan to upstream that work?

A pulse output from the ENETC PHC which is an input to the Felix PHC is not strictly necessary. Your way should be just fine - a GPIO output which is input both to ENETC and to Felix is equally fine, and ts2phc should be able to work with that. I guess you're looking at a "generic"
source of 1-PPS signal, when you open up the ts2phc manual.

> When later ptp4l wants to adjust the PHC according to an external PTP master, it will do this only on one of the two PHCs, therefore they will be no longer in sync.

This is a similar reason to the one for which I modified ts2phc to monitor the direction of ptp4l's synchronization dynamically. If the slave port of the ptp4l BC is an ENETC port, then the Felix PHC gets synchronized to the ENETC PHC, otherwise the ENETC PHC gets synchronized to the Felix PHC.
https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/thread/20200830234525.3311891-11-olteanv%40gmail.com/

I've only tried it with the "PHC" kind of sources of 1-PPS signals.
If it doesn't work with a "generic" source, it probably isn't too hard to modify ts2phc to treat that case reasonably.

> To avoid this, the idea was to create a vclock /dev/ptp2 based on /dev/ptp0. And to let /dev/ptp0 and /dev/ptp1 free running and in sync.
> But because PHC subsystem does not know that /dev/ptp0 and /dev/ptp1 is actually equivalent, it forbids to bind /dev/ptp2 to the socket of swpX.

It's not that the PHC subsystem doesn't know that /dev/ptp0 and
/dev/ptp1 are "actually equivalent". They _aren't_ actually equivalent.
They are completely independent clocks, independently adjustable.
Synchronized once and then left alone, I don't see what will prevent them from starting to drift. The sync process needs to be continuous, like for any other independent hardware clocks.

That, plus the fact that vclocks don't do what you think they do.
Even if there were 2 PTP clocks which could be proven to be equivalent, a vclock only has a single PTP clock as parent, not 2.

> If I understand your suggested options correctly, the ptp4l instance which handles the external front-facing interfaces, will just adjust one physical PHC, while the other PHC is re-adjusted by either internal ptp4l instance or ts2phc, but of course within some latency. Is this correct?

Yes.

> Back to our original problem:
> We want to use ptp4l between all front-facing ports, while physical PHCs of eno0-eno3 and swp0-swp5 are already in sync - known by us, but not known by PHC subsystem.
> For this, you have mentioned boundary_clock_jbod can be used.
> I do not know what boundary_clock_jbod is doing in detail and if and how this could be used to provide a solution in this use case.
> Could you please explain.

man ptp4l

       boundary_clock_jbod
              When running as a boundary clock (that is, when more than
              one network interface is configured), ptp4l performs a
              sanity check to make sure that all of the ports share the
              same  hardware clock  device. This option allows ptp4l to
              work as a boundary clock using "just a bunch of devices"
              that are not synchronized to each other. For this mode,
              the collection of clocks must be synchronized by an
              external program, for example phc2sys(8) in "automatic"
              mode.  The default is 0 (disabled).

"physical PHCs of eno0-eno3 and swp0-swp5 are already in sync - known by us, but not known by PHC subsystem" -> TL;DR: this option tells ptp4l "trust me, the clocks are in sync, within an unknown tolerance, despite being different, you can make a boundary clock out of these ports".
They'd better be in robust sync, though, because ptp4l can make an attempt to adjust any of those PHCs.