IMX471: VIDIOC_STREAMON fails with EPIPE on the mainline imx471 driver, the HAL config fixes RGGB but the driver follows VFLIP

Start by reading config/linux/ipu7x/sensors/imx471-uf.json and the PipeManager.cpp section around lines 339–346, then compare the HAL behavior described for the two driver configurations. Determine whether the HAL reads Bayer order at runtime and whether the processing graph handles it; the issue asks for a support decision and documentation if RGGB under flips is required. Done means the supported behavior is established for IMX471 and documented as needed.

The HAL cannot start an IMX471 camera with the mainline imx471 driver (kernel 7.3.3). VIDIOC_STREAMON returns EPIPE and no frame arrives. The sensor config fixes the Bayer order to RGGB and sets VFLIP=1. The mainline driver reports a Bayer order that follows the flips, so with VFLIP=1 it reports SGBRG10 and the pad formats do not match.

Environment

• ThinkPad X9 (Lenovo 21QACTO1WW), IMX471 front camera, HM1092 IR camera
• Kernel 7.3.3, mainline imx471 (drivers/media/i2c/imx471.c)
• intel_ipu7 and the ISYS driver from intel/ipu7-drivers at 495acc90 (built out of tree)
• intel/ipu7-camera-hal tag 20260629_1, built from the tag source with -DLINUX_PRIVACY_MODE=OFF, started with icamerasrc
• Config: config/linux/ipu7x/sensors/imx471-uf.json, unchanged

Symptom

Each camera start failed the same way in the journals of two boots (2026-11-08 and 2026-11-11):

CamHAL[ERR] V4l2_device_cc: GetControl: Device node /dev/v4l-subdev5 IOCTL VIDIOC_G_EXT_CTRLS error: Invalid argument
CamHAL[ERR] V4l2_video_node_cc: Start: Device node /dev/video2 IOCTL VIDIOC_STREAMON error: Broken pipe
CamHAL[ERR] CaptureUnit: Device:Generic stream on failed.
CamHAL[ERR] CaptureUnit: Devices stream on failed:-38
CamHAL[ERR] CameraDevice: Start capture unit failed with ret:-38.
CamHAL[ERR] CameraDevice: Camera device starts failed.

Cause

The config sets V4L2_MBUS_FMT_SRGGB10_1X10 on the sensor pad and on the CSI-2 pad, and iSysRawFormat to RGGB10. It also sets V4L2_CID_VFLIP to 1 (imx471-uf.json:28-36, :54, :187-189).

The mainline driver picks the media bus code from both flips: imx471_hv_flips_bayer_order[] is RGGB, GRBG, GBRG, BGGR, indexed by vflip << 1 | hflip (imx471.c:272-276, imx471_get_format_code()). With VFLIP=1 and HFLIP=0 the sensor code is SGBRG10, while the HAL sets SRGGB10 on the pads. By reading, STREAMON then fails the link validation of the CSI-2 pad, which returns EPIPE on a format mismatch. I did not trace the kernel call. The driver sets V4L2_CTRL_FLAG_MODIFY_LAYOUT on both flip controls (imx471.c:749-750), so the code follows the flips by design.

The out-of-tree imx471.c that I used before (Intel copyright header, 2025) does not behave like this. It always reports SRGGB10 and moves the end of the readout window by one row when VFLIP is on (it adds 1 to the low byte of Y_ADD_END, register 0x034b), so the first row stays red. I did not diff that file against intel/ipu7-drivers. The HAL config works with this behaviour. Users of the mainline driver do not get it.

What I tried

• HAL unchanged, mainline driver patched to keep RGGB under VFLIP (same row shift as the out-of-tree driver). The camera streams: 40 of 40 frames at 1280x720, correct orientation and colours, no EPIPE.
• Mainline driver unpatched, config changed to GBRG (SGBRG10 for the two pad formats, iSysRawFormat and supportedISysFormat), and the workaround in PipeManager.cpp:339-346 widened to also accept V4L2_PIX_FMT_SGBRG10/12 as external format. The camera streams, but the picture is blue. By reading, the cause is the comment at PipeManager.cpp:339-341: the processing graph takes GRBG as input and crops the real RGGB data to GRBG. GBRG data gives the wrong phase after that crop. I did not verify this in the graph.

The second experiment shows that accepting another order in the HAL needs a change in the processing graph, not only in the config.

Request

Please say which of these the HAL supports for IMX471 with a mainline sensor driver:

1. The HAL reads the Bayer order from the sensor at runtime and the ISP graph handles the other orders. A fixed RGGB in the sensor JSON would then not be needed.
2. The HAL requires a sensor driver that keeps RGGB under the flips. This would then be documented, for IMX471 and for any other sensor whose config sets a flip control.

I can test a change against this hardware. I have not tested other sensors, other kernel versions or the IPU7.5 configs.

Not verified

• Whether other sensor configs in this repo have the same dependency on the Bayer order. I only tested IMX471.
• Why the graph produces a blue picture with GBRG (see above). This is from reading the code.
• The failure with the unpatched mainline driver is from the journals of two earlier boots, not from a fresh run today.