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