How to obtain accurate UTC0 frame timestamps

Hello,

I need to get accurate UTC0 (not uptime) timestamps for each captured frame.

I see that the timestamps of the frames are set in drivers/media/platform/tegra/camera/vi/vi5_fops.c,
with the line

        vb->vb2_buf.timestamp = descr->status.sof_timestamp;

but I wonder from which clock ‘sof_timestamp’ is obtained. Currently it seems that that clock starts at 0 at each reboot. Is it possible to make that clock synchronous to UTC0 when the jetson itself is synchronised using ntp or ptp ?

Please reference to below topic for the detail.

Thanks

Hello Shane,

What I need is to get v4l2 timestamps in CLOCK_REALTIME domain. How can I convert sof_timestamp to CLOCK_REALTIME domain, or even better, let the source of sof_timestamp be a CLOCK_REALTIME clock ? And I am not using argus, but directly v4l2.

Please go through below.

Sorry Shane, all those post refer to old jetpacks or other CPUs.

Here on the Orin NX, with jetpack-5.1.2, let me rephrase my question :

  • the value ‘sof_timestamp’ is set by something for which we do not have the sources, isn’t it ?
  • the value ‘sof_timestamp’ is copied at the start of each frame from a clock running somewhere, isn’t it ?
  • is this base clock a clock managed by linux or a clock running in a parallel CPU ?
  • if this clock runs in a parallel CPU, how is its ticking kept synchronous to the ‘monotonic’ and ‘realtime’ clocks from linux, which differ only by an offset, I think. ?
  • if this clock runs in a parallel CPU, how is it possible (like it is on the TX2 with jetpack-4.6.4) to transform it from ‘monotonic’ clock to ‘realtime’ clock ?

Thanks for your help

The sof_timestamp is the RCE(RTCPU co-processor) time receive SOF from the sensor. It’s monotonic_raw time of RTCPU and have offset tell in the sysfs. If you check the reference topic should able know that.

There’s no accuracy way to transform to realtime.

Thanks

Hello Shane,

Jetpack-5.x.y are based on linux-5.10 kernel.

The documentation for linux-5.10 at 3.6. Buffers — The Linux Kernel documentation states :

For capture streams this is time when the first data byte was captured,
as returned by the `clock_gettime()` function for the relevant clock id;
see `V4L2_BUF_FLAG_TIMESTAMP_*` in [Buffer Flags]
(https://www.kernel.org/doc/html/v5.10/userspace-api/media/v4l/buffer.html#buffer-flags).

And the ‘Buffer Flags’ page cited above lists only two possible V4L2_BUF_FLAG_TIMESTAMP_* values :

V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 	0x00000000 	

Unknown timestamp type. This type is used by drivers before Linux 3.9 and may be either
monotonic (see below) or realtime (wall clock). Monotonic clock has been favoured in
embedded systems whereas most of the drivers use the realtime clock. Either kinds of
timestamps are available in user space via clock_gettime() using clock IDs CLOCK_MONOTONIC
and CLOCK_REALTIME, respectively.

V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 	0x00002000 	

The buffer timestamp has been taken from the CLOCK_MONOTONIC
clock. To access the same clock outside V4L2, use clock_gettime().

So the compliant clocks allowed for the timestamp of v4l2 capture buffers are CLOCK_MONOTONIC and CLOCK_REALTIME. Providing CLOCK_MONOTONIC_RAW is not compliant. With Jetpack-4.x.y on TX2 we got timestamps based on CLOCK_MONOTONIC. Providing CLOCK_MONOTONIC_RAW instead with jetpack-5.x.y is a regression.

Could you provide a patch for jetpack-5.1.x on Orin NX to discipline the rtcpu clock to follow either CLOCK_MONOTONIC or CLOCK_REALTIME ?

Actually, replicating tegra_ivc_vi_notify_get_capture_status’s way of adjusting ‘sof_ts’ into drivers/media/platform/tegra/camera/fusa-capture/capture-vi.c is probably enough.

Thanks