intel / intel/ipu6-drivers

Upstream INT3472 GPIO type 0x12 / Lattice MIPI aggregator support

Open
#281 13 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
251
Forks
75
PR merge metrics
No merged PRs in 30d

Description

Some Meteor Lake laptops return a GPIO/pin type of 0x12 from the INT3472 79234640-9e10-4fea-a5c1-b5aa8b19756f _DSM.

A while ago 2 patches have been posted upstream for this indicating that this is related to a new "Lattice MIPI aggregator" chip:

https://lore.kernel.org/platform-driver-x86/20231007021309.9332-1-hao.yao@intel.com/
https://lore.kernel.org/platform-driver-x86/20231007021225.9240-1-hao.yao@intel.com/

With mainline kernel + libcamera softISP support landing in Fedora 41:
https://hansdegoede.dreamwidth.org/28841.html

Users are now reporting issues with things not working on e.g. a HP Spectre x360 14-eu0xxx with an OVTI08F4/ov08x40 sensor.

dmesg shows the following line indicating that this laptop has the "Lattice MIPI aggregator" chip:

```
[ 4.658940] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work
```

I would like to start working on supporting this setup in the mainline kernel, but first I need to better understand what the "Lattice MIPI aggregator" chip exactly is.

The ACPI tables show that the sensor is directly connected to one of the designware I2C controllers of the main SoC, so there seems to be no USB attached IO-expander (LJCA) ?

I guess that the "Lattice MIPI aggregator" takes the place of the IO-expander and that it takes care of providing extclk/xvclk, voltages and control of reset/powerdown GPIOs? And that all of that then gets controlled by this one single handshake GPIO and the chip takes care of doing the necessary power up/down sequencing with all necessary delays itself ?

Can you please answer the following questions:

1. What IOs are there between the "Lattice MIPI aggregator" and the main SoC/CPU
2. Is there some bus like I2C/SPI/USB to the main SoC for e.g. do firmware updates?
3. To get the sensor to work, do we need a driver for the "Lattice MIPI aggregator", or is is just driving the handshake GPIO high enough to power-up the sensor ?
4. What IOs are there between the "Lattice MIPI aggregator" and the sensor?
5. Does the Lattice MIPI aggregator also touch the MIPI CSI signals, like the IVSC chip does, or does it only control GPIOs / clks / regulators?
6. Does the Lattice MIPI aggregator also touch the I2C signals going to the sensor ?
7. Can you provide an example / simplified schematic with the signals going to/from the main SoC to the Lattice MIPI aggregator and the signals running between the aggregator and the sensor ?

My goal with these questions is to better understand what the exact function / purpose of the "Lattice MIPI aggregator" is.

Once I have a clearer picture of what the exact function / purpose of the "Lattice MIPI aggregator" is I'll send a proposal for how to get this supported in the upstream kernel to the linux-media mailinglist.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.