On 7/10/26 2:56 PM, Vadim Fedorenko wrote:

On 08/07/2026 18:05, Ivan Vecera wrote:

quoted

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.

[...]

quoted

+/**
+ * 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