X86 platform drivers
 help / color / mirror / Atom feed
* RFC: How to deal with the INT3472 handshake GPIO found on Intel IPU6 MTL?
@ 2025-01-22 17:19 Hans de Goede
  2025-01-27  7:48 ` sakari.ailus
  0 siblings, 1 reply; 9+ messages in thread
From: Hans de Goede @ 2025-01-22 17:19 UTC (permalink / raw)
  To: Linux Media Mailing List, platform-driver-x86@vger.kernel.org,
	sakari.ailus@linux.intel.com, Dan Scally
  Cc: Bingbu Cao, Alan Stern, duanek@chorus.net

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@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.


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




^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-02-18 12:01 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-22 17:19 RFC: How to deal with the INT3472 handshake GPIO found on Intel IPU6 MTL? Hans de Goede
2025-01-27  7:48 ` sakari.ailus
2025-01-30 15:34   ` Hans de Goede
2025-01-30 17:25     ` Alan Stern
2025-01-31  9:20     ` Hans de Goede
2025-01-31 11:43     ` sakari.ailus
2025-02-12  4:08       ` Bingbu Cao
2025-02-12 13:43         ` Hans de Goede
2025-02-18 12:01           ` sakari.ailus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox