On Fri, Dec 22, 2023 at 12:57 PM Fabio Estevam <festevam@xxxxxxxxx> wrote: > > On Fri, Dec 22, 2023 at 5:51 PM Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: > > > Fabio, > > > > Thanks for testing. Is this with arch/arm64/defconfig? > > I modified arch/arm64/defconfig to only build for NXP i.MX. > > The resultant defconfig is this one: > https://pastebin.com/raw/6dFx3tfp Fabio, Interesting... when I avoid using the dt overlay it works fine. There is something wrong with my overlay - the phandle from the sensor@10 node was missing. When comparing the output of 'dtc -I fs -O dts /sys/firmware/devicetree/base' between booting with my overlay vs booting with the contents of the overlay merged into the base file I the following diffs: $ diff /tmp/good.dts /tmp/bad.dts 266a267,269 > <stdout>: Warning (graph_endpoint): /soc@0/bus@32c00000/csi@32e20000/port/endpoint:remote-endpoint: graph phandle is not valid > <stdout>: Warning (graph_endpoint): /soc@0/bus@32c00000/mipi-csi@32e30000/ports/port@1/endpoint: graph connection to node '/soc@0/bus@32c00000/csi@32e20000/port/endpoint' is not bidirectional > <stdout>: Warning (graph_endpoint): /soc@0/bus@32c00000/csi@32e20000/port/endpoint:remote-endpoint: graph phandle is not valid 941a945 > phandle = <0xaa>; 1711c1715 < phandle = <0x45>; --- > phandle = <0xab>; 2461a2466 > imx219 = "/soc@0/bus@30800000/i2c@30a40000/sensor@10"; 2524a2530 > imx8mm_mipi_csi_in = "/soc@0/bus@32c00000/mipi-csi@32e30000/ports/port@0/endpoint"; 2543a2550 > cam24m = "/cam24m"; 2560a2568 > imx219_to_mipi_csi2 = "/soc@0/bus@30800000/i2c@30a40000/sensor@10/port/endpoint"; 2569a2578 > reg_cam = "/regulator-cam"; 2572a2582 > pinctrl_reg_cam = "/soc@0/bus@30000000/pinctrl@30330000/regcamgrp"; Not very fun trying to debug this. I'm not sure where exactly a warning could go that would help show the problem. With initcall_debug added and manually probing the drivers to help isolate the messages: # modprobe imx219 [ 1163.785027] calling v4l2_async_init+0x0/0x1000 [v4l2_async] @ 627 [ 1163.791401] initcall v4l2_async_init+0x0/0x1000 [v4l2_async] returned 0 after 44 usecs [ 1163.808005] calling imx219_i2c_driver_init+0x0/0x1000 [imx219] @ 627 [ 1163.814693] imx219 2-0010: supply VANA not found, using dummy regulator [ 1163.821625] imx219 2-0010: supply VDDL not found, using dummy regulator [ 1163.837185] probe of 2-0010 returned 0 after 22594 usecs [ 1163.842614] initcall imx219_i2c_driver_init+0x0/0x1000 [imx219] returned 0 after 28094 usecs ^^ no problems here with the imx219 camera sensor # modprobe imx_mipi_csis [ 1207.488915] calling mipi_csis_driver_init+0x0/0x1000 [imx_mipi_csis] @ 633 [ 1207.496401] probe of 32e30000.mipi-csi returned -517 after 24 usecs [ 1207.502884] initcall mipi_csis_driver_init+0x0/0x1000 [imx_mipi_csis] returned 0 after 6866 usecs ^^^ the -517 (EPROBE_DEFER) here shows a problem but its not clear why it defers # modprobe imx7_media_csi [ 1214.345573] calling imx7_csi_driver_init+0x0/0x1000 [imx7_media_csi] @ 636 [ 1214.353170] imx-pgc imx-pgc-domain.10: imx_pgc_power_up dispmix [ 1214.359185] imx-pgc imx-pgc-domain.10: imx_pgc_power_up dispmix ok [ 1214.365424] imx7_csi_probe [ 1214.368532] imx7-csi 32e20000.csi: Registered csi capture as /dev/video2 [ 1214.375688] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get remote endpoint [ 1214.383250] imx7_csi_probe async_register failed -107 [ 1214.388643] imx7-csi: probe of 32e20000.csi failed with error -107 [ 1214.394913] imx-pgc imx-pgc-domain.10: imx_pgc_power_down dispmix [ 1214.396068] probe of 32e20000.csi returned 107 after 42995 usecs [ 1214.401065] imx-pgc imx-pgc-domain.10: imx_pgc_power_down dispmix ok [ 1214.414034] initcall imx7_csi_driver_init+0x0/0x1000 [imx7_media_csi] returned 0 after 61350 usecs ^^^ the ENOTCONN here is due to imx_mipi_csis being deferred The whole problem appears to be because I was using 'make DTC_FLAGS="-@" dtbs' in my build script because my previous kernel version required the DTC_FLAG for overlays and now apparently not only is it no longer required it causes an issue. Thanks for the testing, and thanks Stefan for the suggestion of adding initcall_debug - they both helped me down the right path to understanding this issue. Best Regards, Tim
