media: Add OmniVision OV32C4 sensor driver

Hi,

v3 of the OV32C4 sensor driver. v2 is at
https://lore.kernel.org/linux-media/[email protected]/

Changes in v3 are Sakari's review of v1, carried out in full; the per-patch changelogs have the detail. The three that are more than mechanical:

- The line length. OV32C4_SCLK and the scaling function are gone; the mode carries .ppl directly, in pixels in the units of PIXEL_RATE, as you said it should be. The numbers come out identical, checked against the controls before and after: hblank 816, vblank 774, exposure max 2582, pixel rate 320000000.

- The chip id retries are dropped. Measured over 31 power-ups of the sensor - one cold boot and 30 unbind/bind cycles - the first read answered every time, so the power-up sequence is sufficient on its own.

- .get_frame_desc() is dropped, and the argument I made for it in v1 does not hold. I re-measured it properly this time: the same scene, 60 frames, with the op and without it. Both give 10 "Received packet is too long" errors and an identical picture. The receiver reports that extra long packet either way; the op never suppressed it, and I had attributed to it something it does not do.

One measurement I would rather report than sit on, on dropping the endpoint check. On the 7.0 kernel this machine runs, v4l2_fwnode_endpoint_alloc_parse() returns -EINVAL rather than -EPROBE_DEFER when the endpoint is not there yet, and the probe is then not retried, so the sensor does not bind at boot when it loses the race with ipu-bridge - which it does on roughly half the boots here. The deferring path with the comment naming the IPU bridge is in media_stage. So the check is redundant against the tree this is merged into, which is why it is gone, and I mention the older behaviour only as data.

The companion chip, which was the first of the two questions in v2: it is not a VCM, and my guess that it might be one with an integrated LDO was wrong. Measured, with the sensor powered and the VCM driver unbound:

    w2@0x3e 0x10 0x01  r1@0x3e   ->  0x04     (what we write, read back)
    w2@0x3e 0x10 0x00  r8@0x3e   ->  00 04 00 00 00 00 00 00
    w2@0x3e 0x10 0x00 r32@0x3e   ->  a sparse block at 0x1010-0x1018
    w2@0x3e 0x00 0x00 r32@0x3e   ->  all zeroes

It has a 16-bit addressed register file and it remembers writes, so it is not a dw9714, which is a write-only DAC with no register addressing at all. Where the name comes from is ipu-bridge: it takes vcmtype straight out of the ACPI SSDB and indexes ipu_vcm_types[] with it without checking anything, and dw9714 has no id register, so its driver binds unconditionally. The chip has no ACPI device of its own - the subdev ends up with 0 pads and 0 links - and I found no id register in it, so I cannot name it. The vendor Windows driver issues the same write from its sensor driver and has no separate driver for it either.

So the position is unchanged but better founded: the write has to happen or the sensor does not answer on I2C, and there is no handle for the chip in the device model other than that mis-named VCM client. I still agree it does not belong in a sensor driver. What I do not know is the shape you want, since a regulator would mean a driver for a chip nobody can name, and something would first have to stop ipu-bridge from claiming the address as a VCM. Guidance welcome; I am happy to do the work.

Still open from your review: the power-up timings. "These are 0 and 5 ms, respectively" - I did not follow, and the question stands. The values in the patch are 5 ms after the supply and 20 ms after reset, arrived at during bring-up; there is no datasheet.

The rest of the series is as before. It adds a driver for the OmniVision OV32C4, a 32 megapixel RGBC CMOS image sensor. It ships as the under-display camera in the Lenovo Yoga Slim 9 14ILL10, where it is enumerated through ACPI (_HID "OVTI32C4") and feeds an Intel IPU7. The last patch adds the sensor to ipu-bridge; without it the bridge builds no fwnode graph for the sensor and the driver never binds.

The driver supports 3264x1840 at 30 fps, 10-bit Bayer, 4 CSI-2 lanes at a 400 MHz link frequency, with exposure, analogue gain, digital gain, vblank, hblank and flip controls, runtime PM and .get_selection.

Tested on the machine above: the sensor probes, streams continuously at a measured 30.00 fps, and the frames arrive complete (60 frames = 720691200 bytes = 60 * 3264 * 1840 * 2). The full path up to a processed image was exercised with libcamera's software ISP.

There is no public datasheet for this sensor, so a note on where the numbers come from. The comments that carried this in v2 are gone from the code, as you asked, so it is here:

- The mode register table is the verbatim initialisation sequence from the vendor Windows driver: 1787 writes, strictly ascending, copied 1:1 with nothing added or reordered.
- The register meanings the controls depend on (exposure 0x3500, analogue gain 0x3508, digital gain 0x350a, VTS 0x380e, and the rule exposure_max = VTS - 32) were read out of the same binary and then confirmed against the values the chip reports.
- The derived timings were checked against reality: the computed

    320000000 / (4080 * 2614) = 30.005 fps matches the measured 30.00.

- The 6560x4928 pixel array and the 6528x4896 active area reported by .get_selection follow from the window registers of the mode table and agree with the vendor's published product brief.
- The gain ranges were measured on the sensor, not inherited. The vendor driver clamps gain a layer above and carries no limits of its own, and the obvious donor - ov13b10, same registers - puts analogue unity at 0x80, which is wrong here. Analogue response is exactly proportional between 0x100 and 0x7c0 (1x to 7.75x, 0x100 also being the power-up value); digital gain is proportional with 1024 as unity and clips to black one step above 16383.
- Flip handling was measured the same way. This sensor preserves the Bayer order across mirror and flip, so the driver only toggles the bits and the media bus code never changes. ov13b10 compensates the crop window by one pixel on the same registers to undo a Bayer shift; doing that here introduces one rather than removing it.

Tooling disclosure, as asked for by Documentation/process/generated-content.rst:
this series was written with the help of an AI coding assistant (Claude, Anthropic; claude-opus-5 for the early work, claude-fable-5 for the rest) in an extended interactive session. The assistant drafted the driver source, the binding and this cover letter from my descriptions of the hardware and of the vendor driver; every register meaning, gain range and timing in it was measured by me on the sensor as described above, I ran all of the tests, and I have reviewed and understand all of the code and take responsibility for it. The mode register table was copied 1:1 from the vendor driver, not generated. Static checks used: checkpatch.pl --strict, sparse (C=1), W=1 and dt_binding_check. The individual patches carry Assisted-by tags.

The series applies to media_stage.git; base-commit is below.

Thanks,
Robert

Robert Bozik (3):
dt-bindings: media: i2c: Add OmniVision OV32C4
media: i2c: Add driver for OmniVision OV32C4
media: ipu-bridge: Add OmniVision OV32C4

 .../bindings/media/i2c/ovti,ov32c4.yaml       |  105 +
 MAINTAINERS                                   |    8 +
 drivers/media/i2c/Kconfig                     |   10 +
 drivers/media/i2c/Makefile                    |    1 +
 drivers/media/i2c/ov32c4.c                    | 2664 +++++++++++++++++
 drivers/media/pci/intel/ipu-bridge.c          |    2 +
 6 files changed, 2790 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov32c4.yaml
 create mode 100644 drivers/media/i2c/ov32c4.c

base-commit: 4900cad020c0580dfb1be27776ff10a4ef110cfa

2.53.0

Add a binding for the OmniVision OV32C4, a 32 megapixel RGBC CMOS image sensor with on-chip 4-cell fusion, a 4-lane MIPI CSI-2 D-PHY transmitter and the standard SCCB command interface.

The sensor ships in laptops as an under-display camera, where it is described by ACPI; the binding follows ovti,ov08x40.yaml, which covers the closest relative already in tree.

---
Changes in v3:
- No changes to the binding itself; picked up Conor Dooley's Acked-by.

 .../bindings/media/i2c/ovti,ov32c4.yaml       | 105 ++++++++++++++++++
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov32c4.yaml

new file mode 100644
index 000000000..804307cd0
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov32c4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV32C4 Image Sensor
+
+maintainers:
+  - Robert Bozik <[email protected]>
+
+description:
+  The OmniVision OV32C4 is a 32 megapixel RGBC (red, green, blue and clear)
+  CMOS image sensor in a 4-cell arrangement, with on-chip 4-cell fusion and
+  binning. It has a 6528x4896 active pixel array, a 4-lane MIPI CSI-2 D-PHY
+  transmitter and the standard SCCB command interface.
+
+allOf:
+  - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+  compatible:
+    const: ovti,ov32c4
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: Input clock (XVCLK).
+
+  avdd-supply: true
+
+  dovdd-supply: true
+
+  dvdd-supply: true
+
+  reset-gpios:
+    maxItems: 1
+    description: Active low GPIO connected to the XSHUTDOWN pad of the sensor.
+
+  port:
+    $ref: /schemas/graph.yaml#/$defs/port-base
+    additionalProperties: false
+
+    properties:
+      endpoint:
+        $ref: /schemas/media/video-interfaces.yaml#
+        additionalProperties: false
+
+        properties:
+          data-lanes:
+            items:
+              - const: 1
+              - const: 2
+              - const: 3
+              - const: 4
+          link-frequencies: true
+          remote-endpoint: true
+
+        required:
+          - data-lanes
+          - link-frequencies
+          - remote-endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - port
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        camera@36 {
+            compatible = "ovti,ov32c4";
+            reg = <0x36>;
+
+            clocks = <&ov32c4_clk>;
+            assigned-clocks = <&ov32c4_clk>;
+            assigned-clock-rates = <19200000>;
+
+            avdd-supply = <&vreg_2p8>;
+            dovdd-supply = <&vreg_1p8>;
+            dvdd-supply = <&vreg_1p1>;
+
+            reset-gpios = <&tlmm 111 GPIO_ACTIVE_LOW>;
+
+            port {
+                ov32c4_ep: endpoint {
+                    remote-endpoint = <&csiphy0_ep>;
+                    data-lanes = <1 2 3 4>;
+                    link-frequencies = /bits/ 64 <400000000>;
+                };
+            };
+        };
+    };
+...

2.53.0

The OV32C4 is a 32 megapixel RGBC CMOS image sensor with on-chip 4-cell fusion and binning, connected over 4 MIPI CSI-2 D-PHY lanes. It is used as an under-display camera in laptops, where it is enumerated through ACPI (_HID "OVTI32C4") and paired with an Intel IPU.

The driver supports 3264x1840 at 30 fps in 10-bit Bayer at a link frequency of 400 MHz, with exposure, analogue gain, digital gain, vblank, hblank and horizontal and vertical flip controls, runtime PM and .get_selection reporting the 6560x4928 pixel array.

There is no public datasheet for this sensor. The mode register table is the verbatim initialisation sequence from the vendor driver, and the registers the controls use were established by correlating that binary with the values read back from the chip; the cover letter has the measurements that back the ranges.

---
Changes in v3, all from Sakari Ailus' review of v1:
- Commit message and the provenance comments in the file cut down; what was measured is in the cover letter instead.
- Kconfig: dropped "depends on ACPI || COMPILE_TEST".
- OV32C4_SCLK and ov32c4_ppl() are gone. The line length is carried by the mode as .ppl, in pixels in the units of the PIXEL_RATE control, and OV32C4_REG_HTS names the register that holds the same line in the sensor's own clock units. The values are unchanged: ppl 4080, hblank 816, pixel_rate 320000000.
- Dropped the chip id read retries. Measured over 31 power-ups of the sensor - one cold boot and 30 unbind/bind cycles, each cutting the supply and the reset - the first read answered every time.
- Dropped .get_frame_desc(). Re-measured with and without it on the same
scene: 10 "Received packet is too long" errors per 60 frames either way, and the image is unaffected. The justification given in v1 was wrong; see the cover letter.
- Dropped the endpoint check in check_hwcfg().
- pm_runtime_get_if_active() instead of pm_runtime_get_if_in_use().
- Control flags set after the handler error check, and the two "if the control exists" conditions around them dropped.
- v4l2_fwnode_device_parse() moved ahead of the controls; return values of __v4l2_ctrl_modify_range() and of the write in .disable_streams() are checked.
- MIPI_CSI2_DT_RAW10 from <media/mipi-csi2.h> (with .get_frame_desc() gone, the include went with it), unsigned int for the loop variable, debug prints and redundant comments removed.

 MAINTAINERS                |    8 +
 drivers/media/i2c/Kconfig  |   10 +
 drivers/media/i2c/Makefile |    1 +
 drivers/media/i2c/ov32c4.c | 2664 ++++++++++++++++++++++++++++++++++++
 4 files changed, 2683 insertions(+)
 create mode 100644 drivers/media/i2c/ov32c4.c

index 3785b8c1d..7b28717fc 100644
@@ -20008,6 +20008,14 @@ S:	Maintained
 T:	git git://linuxtv.org/media.git
 F:	drivers/media/i2c/ov2740.c
 
+OMNIVISION OV32C4 SENSOR DRIVER
+M:	Robert Bozik <[email protected]>
+L:	[email protected]
+S:	Maintained
+T:	git git://linuxtv.org/media.git
+F:	Documentation/devicetree/bindings/media/i2c/ovti,ov32c4.yaml
+F:	drivers/media/i2c/ov32c4.c
+
 OMNIVISION OV4689 SENSOR DRIVER
 M:	Mikhail Rudenko <[email protected]>
 L:	[email protected]

index 5c52007f9..1c363d581 100644
@@ -547,6 +547,16 @@ config VIDEO_OV2740
 	  To compile this driver as a module, choose M here: the
 	  module will be called ov2740.
 
+config VIDEO_OV32C4
+	tristate "OmniVision OV32C4 sensor support"
+	select V4L2_CCI_I2C
+	help
+	  This is a Video4Linux2 sensor driver for the OmniVision
+	  OV32C4 camera.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called ov32c4.
+
 config VIDEO_OV4689
 	tristate "OmniVision OV4689 sensor support"
 	depends on GPIOLIB

index d04bd5724..79bf2e393 100644
@@ -102,6 +102,7 @@ obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
 obj-$(CONFIG_VIDEO_OV2732) += ov2732.o
 obj-$(CONFIG_VIDEO_OV2735) += ov2735.o
 obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
+obj-$(CONFIG_VIDEO_OV32C4) += ov32c4.o
 obj-$(CONFIG_VIDEO_OV4689) += ov4689.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o

2.53.0

On Sat, Aug 29, 2026, [email protected] wrote:

Hi,

Thank you for the review. All three findings are real. The first one needs a different fix from the one the description implies, and I would rather say why than fix it quietly.

Confirmed, but only for one of the two cases the negative return covers.

pm_runtime_get_if_active() returns -EINVAL when runtime PM is disabled for the device and does not take a reference in that case, so the unconditional pm_runtime_put() at the end of the function does underflow the counter. That part is right.

Returning the error early would break the other case, though. With CONFIG_PM=n the inline version in include/linux/pm_runtime.h returns -EINVAL unconditionally, so an early return would make every control write fail on a kernel without runtime PM - where the sensor is in fact permanently powered and the writes are exactly what should happen. The drivers in the tree that use this idiom (gc05a2, gc08a3, imx283 and lm3560, twice) all let the negative value fall through for that reason.

v4 therefore keeps the fall-through and only drops a reference that was actually taken:

	/*
	 * A negative return means runtime PM is disabled for the device,
	 * in which case it is powered and the registers can be written,
	 * but no reference was taken and none may be dropped below.
	 */
	pm = pm_runtime_get_if_active(ov32c4->dev);
	if (!pm)
		return 0;
	...
	if (pm > 0)
		pm_runtime_put(ov32c4->dev);

Right, thank you. The fields are left as userspace passed them and then stored in the subdev state. gc05a2 and gc08a3 set all four, and v4 does the same:

	fmt->colorspace = V4L2_COLORSPACE_RAW;
	fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace);
	fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE;
	fmt->xfer_func = V4L2_XFER_FUNC_NONE;

Right, and it is a consequence of a change made in v3. acpi_dev_get_resources() and acpi_dev_free_resource_list() are declared inside the CONFIG_ACPI section of include/linux/acpi.h and have no stubs in the #else branch, so with "depends on ACPI || COMPILE_TEST" dropped from Kconfig in v3 the driver no longer builds without ACPI. v4 puts the _CRS walk behind #ifdef CONFIG_ACPI with a stub returning 0, which is also more honest: that lookup only means anything on an ACPI platform.

All three are fixed in my tree and will be in v4, which is waiting for the rest of the review of v3. Rebuilt and re-tested on the machine after the changes: the sensor probes, streams and the controls still work.

Thanks,
Robert

Add the sensor configuration for the OV32C4, matching the _HID the sensor enumerates with. Without this entry the bridge does not build a software node graph for the sensor, so its driver defers probing on the missing fwnode endpoint forever and the camera never binds.

---
Changes in v3:
- Comment above the entry cut down to the sensor name; where the link frequency comes from is documented in the driver instead.

 drivers/media/pci/intel/ipu-bridge.c | 2 ++
 1 file changed, 2 insertions(+)

index 1bb3a3e98..385400a58 100644
@@ -93,6 +93,8 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
 	IPU_SENSOR_CONFIG("OVTIDB10", 1, 560000000),
 	/* Omnivision OV2680 */
 	IPU_SENSOR_CONFIG("OVTI2680", 1, 331200000),
+	/* Omnivision OV32C4 */
+	IPU_SENSOR_CONFIG("OVTI32C4", 1, 400000000),
 	/* Omnivision OV5675 */
 	IPU_SENSOR_CONFIG("OVTI5675", 1, 450000000),
 	/* Omnivision OV8856 */

2.53.0