Libargus order of initialization of camera devices

Hello,

I have a general question / understanding issue with the libargus framework. I see, there is the “getCameraDevices” method to get a list of all devices available in the camera provider. Is there any order to that?
Matter is: when restarting my application, I see a different initialization order of my devices (master/slave - sometimes slave/master; the latter causes problems). Is there a way to set the initialization order from a argus client perspective and is there a way to identify the camera devices (they have a badge in the device tree, is this accessible somewhere?)
Maybe I am completely wrong here and this is all Kernel internals which device is initialized first, but then, all the drivers I saw are "power_up"ing and "set_mode"ing on a per-device basis and I have a hard time to figure out, whether or not the master is already up and running.

Aug 25 15:16:51 xavierNX kernel: imx477 10-001a: video1: set imx477 as slave device
Aug 25 15:16:51 xavierNX kernel: imx477 9-001a: video0: set imx477 as master device

leads to the following errors (for all frames of one of the streams, the slave I recon)

NvCaptureStatusErrorDecode Stream 2.0 failed: sof_ts 881112696576 eof_ts 28195623405568 frame 108 error 14 data 0x00020000
NvCaptureStatusErrorDecode Capture-Error: FALCON_ERROR (0x0000000e)
SCF: Error InvalidState: Capture error with status 14 (channel 0) (in src/services/capture/NvCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 880)

If the cams are (by chance) initialized master-first, no errors pop up.

Mhm, I patched the Kernel module a little such that “whatever device comes first” becomes the master and this seems to fix the issue. BUT: the question remains if it would be possible to tell argus “start the capture session for video0 first and then for video1 afterwards” - now it seems very random to me.

Hi @zschutschke,

What carrier board you are using. I am using LI-XNX-6CAM with IMX577 (most likely same as your IMX477). Do you successfully capture camera images?

I am trying to make it works but have no luck till now and was stuck in getting data from camera sensor.

The video node depend on the i2c bus number.
And the argus sensor-id depend on the moduleX of the tegra-camera-platform

Hi Shane,

Thank you, so this is alwas cameraDevice[0] = video0 if my device tree is correct. Now why is the initialization order “random” then? I have a single capture session with the two devices attached. Could this be the issue? Like Argus is telling the kernel to fire up device 0 and 1 and the kernel does it in a different order?

Best,

Axel

I am not sure what you mean the initialization order “random”,
What I mean is the rule of sensor-id and video number of node.

Lets do some pseudo code here

devices = ICameraProvider.getCameraDevices()
session = ICameraProvider.createCaptureSession()
... create the session device / egl output streams and attach devices 0, 1
request = session.createRequest()
settings = interface_cast<ISourceSettings>(request)
settings->setSensorMode(xy) (one of device 0)
...
session->repeat(request)

leads to a (from my observation) “random” behavior for the device bring up and initialization:
either:

Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: imx477_power_on:
Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: imx477_set_mode:
Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: video0: set imx477 as master device
Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: imx477_set_gain: Setting gain control to: 16
Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:32:59 xavierNX kernel: imx477 9-001a: imx477_start_streaming:
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: imx477_power_on:
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: imx477_set_mode:
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: video1: try to set imx477 as slave device
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: imx477_set_gain: Setting gain control to: 16
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:32:59 xavierNX kernel: imx477 10-001a: imx477_start_streaming:

or

Aug 27 09:29:12 xavierNX kernel: imx477 10-001a: imx477_power_on:
Aug 27 09:29:12 xavierNX kernel: imx477 10-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:29:13 xavierNX kernel: imx477 10-001a: imx477_set_mode:
Aug 27 09:29:13 xavierNX kernel: imx477 10-001a: video1: set imx477 as master device
Aug 27 09:29:13 xavierNX kernel: imx477 10-001a: imx477_set_gain: Setting gain control to: 16
Aug 27 09:29:13 xavierNX kernel: imx477 10-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:29:13 xavierNX kernel: imx477 10-001a: imx477_start_streaming:
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_power_on:
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_set_mode:
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: video0: try to set imx477 as slave device
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_set_gain: Setting gain control to: 16
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_set_frame_rate: Setting framerate control to: 20000000
Aug 27 09:29:13 xavierNX kernel: imx477 9-001a: imx477_start_streaming:

You see my “hack” in place for the latter, which sets device 10 as master. This seems to solve my issue for the moment. But still I would like to understand the system to that point why this is happening. So why sometimes device 9 and sometimes device 10 comes first. Seemingly it has nothing to do with the device tree nor the kernel modules. Is it just Argus doing a asynchronous initilization of all devices?

Hi @ShaneCCC,

may I bring up this topic again? Any thoughts on the observation? The post is still up-to-date. The workaround is doing its job reliably but I still don’t understand why it is necessary.

Any sample APP can reproduce the issue?

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Hi zschutschke,

Please help to provide the sample APP, so we can reproduce the issue. Thanks