Hi All, Background / analysis: ---------------------- 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@xxxxxxxxxx/ 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. Proposed solution: ------------------ I have been thinking about how to solve this without needing to modify sensor drivers. I think the best solution is to model the handshake pin as a GPIO driven "dvdd" regulator, configuring a 25 ms delay on enable by setting regulator_desc.enable_time to 25 ms. The reasons for modelling this as a regulator are 3 fold: 1. sensor chips don't have a handshake pin, so we need to abstract this in some way which does not require modification to the sensor drivers, sensor drivers using the bulk-regulator API to get avdd + vddio + dvdd is normal. So this will work to get the right value set to the handshake pin without requiring sensor driver modifications. 2. sensors typically wait only a small time for the sensor to power-on after de-asserting reset. Not the 25ms the Lattice chip requires according to the out-of-tree drivers. Using the regulator framework's enable_time allows hiding the need for this delay from the sensor drivers. 3. Looking at the out of tree drivers from: https://github.com/intel/ipu6-drivers/tree/master/drivers/media/i2c They set the handshake line before de-asserting reset and sensor. Drivers should normally enable regulators before de-asserting reset, so using a regulator will mirror the order the out of tree drivers use. Except that they do the 25 ms delay after setting both GPIOs, arguably doing the delay to let whatever magic the handshake signal does happen before de-asserting reset is better though. (also it seems with the exception of the pre Meteor Lake HP models where handshake appears to be unused that either reset or handshake is used and not both) Please let me know what you think of this proposal. If there are no objections then I will start working on implementing this soon. Regards, Hans
