Re: [PATCH v3] platform/x86: int3472: support the POWER1 GPIO type

["D. Manresa" <dmanresa@gmail.com>]

Since this thread is where the INT3472 _DSM GPIO type codes are being
discussed, relaying a piece of vendor-side documentation that surfaced in
the linux-surface work: the type-name table inside Intel's own Windows
driver. Extracted by the tester known as fildunsky on GitHub (relayed here
with their permission and at their request - full context and discussion in
https://github.com/linux-surface/linux-surface/pull/2252):

From iactrllogic64.sys, "Intel(R) Control Logic", 04/04/2024, shipped in the
Surface Pro 8 driver package (analysable without a Windows install):

  0x00  Reset          0x07  Power0         0x0E  AF
  0x01  Enable         0x08  Power1         0x0F  IO
  0x02  Strobe         0x09  Standby        0x10  Avdd
  0x03  Torch          0x0A  WriteProtect   0x11  Core
  0x04  Flash          0x0B  PowerEn        0x12  (Handshake)
  0x05  LedRear        0x0C  Mclk
  0x06  LedFront       0x0D  PrivateLED

Extraction data, for anyone who wants to reproduce or challenge it: name
pointer array in .data at VA 0x140021060 (file offset 0x1F260), stride 8,
indexed by the _DSM type code; strings in .rdata at VA 0x14001E4C0;
SetGpioOutput at VA 0x1400027C0 rejects type >= 0x13 and indexes per-type
state as base + 0x50 + type*32, consistent with that layout.

What this does and does not say:

- It confirms 0x07/0x08 are simply "Power0"/"Power1" on the vendor side -
  generic numbered rails with no supply semantics - which if anything
  supports mapping them by what the consuming sensor driver requests, as
  this patch does with "dvdd".

- It says the vendor calls 0x10 "Avdd" and 0x11 "Core", while mainline since
  v7.0 names 0x10 INT3472_GPIO_TYPE_DOVDD and registers "dovdd". Worth
  knowing, with two caveats: it is a single artifact and the electrical
  claim is unproven (the Windows control logic raises every described line
  in sequence regardless of name, so a working camera under Windows proves
  nothing about which rail is which); and con_id in int3472 follows what
  in-tree sensor drivers request rather than vendor naming anyway (0x0b is
  "PowerEn" in this table and is registered as "avdd"). Empirically, on the
  Surface Pro 8 the consumer of the 0x10 rail is the ST VD55G0, which
  requests "vddio" - lining up with neither name and resolved there by a
  per-HID mapping.

- For the enable-delay discussions, the same binary's power-on sequence
  (discrete::DiscreteControl::SensorOn):

    Enable -> 2ms -> Power0 -> 5ms -> Power1 -> 5ms -> PowerEn -> 2ms ->
    Avdd -> 2ms -> Reset held -> 2ms -> Mclk (or the ACPI clock when there
    is no Mclk GPIO) -> Reset released -> 2ms -> Enable asserted -> Handshake

fildunsky still has the binary and is happy to re-check it against specific
questions; anything for them is best routed through the PR thread above.

D. Manresa <dmanresa@gmail.com>