Three patches for Lunar Lake (LNL) camera bring-up – SET_HOST_IDENTIFIER, auto-release, sensor_owner sysfs

[osandum]

I got the IPU7 camera fully working on a Dell XPS 13 (Core Ultra 200V, Lunar Lake) running Fedora 42 / kernel 6.18.8, with three patches to the CVS driver. These address the same probe failure reported in #31.

Hardware

• Dell XPS 13 (hw rev 0x10280cc9)
• Camera: OV02C10 (OVTI02C1:00) on CSI-2 port 0, I2C via usbio-i2c.1
• CVS chip: INTC10DE:00 at 0x76 on usbio-i2c.0
• Protocol 1.0, no magic number support

Problem

The unmodified driver fails to probe because SET_HOST_IDENTIFIER returns -EIO and the driver treats this as fatal. This is the same failure in #31:

Intel CVS driver i2c-INTC10DE:00: cvs_common_probe:set_host_identifier cmd failed

Once that's fixed, the driver acquires the sensor via the GPIO handshake and the camera works. However, two usability problems remain:

1. The camera LED stays on permanently because nothing releases the sensor after probe.
2. There is no mechanism for userspace to re-acquire the sensor on demand after a release.

Patches

1. Make SET_HOST_IDENTIFIER non-fatal

The GPIO-based sensor acquisition handshake succeeds without this I2C command. On this hardware (and likely all LNL with protocol 1.0), the command consistently returns -EIO via the USBIO I2C bridge. Downgrading to dev_warn lets the driver continue to the GPIO handshake.

 			ret = cvs_write_i2c(SET_HOST_IDENTIFIER, NULL, 0);
-			if (ret) {
-				dev_err(cvs->dev, "%s:set_host_identifier cmd failed", __func__);
-				goto exit;
-			}
+			if (ret)
+				dev_warn(cvs->dev, "%s:set_host_identifier cmd failed (non-fatal)", __func__);

2. Delayed sensor release after probe

After acquiring the sensor at probe (so dependent sensor drivers like ov02c10 can bind), schedule a release after 10 seconds. This turns the camera LED off when no application is using the camera.

 	icvs->icvs_sensor_state = CV_SENSOR_VISION_ACQUIRED_STATE;
 	acpi_dev_clear_dependencies(ACPI_COMPANION(icvs->dev));

+	INIT_DELAYED_WORK(&icvs->delayed_release, cvs_delayed_release);
+	schedule_delayed_work(&icvs->delayed_release, msecs_to_jiffies(10000));

(With a corresponding delayed_work field in struct intel_cvs and a cancel_delayed_work_sync in the remove path.)

3. sensor_owner sysfs attribute for userspace acquire/release

Exposes a read/write sysfs file so userspace can acquire the sensor before camera use and release it afterwards:

echo ipu > /sys/bus/i2c/devices/i2c-INTC10DE:00/.../sensor_owner   # LED on, camera usable
echo cvs > /sys/bus/i2c/devices/i2c-INTC10DE:00/.../sensor_owner   # shows "ipu" or "cvs"
cat .../sensor_owner                                                 # shows "ipu" or "cvs"

This is necessary because the camera LED is hardware-tied to the CVS req GPIO – it stays on the entire time the host holds sensor ownership. Without this, users either have no camera (if released) or a permanently-lit LED (if acquired).

Result

With all three patches, the boot sequence is:

1. CVS probes → acquires sensor → ov02c10 binds to IPU7 ISYS
2. 10s later → sensor auto-released → LED off
3. Userspace writes ipu to sysfs → LED on, camera active
4. Userspace writes cvs to sysfs → LED off

The camera works at 1920x1080@30fps via libcamera 0.7.0 Simple pipeline handler + GPU-accelerated SoftISP, exposed through PipeWire.

Note on probe ordering

The upstream kernel has INTC10DE in acpi_ignore_dep_ids[] (commit 4405a214df14), so ov02c10 probes before CVS is ready and fails. A udev rule that re-binds ov02c10 after CVS probes works around this. Antti Laakso's pending patch ("media: ipu-bridge: Add DMI quirk for CVS-sensor dependency") should fix this properly.

Full writeup with ACPI topology, INT3472 details, and upstream references: available on request.

[gheylen]

same hardware here — dell xps 13, core ultra 200v, ov02c10 on lunar lake. trying to get this working via mainline + apt upgrade rather than dkms.

the usbio driver landed in 6.18 (commit 121a0f839dbb) and 2ac1:20c9 is in the id table. on debian sid (7.0.3) the source is there but CONFIG_USB_USBIO isn't enabled — filed a debian kernel bug for that.

the remaining blocker is intel_cvs. the three patches you described are exactly what's needed for lnl — the SET_HOST_IDENTIFIER non-fatal fix especially, since it returns -EIO on my machine too.

any plans to submit drivers/misc/icvs/intel_cvs.c upstream to linux-misc or linux-media? if there's a patch series in flight i can test and tag it. if not, happy to help push it along.

also if you're up for sharing the full writeup you mentioned (acpi topology, int3472 details, upstream references) — that'd be useful if the submission needs a nudge.

[vad1110]

https://lore.kernel.org/linux-media/20260514184431.288353-1-miguel.vadillo@intel.com/