[PATCH 0/3] Enable the front camera on the Dell Latitude 7320 Detachable

[PATCH 0/3] Enable the front camera on the Dell Latitude 7320 Detachable

[Sahan Nissanka]

This series enables the user-facing 5MP camera on the Dell Latitude 7320
Detachable, which has never worked on Linux. Two open reports ask for it:
intel/ipu6-drivers issues #24 (2022) and #402 (2025), the latter blocked
waiting for "OV5678 sensor specifications (clock rates, power requirements)".

Those specifications turned out not to be needed. ACPI describes the front
sensor as OVTI5678 and no driver has ever claimed that id. The part reports
chip id 0x005675 at register 0x300a, and the values ov5675.c is sensitive to
were read from the machine's ACPI SSDB before the sensor was ever powered and
both agree - 2 CSI-2 data lanes and a 19.2 MHz external clock. The advertised
5MP also matches the driver's native 2592x1944. So no new sensor driver and no
new register tables are required to make it stream.

One caveat, set out in full in 2/3: this part is not a plain Bayer sensor. It
carries a 4x4 RGB-IR colour filter array, one pixel in four being infrared.
That is confirmed from Intel's own Windows IPU6 configuration for this exact
module, from measurements on the sensor at full resolution, and from the
module's tuning data, which agree with each other. The SGRBG10 that ov5675
declares is therefore inaccurate, and colour is wrong in a way white balance
cannot correct.

That cannot be fixed in this series: the V4L2 ABI has no RGB-IR media bus
code at all, and ox05b1s already carries the same inaccuracy for an RGB-IR
sensor of the same class and resolution. I intend to propose RGB-IR media bus
codes separately. Until such support exists, this series takes hardware that
does not work at all to hardware that works with imperfect colour, which
seemed worth having in the meantime. I am happy to hold 2/3 if maintainers
would rather not add the id before the format can be described honestly.

That leaves three small pieces:

  1/3 gives the TPS68470 PMIC board data, without which the sensors are not
      even enumerated - they declare an ACPI _DEP on the control logic, so no
      i2c client is created until it probes.
  2/3 adds the OVTI5678 id to ov5675.
  3/3 adds the ipu-bridge entry so a software node is created for it.

The patches touch two subsystems: 1/3 is platform-driver-x86, 2/3 and 3/3 are
media. They are independent of each other in build terms, but none of them
does anything useful alone, so they are sent together for context. Happy to
split them if maintainers prefer.

Tested on a Dell Latitude 7320 Detachable, BIOS 1.48.0, kernel 7.0.0. With
all three applied:

  intel-ipu6 0000:00:05.0: Found supported sensor OVTI5678:00
  intel-ipu6 0000:00:05.0: Found supported sensor OVTI8856:00
  intel-ipu6 0000:00:05.0: Connected 2 cameras
  ov5675 1-0036: ... appears in the media graph

and libcamera captures 2584x1944 at 29.95 fps.

The rear OVTI8856 sensor shares the same PMIC. Its rails are described by the
same board data, but its reset/powerdown GPIO assignment is not yet known, so
it is deliberately left out here.

Sahan Nissanka (3):
  platform/x86: int3472: Add TPS68470 board data for Dell 7320
    Detachable
  media: i2c: ov5675: Add OVTI5678 ACPI id
  media: ipu-bridge: Add sensor configuration for OV5675 (OVTI5678)

 drivers/media/i2c/ov5675.c                    | 11 ++
 drivers/media/pci/intel/ipu-bridge.c          |  2 +
 .../x86/intel/int3472/tps68470_board_data.c   | 92 +++++++++++++++++++
 3 files changed, 105 insertions(+)

-- 
2.53.0

[PATCH 1/3] platform/x86: int3472: Add TPS68470 board data for Dell 7320 Detachable

[Sahan Nissanka]

The Dell Latitude 7320 Detachable has two MIPI cameras behind an Intel
IPU6, both powered by a TPS68470 PMIC. Without board data the PMIC
driver fails:

  int3472-tps68470 i2c-INT3472:07: error -ENODEV: No board-data found
  for this model

and because the sensors declare an ACPI _DEP on the control logic they
are never enumerated at all - no i2c client is created for either of
them, so nothing can bind them.

Add board data for the front sensor, which ACPI describes as OVTI5678.
The GPIO and rail assignments are the same as on the Dell 7212 and the
Dell 5290 2-in-1: reset on tps68470-gpio 3, powerdown on 4, and
VSIO/AUX1/AUX2 feeding avdd/dvdd/dovdd. This was confirmed on the
hardware - with these settings the sensor powers up and acknowledges on
i2c, and with the conventional ANA/CORE/VSIO mapping it does not. The
CLDB buffer read from this machine also carries C0W4=3, agreeing with
reset on GPIO 3.

The rails that have no consumers are wired as on the Dell 7212, so reuse
those regulator_init_data rather than duplicating them.

Note the control logic here enumerates as INT3472:07, not :05 as on the
other Dell models in this file. The board data lookup matches on DMI and
device name, so this has to be exact.

The rear OVTI8856 sensor shares this PMIC but its GPIO assignment is not
yet known, so it is left out for now.

Signed-off-by: Sahan Nissanka <adee.sahan@gmail.com>
---
 .../x86/intel/int3472/tps68470_board_data.c   | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
index 71357a0..f32a884 100644
--- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
+++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
@@ -232,6 +232,69 @@ static const struct tps68470_regulator_platform_data dell_7212_tps68470_pdata =
 	},
 };
 
+/* Settings for Dell Latitude 7320 Detachable */
+
+static struct regulator_consumer_supply ovti5678_vsio_consumer_supplies[] = {
+	REGULATOR_SUPPLY("avdd", "i2c-OVTI5678:00"),
+};
+
+static struct regulator_consumer_supply ovti5678_aux1_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dvdd", "i2c-OVTI5678:00"),
+};
+
+static struct regulator_consumer_supply ovti5678_aux2_consumer_supplies[] = {
+	REGULATOR_SUPPLY("dovdd", "i2c-OVTI5678:00"),
+};
+
+static const struct regulator_init_data dell_7320_tps68470_vsio_reg_init_data = {
+	.constraints = {
+		.min_uV = 1800600,
+		.max_uV = 1800600,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(ovti5678_vsio_consumer_supplies),
+	.consumer_supplies = ovti5678_vsio_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_7320_tps68470_aux1_reg_init_data = {
+	.constraints = {
+		.min_uV = 1213200,
+		.max_uV = 1213200,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(ovti5678_aux1_consumer_supplies),
+	.consumer_supplies = ovti5678_aux1_consumer_supplies,
+};
+
+static const struct regulator_init_data dell_7320_tps68470_aux2_reg_init_data = {
+	.constraints = {
+		.min_uV = 1800600,
+		.max_uV = 1800600,
+		.apply_uV = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(ovti5678_aux2_consumer_supplies),
+	.consumer_supplies = ovti5678_aux2_consumer_supplies,
+};
+
+/*
+ * The rails without consumers are wired the same way as on the Dell 7212, so
+ * reuse those init_data rather than duplicating them.
+ */
+static const struct tps68470_regulator_platform_data dell_7320_tps68470_pdata = {
+	.reg_init_data = {
+		[TPS68470_CORE] = &dell_7212_tps68470_core_reg_init_data,
+		[TPS68470_ANA]  = &dell_7212_tps68470_ana_reg_init_data,
+		[TPS68470_VCM]  = &dell_7212_tps68470_vcm_reg_init_data,
+		[TPS68470_VIO]  = &dell_7212_tps68470_vio_reg_init_data,
+		[TPS68470_VSIO] = &dell_7320_tps68470_vsio_reg_init_data,
+		[TPS68470_AUX1] = &dell_7320_tps68470_aux1_reg_init_data,
+		[TPS68470_AUX2] = &dell_7320_tps68470_aux2_reg_init_data,
+	},
+};
+
 static struct gpiod_lookup_table surface_go_int347a_gpios = {
 	.dev_id = "i2c-INT347A:00",
 	.table = {
@@ -258,6 +321,15 @@ static struct gpiod_lookup_table dell_7212_int3479_gpios = {
 	}
 };
 
+static struct gpiod_lookup_table dell_7320_ovti5678_gpios = {
+	.dev_id = "i2c-OVTI5678:00",
+	.table = {
+		GPIO_LOOKUP("tps68470-gpio", 3, "reset", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("tps68470-gpio", 4, "powerdown", GPIO_ACTIVE_LOW),
+		{ }
+	}
+};
+
 static const struct int3472_tps68470_board_data surface_go_tps68470_board_data = {
 	.dev_name = "i2c-INT3472:05",
 	.tps68470_regulator_pdata = &surface_go_tps68470_pdata,
@@ -287,6 +359,19 @@ static const struct int3472_tps68470_board_data dell_7212_tps68470_board_data =
 	},
 };
 
+/*
+ * The control logic on the Latitude 7320 Detachable enumerates as INT3472:07,
+ * not :05 as on the other Dell models here.
+ */
+static const struct int3472_tps68470_board_data dell_7320_tps68470_board_data = {
+	.dev_name = "i2c-INT3472:07",
+	.tps68470_regulator_pdata = &dell_7320_tps68470_pdata,
+	.n_gpiod_lookups = 1,
+	.tps68470_gpio_lookup_tables = {
+		&dell_7320_ovti5678_gpios,
+	},
+};
+
 static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
 	{
 		.matches = {
@@ -316,6 +401,13 @@ static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
 		},
 		.driver_data = (void *)&dell_7212_tps68470_board_data,
 	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 7320 Detachable"),
+		},
+		.driver_data = (void *)&dell_7320_tps68470_board_data,
+	},
 	{ }
 };
 
-- 
2.53.0

Re: [PATCH 1/3] platform/x86: int3472: Add TPS68470 board data for Dell 7320 Detachable

[Sahan Nissanka]

Please do not apply this patch. The GPIO mapping in it is wrong, and I would
rather say so than have it land.

Charles Drolet, who has the same machine, reported against my out-of-tree
repository [1] that the front sensor probes with no pin assignment at all.
That is why a wrong mapping is invisible here: the real reset line sits
released by default, so the camera comes up either way. Two specifics.

There is no powerdown pin. This part needs no hardware to confirm - ov5675.c
requests only "reset", via devm_gpiod_get_optional(dev, "reset", ...), and no
"powerdown" con_id exists anywhere in that driver. So

	GPIO_LOOKUP("tps68470-gpio", 4, "powerdown", GPIO_ACTIVE_LOW),

is never looked up. It is dead code, and my belief that the pin was needed was
unfounded.

The reset is on tps68470-gpio 5, not 3. Charles held the line with gpioset
against a build with no pin assignment, so nothing else had claimed it, and
reloaded the module: held low the sensor fails to identify with -EIO, released
it identifies correctly. That is consistent with an active-low reset on line
5. I have not reproduced this myself yet.

I should also correct how I arrived at 3 and 4. I took them from the Dell 7212
and 5290 board data as prior art, and treated "the camera works" as
confirmation. It is not. It confirms the sensor runs; it says nothing about
whether the mapping describes this board.

The rail mapping may need revisiting too. Charles has avdd on AUX1 at 2.8 V
where this patch has it on VSIO at 1.8 V, and the part wants roughly 2.8 V
analogue. Both configurations work, which suggests these rails may serve as
enables for regulators further down the line rather than as the supplies
themselves. I would rather resolve that than guess again.

The machine this work was done on was a loan and has gone back. A second 7320
Detachable arrives in the next few days, and I will verify the mapping on it
before sending a v2 - including checking whether the board data generalises
across units or merely described the one I had.

Patches 2/3 and 3/3 are not affected by any of this. Charles independently
arrived at the same ipu-bridge entry and the same ACPI id addition.

My thanks to Charles for finding this and for testing it properly.

[1] https://github.com/githomeserver/latitude-7320-camera/issues/1

--
Sahan Nissanka

[PATCH 2/3] media: i2c: ov5675: Add OVTI5678 ACPI id

[Sahan Nissanka]

The front camera of the Dell Latitude 7320 Detachable is described in
ACPI as OVTI5678, and no driver has ever claimed that id. It reports
chip id 0x005675 at register 0x300a, which is what
ov5675_identify_module() expects, and it streams with this driver
unmodified:

  ov5675 i2c-OVTI5678:00: chip id at 0x300a reads 0x005675
    reg 0x300a = 0x00  reg 0x300b = 0x56  reg 0x300c = 0x75

The two other values this driver is sensitive to were read from the
machine's ACPI SSDB before the sensor was ever powered, and both agree:
L0NL = 2 data lanes (OV5675_DATA_LANES) and L0CK = 19200000 Hz
(OV5675_XVCLK_19_2). Native resolution matches at 2592x1944.

With this id added the sensor binds and streams: libcamera lists it and
capture runs at 2584x1944, 29.95 fps.

This part is not a plain Bayer sensor, however, and the format this
driver declares for it is inaccurate. It carries a 4x4 RGB-IR colour
filter array, one pixel in four being infrared:

    G I G I
    R G B G
    G I G I
    B G R G

Confirmed three ways. Intel's Windows IPU6 configuration for this exact
module - matched by ACPI _DDN, so not a near relative - declares
bayer_order="GIGI_RGBG_GIGI_BGRG" and sensor_type="RGB_IR". Measured on
the sensor at full resolution, positions a 2x2 model treats as a single
channel differ by 18% while the four infrared positions agree to 0.4%.
And the module's Intel tuning data carries a 4x4 channel index map that
agrees with both.

Read as the SGRBG10 declared here, the "blue" channel is pure infrared
and the "red" channel interleaves real red with real blue, so colour is
wrong in a way no white balance can correct.

This cannot be fixed in this driver: there is no RGB-IR media bus code
in the V4L2 ABI. Nor is it unique to this part - ox05b1s declares
SGRBG10 for an RGB-IR sensor of the same class and resolution. I intend
to propose RGB-IR media bus codes separately. Until such support
exists, this patch makes otherwise unusable hardware work, carrying the
same known inaccuracy as the existing RGB-IR sensor support.

One further note for anyone building on this: the sensor's binned
1296x972 mode averages infrared pixels together with colour ones, which
destroys the mosaic. Only the full resolution mode is meaningful for an
RGB-IR aware pipeline.

Signed-off-by: Sahan Nissanka <adee.sahan@gmail.com>
---
 drivers/media/i2c/ov5675.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/media/i2c/ov5675.c b/drivers/media/i2c/ov5675.c
index ea26df3..99dbf53 100644
--- a/drivers/media/i2c/ov5675.c
+++ b/drivers/media/i2c/ov5675.c
@@ -1355,6 +1355,17 @@ static const struct dev_pm_ops ov5675_pm_ops = {
 #ifdef CONFIG_ACPI
 static const struct acpi_device_id ov5675_acpi_ids[] = {
 	{"OVTI5675"},
+	/*
+	 * The front sensor of the Dell Latitude 7320 Detachable is described
+	 * as OVTI5678 in ACPI, but the part reports chip id 0x005675 and its
+	 * SSDB agrees with this driver on both other values that matter:
+	 * 2 CSI-2 data lanes and a 19.2 MHz external clock.
+	 *
+	 * Note this variant carries a 4x4 RGB-IR colour filter array, not the
+	 * 2x2 Bayer declared here, so colour is incorrect. There is currently
+	 * no RGB-IR media bus code to declare instead.
+	 */
+	{"OVTI5678"},
 	{}
 };
 
-- 
2.53.0

Re: [PATCH 2/3] media: i2c: ov5675: Add OVTI5678 ACPI id

[Sakari Ailus]

Hi Sahan,

Thank you for the patchset.

On Sun, Aug 09, 2026 at 02:25:18PM +1000, Sahan Nissanka wrote:
> The front camera of the Dell Latitude 7320 Detachable is described in
> ACPI as OVTI5678, and no driver has ever claimed that id. It reports
> chip id 0x005675 at register 0x300a, which is what
> ov5675_identify_module() expects, and it streams with this driver
> unmodified:
> 
>   ov5675 i2c-OVTI5678:00: chip id at 0x300a reads 0x005675
>     reg 0x300a = 0x00  reg 0x300b = 0x56  reg 0x300c = 0x75
> 
> The two other values this driver is sensitive to were read from the
> machine's ACPI SSDB before the sensor was ever powered, and both agree:
> L0NL = 2 data lanes (OV5675_DATA_LANES) and L0CK = 19200000 Hz
> (OV5675_XVCLK_19_2). Native resolution matches at 2592x1944.
> 
> With this id added the sensor binds and streams: libcamera lists it and
> capture runs at 2584x1944, 29.95 fps.
> 
> This part is not a plain Bayer sensor, however, and the format this
> driver declares for it is inaccurate. It carries a 4x4 RGB-IR colour
> filter array, one pixel in four being infrared:
> 
>     G I G I
>     R G B G
>     G I G I
>     B G R G

Most non-Bayer colour raw sensors can be programmed to produce Bayer
output. It'd be interesting to know what are the differences in register
writes compared to the Windows driver -- it might use that feature.

> 
> Confirmed three ways. Intel's Windows IPU6 configuration for this exact
> module - matched by ACPI _DDN, so not a near relative - declares
> bayer_order="GIGI_RGBG_GIGI_BGRG" and sensor_type="RGB_IR". Measured on
> the sensor at full resolution, positions a 2x2 model treats as a single
> channel differ by 18% while the four infrared positions agree to 0.4%.
> And the module's Intel tuning data carries a 4x4 channel index map that
> agrees with both.
> 
> Read as the SGRBG10 declared here, the "blue" channel is pure infrared
> and the "red" channel interleaves real red with real blue, so colour is
> wrong in a way no white balance can correct.
> 
> This cannot be fixed in this driver: there is no RGB-IR media bus code
> in the V4L2 ABI. Nor is it unique to this part - ox05b1s declares
> SGRBG10 for an RGB-IR sensor of the same class and resolution. I intend
> to propose RGB-IR media bus codes separately. Until such support
> exists, this patch makes otherwise unusable hardware work, carrying the
> same known inaccuracy as the existing RGB-IR sensor support.
> 
> One further note for anyone building on this: the sensor's binned
> 1296x972 mode averages infrared pixels together with colour ones, which
> destroys the mosaic. Only the full resolution mode is meaningful for an
> RGB-IR aware pipeline.

The metadata series I've been preparing adds common raw formats and moves
the CFA pattern to a control. Then we can add the non-Bayer patters to the
UAPI as well. This isn't in upstream yet though. See
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=metadata>.

Most of the commit message would seem to be better located in the cover
letter.

> 
> Signed-off-by: Sahan Nissanka <adee.sahan@gmail.com>
> ---
>  drivers/media/i2c/ov5675.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov5675.c b/drivers/media/i2c/ov5675.c
> index ea26df3..99dbf53 100644
> --- a/drivers/media/i2c/ov5675.c
> +++ b/drivers/media/i2c/ov5675.c
> @@ -1355,6 +1355,17 @@ static const struct dev_pm_ops ov5675_pm_ops = {
>  #ifdef CONFIG_ACPI
>  static const struct acpi_device_id ov5675_acpi_ids[] = {
>  	{"OVTI5675"},
> +	/*
> +	 * The front sensor of the Dell Latitude 7320 Detachable is described
> +	 * as OVTI5678 in ACPI, but the part reports chip id 0x005675 and its
> +	 * SSDB agrees with this driver on both other values that matter:
> +	 * 2 CSI-2 data lanes and a 19.2 MHz external clock.
> +	 *
> +	 * Note this variant carries a 4x4 RGB-IR colour filter array, not the
> +	 * 2x2 Bayer declared here, so colour is incorrect. There is currently
> +	 * no RGB-IR media bus code to declare instead.
> +	 */

Given the similarities, adding ov5678 support to this driver would probably
make sense, but the output really should be Bayer or we need to wait for
the metadata series to be merged.

> +	{"OVTI5678"},
>  	{}
>  };
>  

-- 
Kind regards,

Sakari Ailus

Re: [PATCH 2/3] media: i2c: ov5675: Add OVTI5678 ACPI id

[Sahan Nissanka]

Hi Sakari,

Thank you for the review.

> Most non-Bayer colour raw sensors can be programmed to produce Bayer
> output. It'd be interesting to know what are the differences in register
> writes compared to the Windows driver -- it might use that feature.

I have not captured the Windows driver's register writes, so I cannot answer
that directly. What I do have is Intel's shipped configuration for this exact
module, and all of it points the other way: their stack appears to take RGB-IR
from the sensor and convert it downstream rather than ask the sensor for
Bayer.

  - iacamera64.sys documents an IPU6 hardware block named x2b_rgbir, 314
    registers, i.e. RGB-IR to Bayer conversion in the IPU6 itself.

  - graph_settings_OV5678_0BF501T3_TGL.xml, tied to this module by ACPI _DDN
    rather than to a near relative, declares sensor_type="RGB_IR" and
    bayer_order="GIGI_RGBG_GIGI_BGRG". The rear OV8856 on the same machine
    declares plain GRBG, which makes a useful control.

  - The module's tuning file carries a lens shading record whose 4x4 channel
    index map has five channels, two greens tracked separately plus IR,
    against four on the rear sensor.

  - Intel lists exactly one mode for this part, 2592x1944, where the Bayer
    OV8856 gets several.

If the part could be told to emit Bayer, that hardware block and that tuning
would not be needed for this module. But that is an argument about what Intel
chose to do, not proof about what the sensor can do. I have no register-level
documentation for this variant, and the OV5675 documentation I do have does
not describe an RGB-IR part at all.

Since posting, another person working on this hardware extracted and shared
Intel's Windows sensor driver for this part - ov5678.sys, an ACPI\OVTI5678
KMDF driver - so I went looking for the register writes directly. They are not
in it: the driver carries no sensor initialisation tables, and instead reads
external configuration through an ExtFilesPath value under its service key,
from a BSPDRIVERS store. So the Windows driver binary does not settle your
question either, and I would rather say so than imply I have checked something
I have not.

It does suggest a cleaner way to answer it than sniffing the bus. The driver
has a register-dump facility of its own, writing to C:\OV5678reg.txt, and a
matching NVM dump for the module EEPROM. If the replacement machine arrives
with the factory Windows image, letting Windows bring the camera up and then
dumping the sensor's register state gives a direct comparison against the
tables in ov5675.c, using Intel's own tooling rather than my inference. If
there is a mode bit that switches the output to Bayer, that is where it should
appear. I will report either way, including if it turns out I cannot get at
it.

> The metadata series I've been preparing adds common raw formats and moves
> the CFA pattern to a control. Then we can add the non-Bayer patters to the
> UAPI as well. This isn't in upstream yet though. See
> <URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=metadata>.

That is good to know, and it changes my plans usefully. I had started drafting
an RFC proposing RGB-IR media bus codes; I will drop that rather than propose
a competing mechanism, and follow your branch instead. The CFA pattern as a
control looks like the better model for this - a 4x4 pattern does not reduce
to a Bayer order, so new bus codes would have multiplied awkwardly.

Two questions, then, on how you would like to proceed.

Would you prefer this patch waits for the metadata series to land, and returns
as part of describing the sensor honestly? I am content to hold it. The
practical cost is that the front camera stays dead on this machine in the
meantime, which is what prompted the patch, but that is not an argument for
merging something inaccurate.

And how should I read the precedent in ox05b1s? It declares SGRBG10 for an
RGB-IR sensor of this same class and resolution, which is what I was following
here. If that is regarded as a mistake not to repeat, I would rather know now
and wait than argue from it.

> Most of the commit message would seem to be better located in the cover
> letter.

Agreed - I will move it in v2.

One other thing you should know, since it affects the series rather than this
patch. I have asked that 1/3 not be applied: an owner of the same machine has
shown the GPIO mapping in it is wrong, and that the sensor probes with no pin
assignment at all, so my "it works" was never evidence that the mapping was
right. I will verify the corrected mapping on the replacement machine before
sending v2. Patch 3/3 is unaffected, and was independently arrived at by the
same person.

--
Sahan Nissanka

[PATCH 3/3] media: ipu-bridge: Add sensor configuration for OV5675 (OVTI5678)

[Sahan Nissanka]

The front camera of the Dell Latitude 7320 Detachable is an OV5675
described in ACPI as OVTI5678. Without an entry here ipu-bridge creates
no software node for it, so no fwnode endpoint exists and the sensor
cannot be connected to the IPU6 even once a driver binds it:

  intel-ipu6 0000:00:05.0: Found supported sensor OVTI8856:00
  intel-ipu6 0000:00:05.0: Connected 1 cameras

450 MHz is OV5675_LINK_FREQ_450MHZ, the only link frequency ov5675.c
supports, and matches the two data lanes the machine's SSDB reports.

With this entry both cameras are found and the front sensor appears in
the media graph:

  intel-ipu6 0000:00:05.0: Found supported sensor OVTI5678:00
  intel-ipu6 0000:00:05.0: Found supported sensor OVTI8856:00
  intel-ipu6 0000:00:05.0: Connected 2 cameras

Signed-off-by: Sahan Nissanka <adee.sahan@gmail.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 9cebc6a..78fe1f7 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -101,6 +101,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 OV5675, described as OVTI5678 in ACPI */
+	IPU_SENSOR_CONFIG("OVTI5678", 1, 450000000),
 	/* Omnivision OV8856 */
 	IPU_SENSOR_CONFIG("OVTI8856", 3, 180000000, 360000000, 720000000),
 	/* Sony IMX471 */
-- 
2.53.0