int3472: the vendor GPIO type table, and four values that differ

int3472: the vendor GPIO type table, and four values that differ

[Sergey Lebedev]

Working on the cameras of a Surface Pro 11 (Lunar Lake) I pulled the
complete GPIO type table out of Intel's Windows camera driver,
iactrllogic64.sys. Ten of its twenty entries correspond to constants in
int3472.h. Six agree. Four do not, and I cannot tell from here which side
is right, so this is a question rather than a patch.

The table as the vendor driver indexes it:

  0x00 Reset          0x01 Enable         0x02 Strobe        0x03 Torch
  0x04 Flash          0x05 LedRear        0x06 LedFront      0x07 Power0
  0x08 Power1         0x09 Standby        0x0a WriteProtect  0x0b PowerEn
  0x0c Mclk           0x0d PrivateLED     0x0e Avdd          0x0f Core
  0x10 Handshake      0x11 HDMI_INT_IO    0x12 HDMIDetect    0x13 Reserved

Why I believe the indexing rather than a coincidence: five entries land
exactly on values the kernel arrived at independently. 0x00 Reset, 0x07
and 0x08 Power0 and Power1, 0x0b POWER_ENABLE against the vendor's
PowerEn, 0x0c CLK_ENABLE against Mclk, and 0x0d PRIVACY_LED against
PrivateLED. Five independent hits on a plain array index is not chance.

Where we disagree:

  value   int3472.h              vendor driver
  0x01    POWERDOWN              Enable
  0x10    DOVDD                  Handshake
  0x12    HANDSHAKE              HDMIDetect
  0x13    HOTPLUG_DETECT         Reserved

0x12 is the interesting one, because HANDSHAKE appears on both sides but
two slots apart. If the kernel's 0x12 came from observing a machine
rather than from documentation, one of these is off by the distance
between 0x10 and 0x12.

I have no machine that exercises any of the four, so I cannot test them.
If the kernel's values were derived from hardware that works, they are
the better evidence, and this table is Intel's internal naming for a
different set of platforms. If any of them were inferred, this is worth
a second look.

The ten values with no kernel constant may be useful when one turns up
in an unfamiliar _DSM: Strobe, Torch, Flash, LedRear, LedFront, Standby,
WriteProtect, Avdd, Core, HDMI_INT_IO. Two are already relevant
elsewhere. 0x02 Strobe is what an infrared illuminator uses on sensors
that route it through the sensor's own GPIOs, and 0x0e Avdd names a rail
int3472 already registers under that name from a different type.

Provenance: read out of the driver binary shipped in the Windows
DriverStore on my own machine. I am not attaching the binary or quoting
code from it.

Sergey Lebedev

Re: int3472: the vendor GPIO type table, and four values that differ

[Hans de Goede]

Hi,

On 31-Aug-26 20:08, Sergey Lebedev wrote:
> Working on the cameras of a Surface Pro 11 (Lunar Lake) I pulled the
> complete GPIO type table out of Intel's Windows camera driver,
> iactrllogic64.sys. Ten of its twenty entries correspond to constants in
> int3472.h. Six agree. Four do not, and I cannot tell from here which side
> is right, so this is a question rather than a patch.
> 
> The table as the vendor driver indexes it:
> 
>   0x00 Reset          0x01 Enable         0x02 Strobe        0x03 Torch
>   0x04 Flash          0x05 LedRear        0x06 LedFront      0x07 Power0
>   0x08 Power1         0x09 Standby        0x0a WriteProtect  0x0b PowerEn
>   0x0c Mclk           0x0d PrivateLED     0x0e Avdd          0x0f Core
>   0x10 Handshake      0x11 HDMI_INT_IO    0x12 HDMIDetect    0x13 Reserved
> 
> Why I believe the indexing rather than a coincidence: five entries land
> exactly on values the kernel arrived at independently. 0x00 Reset, 0x07
> and 0x08 Power0 and Power1, 0x0b POWER_ENABLE against the vendor's
> PowerEn, 0x0c CLK_ENABLE against Mclk, and 0x0d PRIVACY_LED against
> PrivateLED. Five independent hits on a plain array index is not chance.
> 
> Where we disagree:
> 
>   value   int3472.h              vendor driver
>   0x01    POWERDOWN              Enable

Same thing just different names, sensors typically have an active
low powerdown pin (so driving high enables it). Also older Windows
code has been known to call this "pwdn".

>   0x10    DOVDD                  Handshake

Another reverse engineering has mapped 0x10 to AVDD, see:

https://lore.kernel.org/platform-driver-x86/20260901063353.67252-1-dmanresa@gmail.com/
https://github.com/linux-surface/linux-surface/pull/2252#issuecomment-5483523423

Which seems to make morse sense, given that we've determined that
this controls a regulator and we also have a mapping of 0x12 to
HANDSHAKE provided directly by Intel.

When we mapped 0x0b PowerEn to avdd we just knew it controlled
a regulator and weren't sure which one. Since most drivers just bulk
enable all regulators this does not matter in practice.

So when this second (after 0x0b / power-enable) regulator related
GPIO showed up we mapped it to dovdd instead of avdd. Maybe we should
swap them but then we first need to verify that all relevant sensor
drivers check for both dovdd and avdd.

>   0x12    HANDSHAKE              HDMIDetect

We have:

0x12 = HANDSHAKE
0x13 = HOTPLUG_DETECT = HDMIDetect

Coming directly from Intel and both have been verified on
actual hw.

So I believe that the mappings found here:

https://github.com/linux-surface/linux-surface/pull/2252#issuecomment-5483523423

are the correct ones, no idea where the differences you found come
from.

Regards,

Hans

Re: int3472: the vendor GPIO type table, and four values that differ

[Sergey Lebedev]

Hans, thank you - your two anchors let me find the bug, and it was mine.

You wrote that 0x12 = HANDSHAKE came from Intel directly, and pointed at
dmanresa's independent mapping of 0x10 to AVDD. Neither fits the table I
sent, so I went back to the binary. The table I posted is short by two
entries.

My first pass ran strings(1) with a minimum length of three, which
silently dropped every name shorter than that. Two were dropped, both
sitting between PrivateLED and Avdd:

  0001f370: 4544 0000 4146 0000 494f 0000 4176 6464   ED..AF..IO..Avdd
                      ^^^^        ^^^^
                      0x0e AF     0x0f IO

Everything above 0x0d was therefore reported two slots low. Corrected,
the table runs 0x00..0x15:

  0x00 Reset       0x01 Enable       0x02 Strobe       0x03 Torch
  0x04 Flash       0x05 LedRear      0x06 LedFront     0x07 Power0
  0x08 Power1      0x09 Standby      0x0a WriteProtect 0x0b PowerEn
  0x0c Mclk        0x0d PrivateLED   0x0e AF           0x0f IO
  0x10 Avdd        0x11 Core         0x12 Handshake    0x13 HDMI_INT_IO
  0x14 HDMIDetect  0x15 Reserved

Every disagreement I reported disappears:

  value   int3472.h        vendor, corrected
  0x01    POWERDOWN        Enable          - same pin, as you explained
  0x10    DOVDD            Avdd
  0x12    HANDSHAKE        Handshake       - agrees
  0x13    HOTPLUG_DETECT   HDMI_INT_IO     - agrees, same function

So the answer to the question I asked is that the kernel was right at
every disputed value and my table was wrong. Sorry for the noise.

One thing survives, and it is the reason I am writing rather than just
withdrawing. You said the 0x10 dovdd mapping was a guess - that you knew
it controlled a regulator, did not know which, and picked dovdd because
avdd was already taken by 0x0b. Intel's own table calls 0x10 Avdd. That
is a second, independent vote for dmanresa's reading, arrived at from a
different artifact.

It does not settle what 0x0b should be called. If 0x10 is avdd, then
0x0b - which the vendor calls PowerEn, and which the kernel calls
POWER_ENABLE, not a rail name at all - may never have needed a rail
name. Your point that drivers bulk-enable everything still decides
whether any of this is worth changing.

The indexing is still positional inference: nothing in the binary takes
the address of these strings, so I am reading an array of logging text
and assuming its order is the enum's order. What makes me believe it now
is that three values established independently of this binary - Intel's
0x12, dmanresa's 0x10, and the kernel's 0x13 - all land at once under a
single two-slot correction. That is a much better argument than the one
I made the first time.

Sergey Lebedev