On Fri, May 15, 2020 at 03:26:47PM +0200, Julien Beraud wrote: > The frequency adjustments of the mac's clock are done by changing the value of > addend, so that the number of clock cycles that make the accumulator overflow > slightly change.
This is typical. > The value of sub-second-increment is set to 2 / ptp_clk_freq, because using an > accumulator with the same number of bits as the addend register makes it > impossible to overflow at every addition. > > This mode allows to implement a PTP Slave, constantly adjusting the clock's > freq > to match the master. Right. And I would stick with this. With the ts2phc program (linuxptp master branch) you can use the EXTTS to discipline the clock to match the external time source. > -> In coarse mode, the accumulator and the addend register are not used and > the > value of sub-second-increment is added to the clock at every ptp_ref_clock > cycle. That sounds like simply configuring a fixed rate. > This mode allows to implement a Grand Master where we can feed the stmmac's > ptp > ref clock input with a frequency that's controlled externally, making it > useless to do frequency adjustments with the MAC. > > We want our devices to be able to switch from Master to Slave at runtime. If I understand correctly, what you are really asking for is the ability to switch clock sources. This normally done through the device tree, and changing the device tree at run time is done with overlays (which I think is still a WIP). > So the question is what interface could we use to configure a timestamping > clock that has more than one functioning mode and which mode can be changed at > runtime, but not while timestamping is running ? I think this must be decided at boot time using the DTS. In any case, the PHC time stamping API is not the right place for this. If you end up making a custom method (via debugfs for example), then your PHC should then return an error when user space attempts to adjust it. Thanks, Richard
