Other Parts Discussed in Thread: TFP410, SN65DSI86, AM68, AM68A, TDA4VM
Tool/software:
I'm running Linux SDK 09.02.00.05 (www.ti.com/.../09.02.00.05) and I've developed a driver for an ar0823 camera sensor. I have cameras connected on my SK-AM68 dev kit on J16 and J17. Things work as expected about 70% of the time. I've noticed that the camera on J17 sometimes runs into a capture problem when using v4l2-ctl after a power-cycle or reboot.
I've got my driver blacklisted in `/etc/modprobe.d/blacklist.conf` so that I can manually bring things up via `modprobe`. The driver and two camera instances are defined in my device tree. To bring things up, I do the following:
modprobe ar0823
# configure /dev/media0 for the J16 instance
media-ctl -d /dev/media0 --set-v4l2 "'cdns_csi2rx.4504000.csi-bridge':0[fmt:SGRBG12_1X12/3840x2168 field:none colorspace:srgb]"
media-ctl -d /dev/media0 --set-v4l2 "'cdns_csi2rx.4504000.csi-bridge':1[fmt:SGRBG12_1X12/3840x2168 field:none colorspace:srgb]"
# configure /dev/media1 for the J17 instance
media-ctl -d /dev/media1 --set-v4l2 "'cdns_csi2rx.4514000.csi-bridge':0[fmt:SGRBG12_1X12/3840x2168 field:none colorspace:srgb]"
media-ctl -d /dev/media1 --set-v4l2 "'cdns_csi2rx.4514000.csi-bridge':1[fmt:SGRBG12_1X12/3840x2168 field:none colorspace:srgb]"
v4l2-ctl -d /dev/video2 --set-fmt-video=width=3840,height=2168,pixelformat=BA12 --stream-mmap --stream-count=1 --stream-to=/dev/null # capture a single frame from the J16 camera as a sanity check
v4l2-ctl -d /dev/video10 --set-fmt-video=width=3840,height=2168,pixelformat=BA12 --stream-mmap --stream-count=1 --stream-to=/dev/null # capture a single frame from the J17 camera as a sanity check
The J16 instance works flawlessly. The J17 instance works about 70% of the time. When it fails, the `v4l2-ctl` command returns
VIDIOC_STREAMON returned -1 (Invalid argument)
Further, `dmesg` reports this when the above error occurs:
[ 32.731201] ------------[ cut here ]------------
[ 32.735824] WARNING: CPU: 0 PID: 1295 at drivers/media/common/videobuf2/videobuf2-core.c:1627 vb2_start_streaming+0xe0/0x15c [videobuf2_common]
[ 32.748687] Modules linked in: ar0823 xhci_plat_hcd pci_endpoint_test rpmsg_ctrl panel_edp rpmsg_char cdns_csi2rx v4l2_fwnode omap_rng cdns3 cdns_usb_common overlay crct10dif_ce ti_tfp410 display_connector phy_can_transceiver cfg80211 bluetooth ecdh_generic ecc rfkill ti_sn65dsi86 drm_display_helper ti_k3_r5_remoteproc drm_dp_aux_bus k3_j72xx_bandgap at24 wave5 v4l2_mem2mem j721e_csi2rx videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 tidss v4l2_async videobuf2_common cdns_dsi drm_dma_helper ti_k3_dsp_remoteproc virtio_rpmsg_bus rpmsg_ns drm_kms_helper pvrsrvkm(O) ti_k3_common syscopyarea sysfillrect m_can_platform videodev sysimgblt fb_sys_fops sa2ul pci_j721e_host m_can cdns_dphy_rx pci_j721e mc pcie_cadence_host cdns_dphy can_dev pcie_cadence cdns3_ti pwm_tiehrpwm rti_wdt optee_rng rng_core cryptodev(O) fuse drm drm_panel_orientation_quirks ipv6
[ 32.824120] CPU: 0 PID: 1295 Comm: v4l2-ctl Tainted: G O 6.1.80-ti-g2e423244f8c0 #1
[ 32.833145] Hardware name: Texas Instruments AM68 SK (DT)
[ 32.838528] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 32.845472] pc : vb2_start_streaming+0xe0/0x15c [videobuf2_common]
[ 32.851644] lr : vb2_start_streaming+0x68/0x15c [videobuf2_common]
[ 32.857812] sp : ffff80000b08bb60
[ 32.861111] x29: ffff80000b08bb60 x28: ffff0008310a0a00 x27: ffff0008311c14b8
[ 32.868230] x26: 0000000000000000 x25: 0000000040045612 x24: 0000000000000000
[ 32.875348] x23: ffff80000b08bcc8 x22: ffff00082ea7a800 x21: ffff0008311c1438
[ 32.882466] x20: ffff0008311c1260 x19: 00000000ffffffea x18: 0000000000000000
[ 32.889584] x17: 0000000000000000 x16: 0000000000000000 x15: 0000fffffe2a73d0
[ 32.896701] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 32.903819] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 32.910936] x8 : 0000000000000000 x7 : 0000000000000005 x6 : 0000000000000012
[ 32.918054] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff00082cd089c0
[ 32.925171] x2 : 0000000000000000 x1 : ffff800001033000 x0 : 0000000000000004
[ 32.932289] Call trace:
[ 32.934724] vb2_start_streaming+0xe0/0x15c [videobuf2_common]
[ 32.940546] vb2_core_streamon+0x90/0x190 [videobuf2_common]
[ 32.946196] vb2_ioctl_streamon+0x5c/0xb0 [videobuf2_v4l2]
[ 32.951674] v4l_streamon+0x24/0x30 [videodev]
[ 32.956134] __video_do_ioctl+0x18c/0x3dc [videodev]
[ 32.961106] video_usercopy+0x21c/0x6d0 [videodev]
[ 32.965905] video_ioctl2+0x18/0x30 [videodev]
[ 32.970355] v4l2_ioctl+0x40/0x60 [videodev]
[ 32.974631] __arm64_sys_ioctl+0xa8/0xf0
[ 32.978553] invoke_syscall+0x48/0x114
[ 32.982293] el0_svc_common.constprop.0+0xd4/0xfc
[ 32.986984] do_el0_svc+0x20/0x30
[ 32.990288] el0_svc+0x28/0xa0
[ 32.993334] el0t_64_sync_handler+0xbc/0x140
[ 32.997592] el0t_64_sync+0x18c/0x190
[ 33.001242] ---[ end trace 0000000000000000 ]---
It takes a reboot, or sometimes multiple reboots, to correct this. If J17 works after a reboot, then it continues to perform flawlessly. It just seems the reboot or power-cycle occasionally puts things in a bad state.
At one point, I had two IMX219 cameras configured on J16 and J17 and recall similar behavior. I'm going to set that configuration back up and confirm it was the case.
Any ideas what might be causing this?