[PATCH v2 0/4] Lenovo ThinkPad X1 Carbon Gen 14 IR camera: ST VD55G1 on Intel IPU7

[PATCH v2 0/4] Lenovo ThinkPad X1 Carbon Gen 14 IR camera: ST VD55G1 on Intel IPU7

[Ruslan Koreev]

The ThinkPad X1 Carbon Gen 14 (Panther Lake, Intel IPU7) has a second
MIPI camera for Windows Hello: an ST VD55G1 monochrome global-shutter
sensor, enumerated by ACPI as TBE20A1, with one CSI-2 lane. It is
powered through an INT3472 discrete device that provides a power enable
GPIO, a reset GPIO, a privacy LED and a 19.2 MHz clock. Only the analog
supply has a GPIO; vcore and vddio fall back to dummy regulators. The
RGB camera of the same laptop (Sony IMX471, TBE20A0) is already
supported.

Patch 1 maps the INT3472 power enable GPIO to the supply name the
vd55g1 driver expects, patch 2 adds the ipu-bridge entry, patch 3 lets
the vd55g1 driver defer its probe while the bridge has not attached the
CSI-2 endpoint yet, and patch 4 adds the ACPI match.

Tested on next-20260924 with the ipu6 driver handling the IPU7: the
sensor probes, ipu-bridge connects both cameras, libcamera streams Y8
804x704 at 58 fps, Y10 and Y10P stream with plain V4L2, and with the IR
illuminator on the frames are good enough for face authentication with
howdy.

About the privacy LED Benjamin mentioned on v1: the V4L2 core switches
it when streaming starts and stops, not when the sensor is powered, so
powering up at probe does not light it. vd55g1 does not hand the LED to
the core yet, as it registers with v4l2_async_register_subdev() rather
than v4l2_async_register_subdev_sensor(), so for now the LED also stays
off while streaming. I can send that change as a separate patch.

Peter Marshall's VD55G0 series (linux-media, September 2026) adds the
SMO55F0 HID to the same ipu-bridge and INT3472 tables, so whichever
series lands second needs a trivial rebase.

Changes in v2:
- Dropped the staging ipu7 patch: the ipu6 driver, which takes over
  IPU7, already has the monochrome formats (Sakari).
- Split the vd55g1 change in two and let vd55g1_check_csi_conf()
  return the endpoint parser's error code instead of checking the
  endpoint beforehand (Sakari).
- Trimmed the commit messages, moved the hardware description here and
  dropped the comment above the ACPI table (Sakari).
- Added Benjamin's Acked-by to patches 1 and 2.
- Rebased on media-committers next.

v1: https://lore.kernel.org/linux-media/20260924171820.1179823-1-koreev.r@gmail.com/

Ruslan Koreev (4):
  platform/x86: int3472: Map the VD55G1 power enable GPIO to "vana"
  media: ipu-bridge: Add the ST VD55G1 (TBE20A1)
  media: i2c: vd55g1: Return the endpoint parser's error code
  media: i2c: vd55g1: Add ACPI support

 drivers/media/i2c/vd55g1.c                    | 14 ++++++++------
 drivers/media/pci/intel/ipu-bridge.c          |  2 ++
 drivers/platform/x86/intel/int3472/discrete.c |  1 +
 3 files changed, 11 insertions(+), 6 deletions(-)


base-commit: 58348f64125e9a3e44d3abb275ca7f4e6c9641e5
-- 
2.55.0

[PATCH v2 1/4] platform/x86: int3472: Map the VD55G1 power enable GPIO to "vana"

[Ruslan Koreev]

The ST VD55G1 IR camera of the Lenovo ThinkPad X1 Carbon Gen 14 (ACPI
HID TBE20A1) gets its analog supply from the power enable GPIO of an
INT3472 discrete device. Map that GPIO to "vana", the supply name the
vd55g1 driver uses, as is already done for the imx471 on the same
laptop.

Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>
Acked-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
---
 drivers/platform/x86/intel/int3472/discrete.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index b48cf1b7f..b19ea6ee3 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -131,6 +131,7 @@ skl_int3472_gpiod_get_from_temp_lookup(struct int3472_discrete_device *int3472,
 static const char * const power_enable_hids_vana[] = {
 	"SONY471A", /* imx471 on Lenovo X9-14 and X9-15 */
 	"TBE20A0", /* imx471 on Lenovo X1 Carbon G14 */
+	"TBE20A1", /* vd55g1 on Lenovo X1 Carbon G14 */
 	NULL
 };
 
-- 
2.55.0

[PATCH v2 2/4] media: ipu-bridge: Add the ST VD55G1 (TBE20A1)

[Ruslan Koreev]

Add the ACPI HID Lenovo uses for the ST VD55G1 IR camera of the ThinkPad
X1 Carbon Gen 14. The firmware describes one CSI-2 data lane and, as
usual, no link frequency, so the value has to come from this table; the
vd55g1 driver requires exactly one.

Use 402 MHz (804 Mbps). The sensor derives its MIPI rate and clock tree
from this value and the IPU7 CSI-2 receiver reads the same value back
through V4L2_CID_LINK_FREQ, so both ends agree by construction. At
804 Mbps a full-width 10-bit line takes about 11 us on the link, which
allows well over 100 fps at full resolution; lower rates lengthen every
line proportionally. The rate is in the lower half of the 250 to
1200 Mbps range the sensor supports and is the one validated on the
hardware, where 804x704 streams at 58 fps.

Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>
Acked-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
---
 drivers/media/pci/intel/ipu-bridge.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index e476e269a..8bd200896 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -122,6 +122,8 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
 	IPU_SENSOR_CONFIG("SONY471A", 1, 200000000),
 	/* Sony IMX471 (found on Lenovo X1 Carbon G14) */
 	IPU_SENSOR_CONFIG("TBE20A0", 1, 200000000),
+	/* STMicroelectronics VD55G1 (found on Lenovo X1 Carbon G14) */
+	IPU_SENSOR_CONFIG("TBE20A1", 1, 402000000),
 	/* Toshiba T4KA3 */
 	IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000),
 };
-- 
2.55.0

[PATCH v2 3/4] media: i2c: vd55g1: Return the endpoint parser's error code

[Ruslan Koreev]

Pass the endpoint to v4l2_fwnode_endpoint_alloc_parse() without checking
it first and return the parser's error code instead of -EINVAL. The
parser returns -EPROBE_DEFER for a missing endpoint, which is what a
sensor on an ACPI system needs: there the endpoint is a software node
that the IPU bridge attaches when the IPU driver probes, possibly after
this driver. On OF systems a missing endpoint now defers the probe as
well instead of failing it, as in other sensor drivers that leave this
check to the parser.

Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>
---
 drivers/media/i2c/vd55g1.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
index 22b1497e8..8043eaa50 100644
--- a/drivers/media/i2c/vd55g1.c
+++ b/drivers/media/i2c/vd55g1.c
@@ -1801,7 +1801,7 @@ static int vd55g1_check_csi_conf(struct vd55g1 *sensor,
 
 	ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &ep);
 	if (ret)
-		return -EINVAL;
+		return ret;
 
 	/* Check lanes number */
 	n_lanes = ep.bus.mipi_csi2.num_data_lanes;
@@ -1905,11 +1905,6 @@ static int vd55g1_parse_dt(struct vd55g1 *sensor)
 
 	endpoint = fwnode_graph_get_endpoint_by_id(dev_fwnode(sensor->dev),
 						   0, 0, 0);
-	if (!endpoint) {
-		dev_err(sensor->dev, "Endpoint node not found\n");
-		return -EINVAL;
-	}
-
 	ret = vd55g1_check_csi_conf(sensor, endpoint);
 	fwnode_handle_put(endpoint);
 	if (ret)
-- 
2.55.0

[PATCH v2 4/4] media: i2c: vd55g1: Add ACPI support

[Ruslan Koreev]

Add an ACPI match table with the TBE20A1 HID that Lenovo uses for the
VD55G1, with the same match data as the st,vd55g1 compatible.

Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>
---
 drivers/media/i2c/vd55g1.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
index 8043eaa50..e3939bb9b 100644
--- a/drivers/media/i2c/vd55g1.c
+++ b/drivers/media/i2c/vd55g1.c
@@ -2081,6 +2081,12 @@ static const struct of_device_id vd55g1_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, vd55g1_dt_ids);
 
+static const struct acpi_device_id vd55g1_acpi_ids[] = {
+	{ .id = "TBE20A1", .driver_data = (kernel_ulong_t)&vd55g1_versions[0] },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, vd55g1_acpi_ids);
+
 static const struct dev_pm_ops vd55g1_pm_ops = {
 	SET_RUNTIME_PM_OPS(vd55g1_power_off, vd55g1_power_on, NULL)
 };
@@ -2089,6 +2095,7 @@ static struct i2c_driver vd55g1_i2c_driver = {
 	.driver = {
 		.name  = "vd55g1",
 		.of_match_table = vd55g1_dt_ids,
+		.acpi_match_table = vd55g1_acpi_ids,
 		.pm = &vd55g1_pm_ops,
 	},
 	.probe = vd55g1_probe,
-- 
2.55.0

Re: [PATCH v2 3/4] media: i2c: vd55g1: Return the endpoint parser's error code

[Benjamin Mugnier]

Hi Ruslan,

Le 29/09/2026 à 11:27, Ruslan Koreev a écrit :
> Pass the endpoint to v4l2_fwnode_endpoint_alloc_parse() without checking
> it first and return the parser's error code instead of -EINVAL. The
> parser returns -EPROBE_DEFER for a missing endpoint, which is what a
> sensor on an ACPI system needs: there the endpoint is a software node
> that the IPU bridge attaches when the IPU driver probes, possibly after
> this driver. On OF systems a missing endpoint now defers the probe as
> well instead of failing it, as in other sensor drivers that leave this
> check to the parser.
> 
> Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>

Reviewed-By: Benjamin Mugnier <benjamin.mugnier@foss.st.com>

> ---
>  drivers/media/i2c/vd55g1.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 22b1497e8..8043eaa50 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -1801,7 +1801,7 @@ static int vd55g1_check_csi_conf(struct vd55g1 *sensor,
>  
>  	ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &ep);
>  	if (ret)
> -		return -EINVAL;
> +		return ret;
>  
>  	/* Check lanes number */
>  	n_lanes = ep.bus.mipi_csi2.num_data_lanes;
> @@ -1905,11 +1905,6 @@ static int vd55g1_parse_dt(struct vd55g1 *sensor)
>  
>  	endpoint = fwnode_graph_get_endpoint_by_id(dev_fwnode(sensor->dev),
>  						   0, 0, 0);
> -	if (!endpoint) {
> -		dev_err(sensor->dev, "Endpoint node not found\n");
> -		return -EINVAL;
> -	}
> -
>  	ret = vd55g1_check_csi_conf(sensor, endpoint);
>  	fwnode_handle_put(endpoint);
>  	if (ret)

-- 
Regards,
Benjamin

Re: [PATCH v2 4/4] media: i2c: vd55g1: Add ACPI support

[Benjamin Mugnier]

Hi Ruslan,

Le 29/09/2026 à 11:27, Ruslan Koreev a écrit :
> Add an ACPI match table with the TBE20A1 HID that Lenovo uses for the
> VD55G1, with the same match data as the st,vd55g1 compatible.
> 
> Signed-off-by: Ruslan Koreev <koreev.r@gmail.com>

Again, can't test but :

Acked-By: Benjamin Mugnier <benjamin.mugnier@foss.st.com>

> ---
>  drivers/media/i2c/vd55g1.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 8043eaa50..e3939bb9b 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -2081,6 +2081,12 @@ static const struct of_device_id vd55g1_dt_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(of, vd55g1_dt_ids);
>  
> +static const struct acpi_device_id vd55g1_acpi_ids[] = {
> +	{ .id = "TBE20A1", .driver_data = (kernel_ulong_t)&vd55g1_versions[0] },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(acpi, vd55g1_acpi_ids);
> +
>  static const struct dev_pm_ops vd55g1_pm_ops = {
>  	SET_RUNTIME_PM_OPS(vd55g1_power_off, vd55g1_power_on, NULL)
>  };
> @@ -2089,6 +2095,7 @@ static struct i2c_driver vd55g1_i2c_driver = {
>  	.driver = {
>  		.name  = "vd55g1",
>  		.of_match_table = vd55g1_dt_ids,
> +		.acpi_match_table = vd55g1_acpi_ids,
>  		.pm = &vd55g1_pm_ops,
>  	},
>  	.probe = vd55g1_probe,

-- 
Regards,
Benjamin

Re: [PATCH v2 0/4] Lenovo ThinkPad X1 Carbon Gen 14 IR camera: ST VD55G1 on Intel IPU7

[Qiling Zhu]

Hi Ruslan,

I did some more testing and checked the saved logs from my original
next-20260928 tests. The VD55G1 failure appears to be intermittent.

Today I managed to boot the original next-20260928 + v1 patches 1-3
kernel into a state where the VD55G1 probed successfully again.
`cam -l` showed both cameras:

  1: Internal front camera (\_SB_.LNK0)
  2: Internal front camera (\_SB_.LNK1)

I then ran the libcamera test you provided:

  timeout 30 cam -c '\_SB_.LNK1' -C5 -s width=804,height=704

The camera was configured as 804x704 R8, but when capture started the
same I2C failure appeared:

  i2c_designware i2c_designware.1:
    i2c_dw_handle_tx_abort: lost arbitration
  i2c_designware i2c_designware.1: controller timed out
  vd55g1 i2c-TBE20A1:00: Sensor reset failed -110

The IPU6 ISYS path then reported stream stop/close timeouts and failed
to start Intel IPU6 CSI2 2 with -110.

I also checked my saved logs from the original testing. They contain
both successful and failed boots of the same kernel build and command
line.

In successful boots, the media graph contained:

  vd55g1 1-0010
    -> Intel IPU6 CSI2 2
    -> Intel IPU6 ISYS Capture 16
    -> /dev/video16

and /dev/video16 advertised GREY, Y10 and Y10P.

In failed boots, the sensor failed during probe with the same sequence:

  i2c_designware i2c_designware.1:
    i2c_dw_handle_tx_abort: lost arbitration
  i2c_designware i2c_designware.1: controller timed out
  vd55g1 i2c-TBE20A1:00: Sensor reset failed -110
  vd55g1 i2c-TBE20A1:00:
    probe with driver vd55g1 failed with error -110

This seems to explain my earlier results: sometimes the I2C failure
happens during probe, so LNK1 never appears; sometimes probe succeeds
and the media graph is created, but the same failure can occur later
when streaming starts.

I checked the basic sensor power sequence during failing probes:

  - INT3472:01-vana is enabled during probe
  - the active-low VD55G1 reset GPIO is deasserted
  - INT3472:01-clk is prepared/enabled at 19.2 MHz

The "Sensor reset failed" message above is reached while
vd55g1_wait_state() is polling the sensor over I2C after reset has
already been deasserted.

I also tried forcing i2c_designware.1 runtime PM to "on". In another
test I prevented vd55g1 from probing at boot, waited until the system
had been up for more than 10 seconds, and then loaded the module
manually. Neither changed the failure.

I rebuilt the saved next-20260928 + v1 patches 1-3 source tree and can
reproduce the problem there. I also see the same probe failure on
next-20261002 with the v2 changes already present in linux-next. So at
this point this does not look like a v1/v2 or
next-20260928/next-20261002 regression.

For completeness, I also ran into a separate intermittent boot hang in
thinkpad_acpi hotkey polling while doing these tests. Disabling
CONFIG_THINKPAD_ACPI_HOTKEY_POLL makes boot reliable, but does not fix
the VD55G1 I2C failure, so I currently believe the two issues are
unrelated.

Have you seen this intermittent arbitration loss on your X1 Carbon Gen
14, either during probe or when starting the VD55G1 stream? Is there
anything about the BIOS/firmware or I2C setup on your test machine that
would be useful for me to compare?

I have complete kernel logs from successful-probe, failed-probe, and
successful-probe/failed-stream boots, as well as the saved media
topology, if useful.

Thanks,
Qiling Zhu