Rpi/embedded data support/rpi 6.6.y

[jmondi]

This branch backports embedded data support to rpi-6.6.y

It includes framework changes to support embedded data and

• CFE from mainline
• Unicam from mainline
• Aligns imx219 with mainline
• Sensor patches from Naush to support embedded data

The branch compiles with rpi defconfig but fails for other drivers not part of defconfig. I'm working to backport the necessary changes there too.

The associated libcamera branch will be pushed soon.

[jmondi]

@naushir Naush I haven't changed this, but this hunk seems to revert 074f41b

[naushir]

That's probably an error on my part!

[jmondi]

Refreshed the pull request, compared to v1:

• Test compiling with allmodconfig
• Compact backports at the beginning of the series
• Drop ov2740 multistream support
• Backport 2 BSP patches on mainline unicam
• Backport CFE from the patches merged in media-stage and not from the mailing list
• Fix imx477 multi-stream support reverting a BSP commit

[jmondi]

Added three patches from @jailuthra on top of Naush's one for sensors to add support for enable/disable_streams.

We kept them separate to ease review as they apply on top of Naush's ones. They can be squashed in later.

[jailuthra]

Ah, I missed the check for bpp == 8 here.

I will rework f54e586 and also see if it can be posted upstream.

[jmondi]

Re-established the correct handling of analog binning mode for imx219 by applying ef737ab

[naushir]

Starting to test this now together with raspberrypi/libcamera#200 and all looks ok so far...

[jmondi]

Rebased on most recent rpi-6.6.y and apply the following change

@ -1025,7 +1025,7 @@ static int imx219_set_pad_format(struct v4l2_subdev *sd,
	 * embedded data stream.
	 */
	ed_format = v4l2_subdev_state_get_format(state, IMX219_PAD_EDATA);
-	ed_format->code = imx219_format_edata(format->code);
+	ed_format->code = MEDIA_BUS_FMT_CCS_EMBEDDED;
	ed_format->width = format->width;
	ed_format->height = IMX219_EMBEDDED_DATA_HEIGHT;
	ed_format->field = V4L2_FIELD_NONE;
@ -1033,6 +1033,7 @@ static int imx219_set_pad_format(struct v4l2_subdev *sd,
	format = v4l2_subdev_state_get_format(state, IMX219_PAD_SOURCE,
					      IMX219_STREAM_EDATA);
	*format = *ed_format;
+	format->code = imx219_format_edata(format->code);

	if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
		u32 prev_hts = format->width + imx219->hblank->val;

To imx219, imx277, imx519 and imx708

[naushir]

Been testing on VC4 platforms, the one bit of functionality seems missing is allowing unpacked formats to be used. I think the following fixes it:

diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
index 1a6a0eacd49d..dce1047c3baa 100644
--- a/drivers/media/platform/broadcom/bcm2835-unicam.c
+++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
@@ -550,7 +550,8 @@ unicam_find_format_by_fourcc(u32 fourcc, u32 pad)
        }

        for (i = 0; i < num_formats; ++i) {
-               if (formats[i].fourcc == fourcc)
+               if (formats[i].fourcc == fourcc ||
+                   formats[i].unpacked_fourcc == fourcc)
                        return &formats[i];
        }

@6by9, our D/S unicam driver seems to do something with a check_variant flag in this bit of code that I can't quite understand. Do we want to add it back here?

[naushir]

Also PDAF does not seem to work correctly on Unicam + IMX708 - will need to check this next.

[6by9]

MEDIA_BUS_FMT_YUYV8_2X8 and MEDIA_BUS_FMT_YUYV8_1X16 both mapped to V4L2_PIX_FMT_YUYV (and the other component orderings).

Mainline try to say that 2X.. shouldn't be used for serial interfaces (only parallel where you can have multiple transfers per pixel). However that isn't true in all drivers, including adv7180. adv748x afe got fixed up recently.

I have fixed adv7180 up downstream in 4f9944c, and that's the only device we really care about that needed this workaround. (Yes, another patch I ought to send upstream)

[naushir]

Also PDAF does not seem to work correctly on Unicam + IMX708 - will need to check this next.

For some reason, the first frame has invalid PDAF/HDR metadata when running with Unicam, subsequent frames are fine. CFE/Pi 5 does not seem to show this problem. @njhollinghurst any thoughts as to why this may be? The following test in the helper fails:

if (bpp < 10 || bpp > 14 || len < 194 * step || ptr[0] != 0 || ptr[1] >= 0x40) {

because ptr[0] != 0.

[njhollinghurst]

Of course it means the PDAF data packet was corrupt (or the packet at that position was not PDAF). It's a pretty weak validation -- only 2 bytes are checked -- and since the driver doesn't say how many bytes were received, we can't tell if we're checking current or stale buffer contents. EDIT: The nonzero value does at least suggest we received something...

Is it possible that this always happens (in which case the warning should maybe be suppressed), but in other cases we drop the entire first metadata buffer so the check is never performed?

[naushir]

In the old (i.e. existing) codebase, the first frame coming out of the sensor/Unicam goes through to the helper and gets parsed without errors. I'll trace this again with the new code.

[jmondi]

MEDIA_BUS_FMT_YUYV8_2X8 and MEDIA_BUS_FMT_YUYV8_1X16 both mapped to V4L2_PIX_FMT_YUYV (and the other component orderings).

Mainline try to say that 2X.. shouldn't be used for serial interfaces (only parallel where you can have multiple transfers per pixel). However that isn't true in all drivers, including adv7180. adv748x afe got fixed up recently.

I have fixed adv7180 up downstream in 4f9944c, and that's the only device we really care about that needed this workaround. (Yes, another patch I ought to send upstream)

Hi Dave
do you think you will need to keep the support for the 2X8 formats once [4f9944c] is upstreamed ?

[6by9]

Hi Dave do you think you will need to keep the support for the 2X8 formats once [4f9944c] is upstreamed ?

No, it's officially the wrong thing to do, and doesn't impact any of the source drivers that we care about.
If someone tries adding support for a driver that "does the wrong thing", they get told to fix up the source driver.

At the time I originally wrote the Unicam driver I don't think 2X formats had been officially been stated as not applicable for CSI, hence working around the source driver quirks.