[PATCH 0/4] media: ov9734: Support the Microsoft Surface Laptop 1 front camera
From: Afonso Figuinha
Date: Thu Nov 05 2026 - 18:03:57 EST
The front camera of the Microsoft Surface Laptop 1 is an OmniVision
OV9734 connected to the IPU3 CIO2. It does not work today for two
reasons. The ipu-bridge does not know the OVTI9734 HID, so no fwnode
graph is built for the sensor. The ov9734 driver relies on ACPI to
power the sensor, while on this laptop an INT3472 discrete device
(SKC1 in the DSDT) controls the clock and the reset line.
Patch 1 adds the sensor to ipu-bridge. Patch 2 makes the driver wait
for the endpoint that the bridge creates. Patch 3 adds the reset GPIO,
the supplies and the PM callbacks. Patch 4 adds control event support,
so v4l2-compliance passes.
The series is based on media-committers next (v7.4-rc1).
ov9734.o and ipu-bridge.o build there with W=1 and C=1 (sparse from
git) with no warnings.
Hardware tests ran on a Surface Laptop 1 with 6.19.8-surface-3, the
linux-surface kernel. Patches 2 to 4 apply to 6.19.8 with offsets
only, apart from the v4l2_subdev_client_info API change, which they do
not touch. That kernel also carries the linux-surface camera patches,
and I did not check which of them this result depends on. Patch 1 does
not apply there because the sensor list differs, so the same entry was
added by hand.
Results:
- the sensor probes and the chip ID reads back as 0x9734;
- libcamera (IPU3 pipeline) streams 1280x704 at 30 fps;
- the sensor is runtime suspended when idle and active while
streaming;
- unloading and reloading the module works with no warnings;
- v4l2-compliance 1.32.0 on the sensor subdev: 46 tests, 46 passed,
0 warnings. Without patch 4, the event subscription test fails.
Not tested:
- a boot of the posted base;
- probe deferral at boot with this exact revision of patch 2. The
sensor binds at boot, but a deferred probe is no longer logged, so I
could not confirm the sensor driver probed before ipu3-cio2 on that
boot. An earlier revision with the same logic logged the deferral
and then bound;
- platforms that power the sensor through ACPI, which the driver
supported before this series. Where no reset GPIO is described, the
callbacks only enable and disable the clock, and the supplies fall
back to dummy regulators;
- system suspend while streaming.
libcamera also needs changes for this sensor. I am sending them to
libcamera-devel at the same time.
Tool disclosure: this series was developed with an AI coding
assistant (Claude Code, model Claude Opus 5.5) in an interactive
session on the laptop. I asked it to get the front camera working. It
read the DSDT, the driver sources and the kernel logs, wrote the
patches, drafted the commit messages and this cover letter, and ran
the builds and tests listed above on the laptop. I reviewed every
change and can answer review comments on it.
Afonso Figuinha (4):
media: ipu-bridge: Add OV9734 to the supported sensors list
media: i2c: ov9734: Defer probe until the fwnode graph endpoint exists
media: i2c: ov9734: Add reset GPIO, supplies and PM callbacks
media: i2c: ov9734: Support control events
drivers/media/i2c/ov9734.c | 115 ++++++++++++++++++++++++---
drivers/media/pci/intel/ipu-bridge.c | 2 +
2 files changed, 107 insertions(+), 10 deletions(-)
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
--
2.53.0