Re: [PATCH v3] media: ipu-bridge: do not use the CVS device lookup for IVSC

[Junjie Cao <junjie.cao@intel.com>]

On Sat, 12 Sep 2026 20:58:32 +0200, Manuel Knitza wrote:
> On this machine the driver on that i2c device is Intel's out-of-tree
> intel_cvs (from intel/vision-drivers), and it provides only ownership
> arbitration and firmware update - no CSI-2 subdevice.
[...]
> There is no in-tree CVS driver to take that role.

There is, since v7.2: drivers/media/i2c/cvs/, CONFIG_VIDEO_INTEL_CVS,
8e2b43d2c10b ("media: i2c: cvs: Add driver of Intel Computer Vision
Sensing Controller(CVS)"). It matches INTC10DE/E0/E1/FA, registers an
"Intel CVS" MEDIA_ENT_F_VID_IF_BRIDGE subdev with sink and source
pads, parses the port 0/1 endpoints ipu-bridge puts on the CVS node
and binds the sensor through an async notifier (v4l2.c,
cvs_csi_parse_firmware()), then calls acpi_dev_clear_dependencies()
at the end of probe (core.c). That is the device c6b1b34b5090 and
c28527ce5d06 are written against.

Its module is also called intel_cvs. A vision-drivers DKMS build
installs under updates/, which depmod searches before kernel/, so a
CONFIG_VIDEO_INTEL_CVS=m kernel still binds the vendor module.
modinfo -F filename intel_cvs shows which one you have; with the DKMS
package removed the graph ends at a device that registers the
endpoint. Not tested on a DA16260 here.

> Gating on a bound driver would also cover the ACPI half of the same
> conversion, c28527ce5d06, where a dependency on an unclaimed supplier
> blocks enumeration outright - kernel bugzilla 221988.

With the in-tree driver built, both gates pass. Kernels that carry
the 7.2 bridge without CONFIG_VIDEO_INTEL_CVS are the bugzilla 221988
case; Fedora has it enabled since 7.1.13-200. Whether the CVS entries
in acpi_honor_dep_ids[] and ivsc_acpi_ids[] should sit under
IS_ENABLED(CONFIG_VIDEO_INTEL_CVS) instead is Sakari's and Rafael's
call.

One more check on the DA16260 while intel_cvs is bound: the in-tree
driver requests its wake GPIO, and on the XPS 14 DA14260 that line is
the CS35L57 amplifiers' speaker-ID input, so all four amps fail probe
with -EBUSY and the machine has no sound (three Fedora reports,
https://bugzilla.redhat.com/show_bug.cgi?id=2529031). If
dmesg | grep spk-id shows the same on the XPS 16, the fix is

  https://lore.kernel.org/r/20260908105717.496232-1-junjie.cao@intel.com