About the AUTOLOAD bit for VI (video input unit)

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi,

Currently I have been working on a TX2-based system that is reported to have camera frame drop issue. This product has very tight requirements where the camera recording frame rate has to be very stable and never drop a single frame. The system employs an SSD through NVMe or USB, and to mitigate this problem the current workaround is to set the cgroup write speed limit on the SSD. In general this issue is correlated with high CPU load. When the system is under CPU intensive tasks it would drop frames. Interestingly enough, when the streaming pipeline writes to SSDs connected through USB 3.0 the issue does not seem to show or at least not as often.

Another possible (“sturdier”) approach that has been proposed to solve this frame drop issue is based on the AUTOLOAD bit for VI described in the TX2 TRM. On page 2785 one can read:

The AUTOLOAD bit behaves as described, but is generally not recommended for use. Since the autoload functionality has no
provision for error detection and handling, it is generally not the preferred mechanism with which to build a robust system. It may
be used in conditions requiring extremely low Vblank times, or when the real-time CPU is not available and interrupt latency to
the main CPU is high. In general, the real-time CPU should be responsible for reloading channels. When a channel is in frame
and enabled, LOAD commands are deferred until the frame completes; this can also be used as an alternative to autoload
mode.

Based on this description it seems this mode could work as a potencial solution since the current hypothesis is that the issue is in the frame capture loop that should setup a capture for the next frame (frame by frame basis process) and sometimes does not run in time. There have been some attempts to enable this bit by patching the VI driver (vi4_fops.c) but without success, the camera capture support gets broken when this bit is set.

We have seen the capture is being configured in the function: tegra_channel_capture_frame_single_thread, it then sets the SINGLESHOT bit at:

   519                  for (i = 0; i < chan->valid_ports; i++) {
   520                        vi4_channel_write(chan, chan->vnc_id[i],
   521                                          CHANNEL_COMMAND, LOAD);
   522                        vi4_channel_write(chan, chan->vnc_id[i],
   523                              CONTROL, SINGLESHOT | MATCH_STATE_EN);
   524                  }
       
   525                  /* wait for vi notifier events */
   526                  if (!vi_notify_wait(chan, buf, &ts)) {

We are not entirely sure if to enable this feature is as simple as replacing LOAD with AUTOLOAD and removing the SINGLESHOT bit or if the driver need some other refactoring.

Does anyone have any experience hacking the VI driver to enable this mode? Any insight is helpful. Thanks in advance for the support.

Jafet Chaves,
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

3

The critical latency loop in the VI system is the time from the sensor’s frame end to the time when the channel is reloaded and re-enabled. If this time exceeds the time between the frame end and frame start, then a frame is dropped. To avoid frame drops in applications with indeterminate latencies, VI provides an AUTOLOAD feature to automatically reload and re-enable a channel when a frame completion reaches the end of the pipeline. If the frame-end latency cannot be guaranteed because the system is using a more distant CPU, an application should use AUTOLOAD. This gives additional complication for error handling, however: AUTOLOAD reloads, even in the event of an errored frame, which may be different from the expectations of the rest of the system

4

Thanks for the insight, ShaneCCC. Do you know of any use case that enabled this capability? Has this been attempted in the past by anyone? Is there any other documentation besides the TRM where I can dig this feature further?

5

Didn’t hear any customize applied this case.

Thanks

6

That’s unfornatute to hear, ShaneCCC. Do you know of any other documentation (aside the TRM) where I can dig more information about this?

7

@jchaves
Sorry to tell there’s no any document for that.
But I think you can try it

Thanks

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.