Re: int3472: unhandled GPIO type 0x08 leaves the rear camera dead (Surface Pro 11, Intel)

[Sergey Lebedev <lsa.uz@pm.me>]

Following up on my own report from this morning, because I should have
found this first: the question I asked has already been answered in
public, on a sibling machine, with patches.

  https://github.com/linux-surface/linux-surface/issues/2153

djmulder worked out the Surface Pro 10 rear camera - the same OV13858
behind the same OVTID858 ACPI id - and identified GPIO type 0x08 as
DVDD, a second digital power rail, mapped as con_id "dvdd2". They also
found three causes my report did not mention at all, because I had not
looked:

  - drivers/media/pci/intel/ipu-bridge.c has no entry for OVTID858, so the IPU
    never recognises the sensor even once it is powered
  - ov13858 never requests or releases the reset GPIO; the sensor is held in
    reset by the INT3472 and answers on I2C as soon as it is let go
  - INT3472_MAX_SENSOR_GPIOS is 3, and the _DSM here declares four, so the
    fourth would be refused by the array bound even with 0x08 understood

So please do not spend time re-deriving any of that on my account. My
apologies for the noise; I searched the kernel history and MAINTAINERS
before writing, but not the place where Surface owners actually work on
Surface hardware, which is the obvious first place to look and is entirely
my error.

What I think is still open, and what I can usefully do:

None of it has been confirmed on the Surface Pro 11, and the two machines
are not identical. On SP10 the 0x08 GPIO sits at pin 0xC6; on this SP11 it
is at pin 4, with the whole ICL0 descriptor set at different pins. The
thread also notes the two models use different sensor clock rates.

I will apply those four patches here, report back whether they are
sufficient on SP11 unchanged, and say plainly where they are not.

That thread describes its own CLK_IS_CRITICAL and always_on regulator
constraints as too broad for upstream. If you would rather see a different
shape tested - a DMI quirk, or teaching ov13858 to request its own
regulators and clock - say which and I will try it here. The machine is
available and I can build and boot kernels on it.

Thanks,
Sergey