On Fri, 20 Jan, 2023 09:21:09 -0800 Jacob Keller [off-list ref] wrote:

On 1/19/2023 8:26 PM, Rahul Rameshbabu wrote:

quoted

On Thu, 19 Jan, 2023 20:03:43 -0800 Jakub Kicinski [off-list ref] wrote:

quoted

The other question is about the exact semantics of ->adjphase
- do all timecounter based clock implementations support it
by definition?

My understanding is no (though anyone is free to jump in to correct me
on this). Only implementations with support for precisely handling small
PPS corrections can support adjphase (being able to adjust small offsets
without causing same or worse drift).

I guess I'm missing something here? timecounters allow adjusting time in
an atomic way. They don't lose any time when making an adjustment
because its a change to the wrapping around a fixed cycle counter.

If that's the case, wouldn't adjphase be implementable by every PTP
hardware clock device. I agree with the description here but not all
devices provide this atomic (phase offset control) functionality from my
understanding. More details in next section.

How does that not comply with adjphase? and if it doesn't, then whats
the difference between adjphase and just correcting offset using adjfine
for frequency adjustment?

  Some PTP hardware clocks have a write phase mode that has a built-in
  hardware filtering capability. The write phase mode utilizes a phase
  offset control word instead of a frequency offset control word.

The above is from the original patch description for adjphase. My
understanding is that some PTP hardware clocks do not implement the
phase control word. Hence why I responded with no in my original post as
in no, not all PTP hardware devices are expected to support this
capability.

I guess adjusting phase will do the small corrections in hardware
(perhaps by temporarily adjusting the nominal frequency of the clock)
but will then return to the normal frequency once complete?

So adjphase is more than just being atomic...?

I assumed the phase control word is more than just a simple one-shot
(atomic) time offset done in the hardware (at least internally what the
hardware does when implementing this control word).

  adjtime modifies HW counter with a value to move the 1 PPS abruptly to new location.
  adjphase modifies the frequency to quickly nudge the 1 PPS to new location and also includes a HW filter to smooth out the adjustments and fine tune frequency.

  Continuous small offset adjustments using adjtime, likley see sudden shifts of the 1 PPS.  The 1 PPS probably disappears and re-appears.
  Continuous small offset adjustments using adjphase, should see continuous 1 PPS.

https://lore.kernel.org/lkml/20220804132902.GA25315@renesas.com/ (local)

Looking at the mlx5 driver implementation, it does look like a simple
atomic operation. That said, I wouldn't consider myself a ptp architect
and am mostly going off based on what I read from the patch series that
introduced the capability in the ptp core stack in the kernel. I do
think this needs to get updated in ptp_clock_kernel.h.