Trying to use ISI on apalis-imx8 as a V4L2 mem2mem device

I am trying to set up the i.MX8 QuadMax’s ISI (on the apalis-imx8) to be exported to Linux userspace as a V4L2 memory-to-memory device for purposes of colorspace conversion. This worked well in the Dunfell release, but does not work properly in Kirkstone. v4l2-ctl -d /dev/video3 --list-formats-ext --list-formats-out-ext prints out:

ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture Multiplanar

        [0]: 'RGBP' (16-bit RGB 5-6-5)
        [1]: 'RGB3' (24-bit RGB 8-8-8)
        [2]: 'BGR3' (24-bit BGR 8-8-8)
        [3]: 'YUYV' (YUYV 4:2:2)
        [4]: 'YUV4' (32-bit A/XYUV 8-8-8-8)
        [5]: 'NV12' (Y/CbCr 4:2:0)
        [6]: 'NM12' (Y/CbCr 4:2:0 (N-C))
        [7]: 'YM24' (Planar YUV 4:4:4 (N-C))
        [8]: 'XR24' (32-bit BGRX 8-8-8-8)
        [9]: 'AR24' (32-bit BGRA 8-8-8-8)
ioctl: VIDIOC_ENUM_FMT
        Type: Video Output Multiplanar

The “output” side if actually where the input frames that are to be converted go, while the capture side is where converted frames come out of (it is a somewhat confusing V4L2 terminology). As can be seen here, the list of supported formats for the output side is empty - this is the bug. It should list at least a couple of RGB formats.

The ISI is normally not set up for this. It has to be enabled in the devicetree. I use this patch:

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1-eval.dts b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1-eval.dts
index 6589cdb2251b..e8cb7be0a0c7 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1-eval.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-apalis-v1.1-eval.dts
@@ -14,3 +14,15 @@
 		     "toradex,apalis-imx8-v1.1",
 		     "fsl,imx8qm";
 };
+
+&isi_0 {
+    status = "okay";
+
+    cap_device {
+        status = "okay";
+    };
+
+    m2m_device {
+        status = "okay";
+    };
+};

Do you see anything wrong here? uname -a shows:

Linux apalis-imx8 5.15.77-0+git.3592e06b1bda #1 SMP PREEMPT Wed May 24 16:25:17 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Nevermind. A USB camera caused the dev/videoX nodes to shift in number, so video3, which used to be the correct device, now wasn’t. /dev/video2 works properly.