[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8336MEkd6R/XU7x@hoboy.vegasvil.org>
Date: Sun, 22 Jan 2023 18:58:48 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Rahul Rameshbabu <rrameshbabu@...dia.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>,
Saeed Mahameed <saeed@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
Tariq Toukan <tariqt@...dia.com>,
Gal Pressman <gal@...dia.com>,
Vincent Cheng <vincent.cheng.xh@...esas.com>
Subject: Re: [net-next 03/15] net/mlx5: Add adjphase function to support
hardware-only offset control
On Sun, Jan 22, 2023 at 06:48:49PM -0800, Rahul Rameshbabu wrote:
> 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.
> 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.
Thanks,
Richard
Powered by blists - more mailing lists