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
I've just posted a series upstream which implements the suggested solution, waiting for testing now... : https://lore.kernel.org/platform-driver-x86/20250325161340.342192-1-hdegoede@redhat.com/
Has this landed yet on 6.14.4-300.fc42.x86_64 kernal? I have a HP Spectre x360 16 16-aa0023DX and I was wondering if the camera work is coming for this model?
Handshake GPIO support has now landed upstream: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next&id=c5d0393272048748ace2dd4ff8326fc0bf70b262 And I've backported this to the Fedora kernels starting with kernel-6.14.6-300.fc42. On laptop models where the following messages was shown in dmesg: [ 4.908019] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work with an otherwise supported camera-sensor (and if necessary the USBIO drivers installed from rpmfusion installed) the camera should now work. Also see: https://hansdegoede.dreamwidth.org/29996.html Note the colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. There also is a software-ISP issue where in some cases the auto-exposure algorithm gets into an oscillation and the image flickers pretty badly. Since this bug was for tracking adding handshake GPIO support to the Fedora kernels, I'm now closing this. If your camera still does not work after these changes (and with he USBIO drivers installed from rpmfusion) and you've not filed a bug for your laptop model already please file a bug following these instructions: https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement#How_To_Test