Bug 2341731

New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12
pin defined in the INT3472 sensor companion device which describes
the sensor's GPIOs.

Based on what I know about this now, this pin seems to be used in at least
3 different scenarios:

1. To power-up / activate some unknown auxiliary IC on HP laptop designs
where the sensor is directly connected to the main Meteor Lake SoC for
I2C and GPIOs (no USB io-expander used). Example dyndbg int3472 output:

HP Spectre x360 2-in-1 Laptop 16t-aa000/8C17, BIOS F.11 08/14/2024 (ov08x40):
[    4.908016] int3472-discrete INT3472:01: unknown \_SB.GPI0 pin 65 active-high
[    4.908019] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work
[    4.908100] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high
(and lsusb shows no Lattice NX## / Synaptics Sabre USB-io expander)

2. To make the Lattice chip in designs with the Lattice chip is used run
the power-on sequence of the sensor which is handled by the Lattice chip
firmware itself running the entire power-on/-down sequence when changing
the GPIO value. Example dyndbg int3472 output:

Dell Latitude 7450 (with patch to map handshake in INT3472) (ov02e10):
[    5.110920] int3472-discrete INT3472:01: Sensor name OVTI02E1:00
[    5.111908] int3472-discrete INT3472:01: Sensor module id: 'CIFNE24'
[    5.113653] int3472-discrete INT3472:01: handshake \_SB.PC00.XHCI.RHUB.HS05.VGPO pin 0 active-high
[    5.113676] int3472-discrete INT3472:01: privacy-led \_SB.PC00.XHCI.RHUB.HS05.VGPO pin 2 active-high
(with 2ac1:20c9 Lattice NX33 USB IO-expander)

3. For unknown reason (ACPI table bug? / not actually used) there is
a handshake type pin in the INT3472 device on some older HP models with
a hi556 sensor connected directly to the Alder Lake or Raptor Lake SoC,
see e.g. the dmesg from: https://linux-hardware.org/?probe=a9a2e2ab03 :

[    9.077107] int3472-discrete INT3472:01: reset \_SB.GPI0 pin number mismatch _DSM 141 resource 301
[    9.077170] int3472-discrete INT3472:01: power-enable \_SB.GPI0 pin number mismatch _DSM 142 resource 302
[    9.086727] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work

which is from a model where it has been confirmed that the FOSS stack
works already even though we have no handshake GPIO support yet.

Testing has shown that for things to work in scenario 1. and 2. the 0x12 /
handshake type pin needs to be driven high, followed by a msleep of 25 ms.

The 25 ms was taken from the out of tree drivers which specify this as
minimum sleep for the Lattice case. For the HP without Lattice, the default
1 ms post reset delay also is not enough see:
https://lore.kernel.org/linux-media/1664997903.107383327.1734874558698.JavaMail.zimbra@chorus.net/

This applies to both the HP Spectre x360 16t without Lattice chip and
the Dell Latitude 7450 with Lattice chip.

I suspect that there might be some micro-controller or something running
the power-on sequence in the HP Spectre x360 16t case too, but there it
is just a standalone chip responding to the GPIO, not an USB attached chip
also offering, e.g. an I2C + GPIO controller like the Lattice chip.

A proposal to solve this is being discussed here:
https://lore.kernel.org/linux-media/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/

Reproducible: Always