reboot CSI channel without rerun gst-launch-1.0

Hi everyone,

Currently, We use CIS channel A receive sensor data. Our sensor suppot two work mode YUV422 or 8bit monochrome data.
Both of these have same resulotion 1280 *1024,and pixel frequency. We can switch one of the mode by uart command.
Now,I can use " gst-launch-1.0" tools capture this seneor and display. But,when the " gst-launch-1.0" tools is running and I use uart command switch sensor work on another mode.The display was froze and “dmesg” show “video4linux video0: frame start syncpt timeout!0 " But when I terminate " gst-launch-1.0” application and restart it,capture and display will return to normal.

We scope the sensor signal.There is no output in one microsecond,when sensor output mode be changed.And this will make TX1 MIPI receiver mismatch with sensor.But if I restart “gst-launch-1.0” tools,capture and display is well.

Is there a way,when I change my sensor output mode without restart "“gst-launch-1.0”?
Or,could I restart and reconfigure MIPI CSI channel without restart capture and display application?

The problem is cause you switch sensor mode by your tools and not tell the CSI/VI driver to change the mode.
You should implement different sensor mode and report the v4l2 framework and switch mode by the v4l2 app to change all the pipeline setting.

HI Shaneccc,

I use the same configuration to capture different sensor mode successfully. So, I think I don’t need different driver mode. When sensor mode has been changed,sensor signal has been cut off for a little while about 1us,then camera signal would keep normal. I think this why TX1 CSI channel report " start syncpt timeout!0" error.

And,in fact,sensor mode switch command cann’t report to TX1,because hardware doesn’t support this.

The sync point because sensor stop stream a while when switch the sensor mode. At least you need to stop stream when switch the sensor mode. You should develop your gstreamer APP for your use case. Otherwise the default gst-launch can’t do what you want.

Thanks for you reponse.

That’s right. I don’t want to restart app.Could I restart and reconfigure MIPI CSI channel ?

How to restart and reconfigure MIPI CSI channel?

An idea is implement a litter different sensor mode maybe just resolution have a litter different. Otherwise you totally need stop stream => switch mode => start stream again.

ok, thanks for you response.
is there a way,V4L2 capture application could detect bottom CSI status or error when sensor mode is changed?

Currently, when sensor mode was changed,vi driver report " video4linux video0: frame start syncpt timeout!0" error message.

There’s no this kind of implement for V4L2 framework. Your case is a special unit case that can’t support by the V4L2 framework.

Hi,Shane,
We had a review of the VI source code, and noticed that the driver was trying to recover from the err, by calling the following piece of code :

static void tegra_channel_ec_recover(struct tegra_channel *chan)
{
int index, valid_ports = chan->valid_ports;

    /* Disable pad power to start recovery */
    tegra_csi_pad_control(chan->vi->csi, chan->port, DISABLE);

    chan->fops->soc_channel_ec_recover(chan);

    /* Re-init VI and CSI */
    tegra_channel_capture_setup(chan);
    for (index = 0; index < valid_ports; index++) {
            tegra_csi_stop_streaming(chan->vi->csi,
                                            chan->port[index]);
            dev_err(chan->vi->dev,"stop\n");
            tegra_csi_start_streaming(chan->vi->csi,
                                            chan->port[index]);

            dev_err(chan->vi->dev,"start\n");
            nvhost_syncpt_set_min_eq_max_ext(chan->vi->ndev,
                                            chan->syncpt[index]);
            dev_err(chan->vi->dev,"syncpt\n");
    }

}

Within this code, there is a tegra_csi_stop_streaming() and tegra_csi_start_streaming().
This looks like the driver is trying to restart the MIPI device when it has error.
So based on our understanding, the driver should be able to work again after calling stop and start functions.
But we don’t understand why the channel didn’t get recovered. Could you help?
Please see the error message captured


code.png
error.png

The vi driver try to recover but if the the sensor output still have bad signal then it won’t get recover.