IRS1125 camera kernel driver outputs unvalid data since 5.4.51

[bjajoh]

Hi,

In Kernel 5.4.49 the IRS1125 imager was merged and working. 5.4.49 and 5.4.50 worked just fine as expected.
However without changes to the code since then, it is not working anymore since 5.4.51 More specifically the received data in wrong.

Do you know what happend there?

[6by9]

IRS1125 was contributed by @Coimbra1984. I don't even have hardware to test with.
Ah, I note from #3544 that he tags you as also an employee at pieye.

5.4.51 was the first "stable" release of our 5.4 branch. Until there that point the branch was being rebased, so we don't have the history to diff between 5.4.49 and 5.4.51. I'm not aware of any significant changes.
There was a switch to the upstream Unicam driver with #3688, but that was already in 5.4.49.
There was also a siginficant update in #3609 to how that clocks were setup for CSI-2 reception. Prior to that there was a potential to drop data if the incoming link speed was too high. That affected the HQ camera. Have you tested against the more recent kernels?

Do you receive any data? What configuration mode is the Unicam peripheral in? I'm assuming it's not having to unpack or pack the data seeing as it isn't straight image data. Can you describe how the data is wrong?

[Coimbra1984]

Hi @6by9,
we do receive data, but unpacking RAW12 format to 16 bit doesn't work any longer. That's why we receive inplausible data.
I debugged into bcm2835-unicam.c and the problem is resolved when changing:

        }, {
                .fourcc               = V4L2_PIX_FMT_Y12P,
                .repacked_fourcc = V4L2_PIX_FMT_Y12,
                .code           = MEDIA_BUS_FMT_Y12_1X12,
                .depth          = 12,
                .csi_dt         = 0x2c,
        }, {

into

        }, {
                //.fourcc               = V4L2_PIX_FMT_Y12P,
                .repacked_fourcc = V4L2_PIX_FMT_Y12,
                .code           = MEDIA_BUS_FMT_Y12_1X12,
                .depth          = 12,
                .csi_dt         = 0x2c,
        }, {

[6by9]

So it sounds like commit e047cfe#diff-5a62c2c8d1e6f6475c3825cc14977cca is causing you the grief.

Both formats will be advertised, and it is up to the application/user to choose between the two. The default is the packed format.

eg on imx477

pi@raspberrypi:~ $ v4l2-ctl --list-formats
ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'pRCC' (12-bit Bayer RGRG/GBGB Packed)
	[1]: 'RG12' (12-bit Bayer RGRG/GBGB)
	[2]: 'pRAA' (10-bit Bayer RGRG/GBGB Packed)
	[3]: 'RG10' (10-bit Bayer RGRG/GBGB)

So you can choose between 10 and 12 bit modes (different resolutions are offered by each), and whether they are packed or unpacked.

Use v4l2-ctl --pixelformat Y12 to manually select the unpacking to 16bpp mode, or do so in your app with a call to VIDIOC_S_FMT.

        struct v4l2_format fmt;
        int ret;

        memset(&fmt, 0, sizeof fmt);
        fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;

        ret = ioctl(fd, VIDIOC_G_FMT, &fmt);
        if (ret < 0) {
                print("Unable to get format: %s (%d).\n", strerror(errno),
                        errno);
                return ret;
        }
        fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_Y12;
        ret = ioctl(fd, VIDIOC_S_FMT, &fmt);
        if (ret < 0) {
                print("Unable to set format: %s (%d).\n", strerror(errno),
                        errno);
                return ret;
        }

where fd is the file handle to your open V4L2 node.

I've just checked IMX477 with both packed and unpacked modes. Whilst my unpacked image is dark as I haven't got the ISP dealing with the shift correctly, the images are fine.

[Coimbra1984]

Cool, we were missing this line in our userspace application:

fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_Y12;

I added it and now it works.

[6by9]

Glad to hear that.

Making assumptions over the format is always a bit risky, so best to be explicit over these things.
V4L2 is doubly weird in that should you set a width/height/pixelformat that the driver doesn't support, it chooses the "closest" value (whatever that means), and returns you that format from the VIDIOC_S_FMT call. It does NOT return an error!

[6by9]

Could you close the issue if you're happy that it's resolved?

[Coimbra1984]

@bjajoh will test also on his hardware and than resolves the issue.

[bjajoh]

I'll close that issue once I validated that everything is working fine in the next few days. :) Thanks for your help!

[bjajoh]

Everthing is working as before, thanks for your help!