On 1/23/2023 10:44 AM, Rahul Rameshbabu wrote:

Thanks for the followup. Have a couple more questions.

On Sun, 22 Jan, 2023 18:58:48 -0800 Richard Cochran [off-list ref] wrote:

quoted

On Sun, Jan 22, 2023 at 06:48:49PM -0800, Rahul Rameshbabu wrote:

quoted

Another question then is can adjtime/ADJ_SETOFFSET make use of this
servo implementation on the device or is there a strict expectation that
adjtime/ADJ_SETOFFSET is purely a function that adds the offset to the
current current time?

ADJ_SETOFFSET == clock_settime.  Drivers should set the time
immediately.

quoted

If adjphase is implemented by a driver, should
ADJ_SETOFFSET try to make use of it in the ptp stack if the offset
provided is supported by the adjphase implementation?

No.


BTW, as mentioned in the thread, the KernelDoc is really, really bad:

 * @adjphase:  Adjusts the phase offset of the hardware clock.
 *             parameter delta: Desired change in nanoseconds.

The change log is much better:

    ptp: Add adjphase function to support phase offset control.

    Adds adjust phase function to take advantage of a PHC
    clock's hardware filtering capability that uses phase offset
    control word instead of frequency offset control word.

So the Kernel Doc should say something like:

 * @adjphase:  Feeds the given phase offset into the hardware clock's servo.
 *             parameter delta: Measured phase offset in nanoseconds.

Questions based on the proposed doc change.

1. Can the PHC servo change the frequency and not be expected to reset
   it back to the frequency before the phase control word is issued? If
   it's an expectation for the phase control word to reset the frequency
   back, I think that needs to be updated in the comments as a
   requirement.

My understanding from what Richard said is that .adjphase basically
offloads the entire servo and corrections to the hardware, and thus
would become responsible for maintaining the phase correction long term,
and callers would not use both .adjphase at the same time as .adjtime or
.adjfine

2. Is it expected that a PHC servo implementation has a fixed
   configuration? In userspace servo implementations, configuration
   parameters are supported. Would we need devlink parameters to support
   configuring a PHC servo?

I would assume some sort of parameter configuration, either via devlink
or something in the ptp_clock ecosystem if we get a device that has such
configuration?

quoted

Thanks,
Richard