Problems interpreting INT3472 GPIO DSM GPIO-pin-number when not using LJCA or iVSC

[jwrdegoede]

Some designs (1) use I2C busses and GPIOs coming directly from the main CPU / SoC, instead of using an IO-expander like the LJCA chip or having the GPIOs connected to a video-processing chip like the iVSC.

On these designs the INT3472 driver currently logs e.g. the following warnings:

[ 8.902024] int3472-discrete INT3472:02: reset _SB.GPI0 pin number mismatch _DSM 101 resource 357

and it looks like things are not working since the ov2740 sensor does not respond when probed:

[ 9.115398] ov2740 i2c-INT3474:02: error -EREMOTEIO: failed to find sensor

Can someone from Intel provide information on how the GPIO-pin-number (bits 8-15) of the GPIO DSM on the INT3472 ACPI devices:

static const guid_t int3472_gpio_guid =
        GUID_INIT(0x79234640, 0x9e10, 0x4fea, 0xa5, 0xc1, 0xb5, 0xaa, 0x8b, 0x19, 0x75, 0x6f);

should be interpreted / mapped to a GPIO controller + pin number on that controller ?

ATM the drivers/platform/x86/intel/int3472/discrete.c simply takes the nth ACPI GPIO resource from (CRS) on the INT3472 ACPI device for the nth GPIO returned by the DSM but I would like to be able to double check that that is correct.

1. For example tablets where the mainboard is directly behind the display rather then in the keyboard half of a clamshell design. One example of this is the TerraPAD 1263v2 with an Intel i5-1230U chip.

[jwrdegoede]

Looking at the warning printed by the INT3472 code again:

int3472-discrete INT3472:01: reset \_SB.GPI0 pin number mismatch _DSM 103 resource 359
int3472-discrete INT3472:01: powerdown \_SB.GPI0 pin number mismatch _DSM 207 resource 335
int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 101 resource 357

I see that the pin number gotten from the _DSM is a multiple of 256
lower then the pin-number from the INT3472 ACPI GPIO resource at
the same index in 2 cases. So I think we may need to use more
bits, maybe 8-16 or 8-17 ?

But that still leaves one case where the 2 disagree more
strongly:

int3472-discrete INT3472:01: powerdown \_SB.GPI0 pin number mismatch _DSM 207 resource 335

[jwrdegoede]

In the mean time I have been kindly given remote ssh root access on a Terra Pad 1263 v2.

With some poking with a dummy driver to enable the clks + "gpioset" + "i2ctransfer" to set GPIOs / do I2C transfers from userspace I managed to get both sensors powered-up and I could read their ID registers.

The findings from this are interesting. This hw is wired up in a quite unique way and the ACPI tables are buggy:

• The INT3474:01 OV2740 ACPI fwnode has an ACPI I2C resource at bus 0 addr 0x36, but the sensor actually is at bus 1 addr 0x21 which is just outright broken
• Both sensors share their reset and powerdown GPIOs and both also use the same external clk source
• The ACPI INT3472 devices to describe GPIOs and clk-sources does not allow describing since a setup. In essence both sensors are using the resources from INT3472:01, but they both have their own INT3472:0x companion, with the INT3472:02 companion just describing random unused GPIOs ...
• Fixing all this will require quirking the setup on this specific model and manually instantiating the i2c-client for the sensor with the broken ACPI I2C-resource