Hello,
I am very close to getting my camera driver working for the Sony IMX392. I have some issues that it doesn’t register to /dev/video0.
I do not see where the issue is in the logs provided below.
In the tegra186-quill-camera-modules.dts file I enabled all CSI channels and vi ports (as I’m not sure which ones I only need to enable for the first 8 CSI lanes as I have two sensors).
I added the two entries under i2c@3180000.
imx392_cam0: imx392_a@36 {
status = "okay";
};
imx392_cam1: imx392_c@37 {
status = "okay";
};
Full dmesg log: [ 0.000000] Booting Linux on physical CPU 0x100[ 0.000000] Linux version - Pastebin.com
I narrowed it down in the probe function. Everything is fine up until this point:
err = tegracam_v4l2subdev_register(tc_dev, true);
if (err) {
dev_err(dev, "tegra camera subdev registration failed\n");
return err;
};
dev_info(dev, "Detected IMX392 sensor\n");
It results in a stack error when running the function err = tegracam_ctrl_handler_init(ctrl_hdl); in tegracam_v4l2.c
[ 225.001617] imx392 2-0036: imx392_set_gain: val: 0 (/10) [times], gain: 0
[ 225.001925] imx392 2-0036: imx392_set_exposure: val: 0
[ 225.001930] imx392 2-0036: imx392_set_coarse_time: coarse1:0, shs1:1124, FL:1125
[ 225.002344] imx392 2-0036: imx392_set_frame_rate: val: 0
[ 225.002764] Internal error: Attempting to execute userspace memory: 86000005 [#1] PREEMPT SMP
[ 225.011277] Modules linked in: imx392(+) fuse bnep zram bcmdhd cfg80211 spidev overlay nvgpu bluedroid_pm ip_tables x_tables [last unloaded: imx392]
[ 225.024750] CPU: 5 PID: 8068 Comm: insmod Tainted: G W 4.9.140-tegra #2
[ 225.032491] Hardware name: quill (DT)
[ 225.036162] task: ffffffc191ecd400 task.stack: ffffffc197eb0000
[ 225.042087] PC is at 0x0
[ 225.044644] LR is at tegracam_s_ctrl+0x280/0x318
[ 225.049282] pc : [<0000000000000000>] lr : [<ffffff8008b52fa8>] pstate: 60400045
[ 225.056702] sp : ffffffc197eb3910
[ 225.060034] x29: ffffffc197eb3910 x28: 0000000000000018
[ 225.065403] x27: 000000000000008c x26: 0000000000000030
[ 225.070814] x25: ffffff8000f7b3c8 x24: ffffffc191a84018
[ 225.076178] x23: ffffffc192e0f018 x22: ffffff8000f7b3c8
[ 225.081562] x21: ffffffc1de0d9718 x20: ffffffc1865a2700
[ 225.086924] x19: 0000000000000001 x18: 0000000000000001
[ 225.092284] x17: 0000000000000002 x16: 0000000000000000
[ 225.097689] x15: ffffffffffffffff x14: ffffffc197eb38f0
[ 225.103102] x13: ffffffc197eb37f6 x12: 0000000000000400
[ 225.108511] x11: 0000000005f5e0ff x10: ffffffc197eb37b0
[ 225.113872] x9 : 0000000000000002 x8 : 0000000000000002
[ 225.119229] x7 : ffffff8008fc6e88 x6 : 0000000000000090
[ 225.124587] x5 : 000000000000008d x4 : 0000000000000001
[ 225.129974] x3 : 0000000000000000 x2 : 0000000000000000
[ 225.135387] x1 : 0000000000000000 x0 : ffffffc1de0d9718
[ 225.142332] Process insmod (pid: 8068, stack limit = 0xffffffc197eb0000)
[ 225.149069] Call trace:
[ 225.151555] [< (null)>] (null)
[ 225.156336] [<ffffff8008b21148>] v4l2_ctrl_handler_setup+0x108/0x158
[ 225.162731] [<ffffff8008b52b70>] tegracam_ctrl_handler_init+0x1d0/0x388
[ 225.169384] [<ffffff8008b53830>] tegracam_v4l2subdev_register+0xc0/0x2d8
[ 225.176147] [<ffffff8000f7a33c>] 0xffffff8000f7a33c
[ 225.181072] [<ffffff8008aea7bc>] i2c_device_probe+0x144/0x258
[ 225.186879] [<ffffff8008781b68>] driver_probe_device+0xd8/0x408
[ 225.192835] [<ffffff8008781f74>] __driver_attach+0xdc/0x128
[ 225.198453] [<ffffff800877f5e4>] bus_for_each_dev+0x5c/0xa8
[ 225.204064] [<ffffff8008781368>] driver_attach+0x30/0x40
[ 225.209413] [<ffffff8008780d9c>] bus_add_driver+0x20c/0x2a8
[ 225.215026] [<ffffff8008782eac>] driver_register+0x6c/0x110
[ 225.220639] [<ffffff8008aeaeac>] i2c_register_driver+0x4c/0xb0
[ 225.226525] [<ffffff8000f84018>] init_module+0x18/0x30 [imx392]
[ 225.232495] [<ffffff8008083b3c>] do_one_initcall+0x44/0x130
[ 225.238114] [<ffffff80081c20fc>] do_init_module+0x64/0x1a8
[ 225.243642] [<ffffff800815750c>] load_module+0x10a4/0x12d8
[ 225.249163] [<ffffff80081579f0>] SyS_finit_module+0xd8/0xf0
[ 225.254771] [<ffffff8008083900>] el0_svc_naked+0x34/0x38
[ 225.260145] ---[ end trace 8e73db956529a8e3 ]---
hello FPSUsername,
during sensor probing, it’ll power-on sensor and parse the sensor capability; these properties were report from the device tree. please refer to Sensor Software Driver Programming Guide to review your device tree properties.
you may also check below reference driver with dual IMX274 cameras.
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-modules/tegra186-camera-imx274-dual.dtsi
I do not understand how the port binding relates to the CSI ports on the Jetson. I’ll start with getting one camera working and then expand to two. I have my camera connected to CSI 2 and CSI 3 with 4 lanes.
If I look at the port index section, this means that I use CSI C and CSI D.
To begin with patching tegra186-quill-camera-modules.dtsi.
Looking at the port index schematic, it looks like I have to enable VI port 2 for 4 CSI lanes.
Does this also mean that I have to enable CSI channel 2?
When I look at the IMX274 dual driver, each sensor uses 4 CSI lanes, however, I see that each sensor only uses one CSI channel with two ports (as each port has two lanes).
This is what I currently have set in my tegra186-camera-imx392-a00.dtsi file. This however doesn’t correspond with what I wrote above.
vi@15700000 {
num-channels = <2>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@2 {
reg = <0>;
liimx392_vi_in2: endpoint {
port-index = <2>;
bus-width = <4>;
remote-endpoint = <&liimx392_csi_out2>;
};
};
};
};
nvcsi@150c0000 {
num-channels = <2>;
#address-cells = <1>;
#size-cells = <0>;
channel@2 {
reg = <2>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
liimx392_csi_in2: endpoint@4 {
port-index = <2>;
bus-width = <4>;
remote-endpoint = <&liimx392_imx392_out2>;
};
};
port@1 {
reg = <1>;
liimx392_csi_out2: endpoint@5 {
remote-endpoint = <&liimx392_vi_in2>;
};
};
};
};
};
And in the device part itself I have
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
liimx392_imx392_out2: endpoint {
port-index = <2>;
bus-width = <4>;
remote-endpoint = <&liimx392_csi_in2>;
};
};
};
Is this the correct translation to the DTSI?
hello FPSUsername,
that’s correct, you should enable CSI-C/D to connect your 4-lane sensor;
you may also refer to Port Index session to understand the connection between CSI and VI.
thanks
Hello Jerry,
Thanks for the clarification. Unfortunately, I am still not getting /dev/video0.
Do the CSI lines have to be active and fully working?
I’m asking this because I have a less “traditional” setup. The IMX392 does not have a function to create a test pattern and has a sub-LVDS output. I use a Lattice MachXO3 with the Sony Sub-LVDS to MIPI CSI-2 Sensor Bridge reference design.
hello FPSUsername,
you may also co-work with your hardware engineer to probe the sensor signaling,
normally, there will be MIPI signaling if you’d configure power regulators correctly; the next step will be looking into device tree to review properties settings.
thanks