nvidia tx2 camera capture timeout

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi,

I’m currently developing a camera driver on TX2. Before doing this job, I’ve successfully developed this driver for the Jetson TX1 development kit, so I thought it would be a straightforward job.

However, I was stuck at some errors. When I use yavta tools to test stability，but occasionally, some
problems occured as follows:

[   42.192947] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[   43.196973] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout!

By reading TX1‘s VI driver, I found that there is a error recovery mechanism as follows:

/* Arm capture and wait for notifier or syncpoint */
err = chan->fops->soc_channel_capture_frame(chan, &ts, thresh);
if (err) {
        state = VB2_BUF_STATE_ERROR;
        /* perform error recovery for timeout */
        tegra_channel_ec_recover(chan);
} else if (!chan->vi->pg_mode) {

But this disappear on TX2.

for (i = 0; i < chan->valid_ports; i++) {
                err = nvhost_syncpt_wait_timeout_ext(chan->vi->ndev,
                                chan->syncpt[i][SOF_SYNCPT_IDX], thresh[i],
                                250, NULL, NULL);
                if (unlikely(err))
                        dev_err(chan->vi->dev,
                                "PXL_SOF syncpt timeout! err = %d\n", err);
                else {
                        struct vi_capture_status status;

                        err = vi_notify_get_capture_status(chan->vnc[i],
                                        chan->vnc_id[i],
                                        thresh[i], &status);
                        if (unlikely(err))
                                dev_err(chan->vi->dev,
                                        "no capture status! err = %d\n", err);
                        else
                                *ts = ns_to_timespec((s64)status.sof_ts);
                }
        }

So It runs well on TX1, but unstable on TX2.

thanks.

2

＠cloundliu
Please make sure the MIPI output is match the spec and find tun the settle time by modify the T18X_BYPASS_LP_SEQ as 0 << 7 and DEFAULT_THS_SETTLE from 0x1 - 0x7f find the detail information from the TRM.

#define T18X_BYPASS_LP_SEQ (0x1 << 7)
#define DEFAULT_THS_SETTLE (0x14 << 0)

…/./camera/csi/csi4_registers.h

3

Hi ShaneCCC,

I have checked the MIPI output, it is match the spec.
I have modified the settle time, and the situation remains. Sometimes it will run 2 hours more, sometimes it just a few minutes. But when I restart the capture test, It will run a period of time.
So maybe we should add a error recovery mechanism like TX1, I will do this.

thanks.

4

@cloundliu
We are going to implement it.

5

@ShaneCCC
When will the patch be ready?

6

@ShaneCCC

Have you add a error recovery mechanism for TX2?

thanks

7

Yes, next release will have it.

8

@ShaneCCC

How long does it take？

Another question:

void tegra_channel_ring_buffer(struct tegra_channel *chan,
                               struct vb2_v4l2_buffer *vb,
                               struct timespec *ts, int state)
{
...
         /* release buffer N at N+2 frame start event */
         if (chan->num_buffers >= (QUEUED_BUFFERS - 1))
                 free_ring_buffers(chan, 1);

I know you had the buffer release mechanism to avoid multiple race conditions as shown above, it is expected that queue 2 frames in the ring buffer， but it will increase the capture-to-display time delay, approximately 1 frame(for 30fps camera is 33.3ms), So could you have some patch to improve this on TX2(R28.1/R28.2)?

thanks.

9

28.2 already have improve please check 28.2

10

@ShaneCCC:

Is there any patch for the error recovery mechanism for TX2?

11

@zhaozoz
Should be release in next version.