From: Ivan Vecera <ivecera@redhat.com>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>, netdev@vger.kernel.org
Cc: Chris du Quesnay <Chris.duQuesnay@microchip.com>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Michal Schmidt <mschmidt@redhat.com>,
Paolo Abeni <pabeni@redhat.com>,
Pasi Vaananen <pvaanane@redhat.com>, Petr Oros <poros@redhat.com>,
Prathosh Satish <Prathosh.Satish@microchip.com>,
Richard Cochran <richardcochran@gmail.com>,
Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/4] dpll: zl3073x: add channel ToD and phase step operations
Date: Fri, 10 Jul 2026 17:02:04 +0200 [thread overview]
Message-ID: <f5cab4c5-e2dd-46ca-b788-af0c7c4f77b3@redhat.com> (raw)
In-Reply-To: <c66e433b-654d-4c14-ad73-e3a93314d8d8@linux.dev>
On 7/10/26 2:56 PM, Vadim Fedorenko wrote:
> On 08/07/2026 18:05, Ivan Vecera wrote:
>> Add low-level DPLL channel operations for ToD read/write/adjust,
>> delta frequency offset write and output phase step. ToD operations
>> use a wait-before-write pattern to avoid blocking after each
>> operation. tod_adjust additionally waits for completion since callers
>> may follow with phase step operations.
>>
>> The tod_ready_wait helper selects the poll timeout based on the
>> current ToD command - write operations use a longer timeout (1000 ms)
>> than reads (30 ms).
>>
>> The ToD read captures system timestamps (ptp_system_timestamp) around
>> the HW command and completion poll to support cross-timestamping.
>>
>> Add output step-time mask invariant to zl3073x_chan and
>> zl3073x_chan_is_out_stepped() helper to check if an output
>> participates in step-time operations.
>>
>
> [...]
>
>> +/**
>> + * zl3073x_chan_tod_read - read ToD registers after issuing a command
>> + * @zldev: pointer to zl3073x device
>> + * @ch: DPLL channel index
>> + * @next_hz: if true, read predicted ToD at next 1 Hz; otherwise read
>> current
>> + * @ts: timespec to store the result
>> + * @sts: optional system timestamp pair for cross-timestamping
>> + *
>> + * Context: Caller must serialize all zl3073x_chan_tod_* calls
>> externally.
>> + * Return: 0 on success, <0 on error
>> + */
>> +int zl3073x_chan_tod_read(struct zl3073x_dev *zldev, u8 ch,
>> + bool next_hz, struct timespec64 *ts,
>> + struct ptp_system_timestamp *sts)
>> +{
>> + u32 nsec;
>> + u64 sec;
>> + u8 cmd;
>> + int rc;
>> +
>> + if (next_hz)
>> + cmd = ZL_DPLL_TOD_CTRL_CMD_RD_NEXT_1HZ;
>> + else
>> + cmd = ZL_DPLL_TOD_CTRL_CMD_RD_CURRENT;
>> +
>> + /* Wait for any previous ToD operation to complete */
>> + rc = zl3073x_chan_tod_ready_wait(zldev, ch);
>> + if (rc)
>> + return rc;
>> +
>> + ptp_read_system_prets(sts);
>> + rc = zl3073x_chan_tod_ctrl(zldev, ch, cmd);
>> + if (rc)
>> + return rc;
>> +
>> + rc = zl3073x_chan_tod_ready_wait(zldev, ch);
>> + if (rc)
>> + return rc;
>> + ptp_read_system_postts(sts);
>
> AFAIU, this code means that the ToD value was somewhere between tod_ctrl
> command and tod_ready read value 0 of the register. How does it work
> with "predicted ToD at next 1 Hz"?
The ptp_system_timestamp is only used by the gettimex64 callback which
always calls tod_read with next_hz=false (current ToD). The next_hz=true
path is only used internally by tod_adjust() which passes sts=NULL.
So in practice, system timestamps are never captured around a predicted
ToD read. The function accepts both options through the same interface
for simplicity, but the sts parameter is only meaningful with
next_hz=false.
Thanks,
Ivan
next prev parent reply other threads:[~2026-07-10 15:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 17:05 [PATCH net-next 0/4] dpll: zl3073x: add PTP clock support Ivan Vecera
2026-07-08 17:05 ` [PATCH net-next 1/4] dpll: zl3073x: add channel ToD and phase step operations Ivan Vecera
2026-07-10 12:56 ` Vadim Fedorenko
2026-07-10 15:02 ` Ivan Vecera [this message]
2026-07-08 17:05 ` [PATCH net-next 2/4] dpll: zl3073x: add PTP clock support Ivan Vecera
2026-07-10 13:08 ` Vadim Fedorenko
2026-07-10 15:19 ` Ivan Vecera
2026-07-08 17:05 ` [PATCH net-next 3/4] dpll: zl3073x: add channel TIE write operation Ivan Vecera
2026-07-08 17:05 ` [PATCH net-next 4/4] dpll: zl3073x: add PTP clock adjphase and TIE support Ivan Vecera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5cab4c5-e2dd-46ca-b788-af0c7c4f77b3@redhat.com \
--to=ivecera@redhat.com \
--cc=Chris.duQuesnay@microchip.com \
--cc=Prathosh.Satish@microchip.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
--cc=pvaanane@redhat.com \
--cc=richardcochran@gmail.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox