Carrior board with 2 HDMI Cameras with 6911 HDMI to mipi bridge get half green screen when stressful test

[stephen.xi]

Jetson NX 8G with custom carrier board with 6911(HDMI to MIPI birdge) on board
L4T 32.6.1

Testing has 4 GStreamer based windows show 4 streams each have a gst-pipeline

2 HDMI cameras +2 IPC cameras (with 2 IPC or not doesn’t make any difference)

Create /destroy HDMI cams preview pipeline 200 times, in about 175 times, totally about 1/175 fail rate, screen will freeze and show this picture,half green half picture (some time full green)

this is kernel message when issue happen
[18200.966114] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 38, err_data 160
Feb 8 14:05:53 linux kernel: [18200.966114] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 38, err_data 160
[18200.999541] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
Feb 8 14:05:53 linux kernel: [18200.999541] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
[18201.032856] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
Feb 8 14:05:53 linux kernel: [18201.032856] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
[18201.066126] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
Feb 8 14:05:53 linux kernel: [18201.066126] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
[18201.099455] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
Feb 8 14:05:53 linux kernel: [18201.099455] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
[18201.132865] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160
Feb 8 14:05:53 linux kernel: [18201.132865] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 32, err_data 160

[kayccc]

Is it on custom carrier board or devkit?
Which JetPacK version?
How to reproduct this test? failure rate?

[stephen.xi]

updated in my post

[stephen.xi]

Jetpack 4.6 , 32.6.1
Cams input size is 1080P30, ,in this case, is 2 1080P30 HDMI to MIPI , which I don’t think have any bandwidth issue, we have testing 4k cams also working, it is on board we have 3 6911 HDMI to MIPI, each has config as 4 lanes MIPI
pipeline like this :
gst-launch-1.0 v4l2src device=/dev/video0 ! “video/x-raw,width=1920,height=1080,framerate=(fraction)30/1” ! xvimagesink

[ShaneCCC]

For this case you may need to confirm the MIPI signal match the MIPI spec like the power sequence …
Also you can try different mode like MIPI continuous/discontinuous mode and adjust the setting time.

[stephen.xi]

For this case you may need to confirm the MIPI signal match the MIPI spec like the power sequence …

I think this is kind of like HW signal level verification HWV need scope to measure it which is kind of very hard to do it right now
Also you can try different mode like MIPI continuous/discontinuous mode and adjust the setting time.

I am not aware how to setting it , How to config it ?thanks

[ShaneCCC]

Please consult with vendor to configure it. And modify the discontinuous_clk/cil_settletime in device tree to match the device mode.

[stephen.xi]

DTS have this setting, already testing it , set discontinuous_clk/cil_settletime in device tree no improvement

[ShaneCCC]

Did you also configure the output source from bridge REG too?

[stephen.xi]

we have some new founding
Testing 1：
Environment:
lt6911uxc dts use attachment tegra194-camera-rbpcv2-lt6911_old1.dtsi
using lt6911uxc firmware which is for 1080PEDID FW
testing 1080P30 without any eroror with 3 round each 500 times
Testing 2
Environment
lt6911uxc dts use attachment tegra194-camera-rbpcv2-lt6911_new1.dtsi
using lt6911uxc firmware which is for 1080PEDID fw
with fail rate with below pciture error in kernel message

tegra194-camera-rbpcv2-lt6911_new1(1).dtsi (16.6 KB)
tegra194-camera-rbpcv2-lt6911_old1.dtsi (16.7 KB)

[stephen.xi]

update lastest testing , we found issue is very random , on test 2 , still have failed rate , it dependence on various factor , for example , cams , machines and even the cable length ,
we already asking 6911 vendor provides the continuous clock FW for next round test