Re: [BUG] OV02C10 on Dell 16 Premium DA16250 (ARL): INT3472 handshake-derived "dvdd" regulator registered but never linked to sensor, sensor probe fails with -EREMOTEIO

["Angioli Samuele (gmail)" <angioli.samuele@gmail.com>]

Hi Marco,

Topology confirmed, and it's the "firmware mismatch" case. In short:

- The sensor (OVTI02C1:00) sits at \_SB.PC00.LNK1 and depends on DSC1,
   exactly as the _DEP decode showed. DSC0 is instead the link-0 PMIC,
   whose sensor is the Himax HM1092 IR camera (HIMX1092:00, Windows
   Hello).

- DSC0 = INT3472:0c, DSC1 = INT3472:01.

- The clincher is the regulator_summary: the only dvdd on the whole
   platform is INT3472:0c-dvdd (DSC0), and it's orphaned (use=0). DSC1,
   which the RGB sensor actually depends on, exposes no dvdd at all --
   only avdd/dovdd/reset.

regulator_summary (the only two top-level regulators; all
regulator-dummy children are SoundWire audio rails, elided for brevity):

    regulator                 use open bypass  opmode voltage ...
   ------------------------------------------------------------------
    regulator-dummy            19   27      0  unknown    0mV  ...
       [ ~30 sdw:* / cs42l43 / spi0.0 audio rails -- elided ]
    INT3472:0c-dvdd             0    0      0  unknown    0mV  ...

   No INT3472:01-* (DSC1) entry: DSC1 registers no dvdd.

Direct kernel confirmation, the "Sensor name" line from DSC0's probe:

   [    6.301445] int3472-discrete INT3472:0c: Sensor name HIMX1092:00

i.e. DSC0 keys its dvdd to the link-0 IR camera (HIMX1092:00), not to
the OV02C10. So there is exactly one dvdd handshake and it's on the
wrong side: it lives on DSC0/link-0, while the RGB sensor is on
link-1/DSC1, and nothing connects the two. DSC0's reverse-_DEP resolves
to HIMX1092:00, the dvdd supply_map is keyed there, and i2c-OVTI02C1:00
never matches -> dummy -> rail down -> 0x300a -EREMOTEIO.


Thanks,
Samuele

Il 13/06/26 19:01, Marco Nenciarini ha scritto:
> Hi Samuele,
> 
> No problem on the timing, and thanks. The regulator_summary plus the
> _DEP decode settle it, and they confirm the multi-instance hypothesis
> from my last mail rather than the missing-map one.
> 
> One correction on the code side first, because it matters for the fix.
> The handshake path is not missing the consumer-map step. HANDSHAKE
> (type 0x12) and POWER_ENABLE (0x0b) fall through to the same call site
> in skl_int3472_handle_gpio_resources(), so both go through
> skl_int3472_register_regulator(), which plants supply_map[] (dev_name +
> supply, lower- and upper-case) the same way for either type. That has
> been the case since v6.16 (c5d039327204, "int3472: Add handshake pin
> support"), so your 7.0.10 kernel has it. The dvdd map does get created.
> The problem is the dev_name it is keyed on.
> 
> That dev_name is int3472->sensor_name, and sensor_name is
> "i2c-" + acpi_dev_name(acpi_dev_get_next_consumer_dev(adev)), i.e. the
> first device that lists the registering INT3472 instance in its _DEP.
> Here that instance is INT3472:0c = DSC0 (the regulator name in your
> summary, "INT3472:0c-dvdd", is built from acpi_dev_name(adev), so the
> provider is unambiguously DSC0). But your _DEP decode shows the sensor
> (LNK1) depends on DSC1, never on DSC0: ARLP -> {CVSS, HS09.VIC1},
> non-ARLP -> {DSC1, HS09.VIC1}. So DSC0's reverse-_DEP walk does not
> return OVTI02C1. It returns whatever else declares a _DEP on DSC0
> (plausibly the IR-flood side, given func 3 sits on the same device),
> the dvdd map is keyed to that name, and the sensor's
> regulator_get("dvdd") for "i2c-OVTI02C1:00" never matches. -ENODEV,
> permanent dummy under full constraints (the legacy ACPI dev_name path
> has no "coming later" signal, so it is a dummy, not -EPROBE_DEFER),
> rail stays down, 0x300a reads -EREMOTEIO, no retry. That is exactly the
> regulator_summary you captured: INT3472:0c-dvdd registered, use=0.
> 
> Note this is specific to dvdd. DSC0's _DSM only exposes the dvdd
> handshake (func 2) and the IR-flood strobe (func 3); it does not
> provide avdd or dovdd. The sensor correctly _DEPs on DSC1 and is served
> by DSC1 for the rails and resets DSC1 owns, which is why it gets far
> enough to attempt the chip-ID read at all. dvdd is the one rail
> stranded on an instance the sensor does not depend on. (avdd and dovdd
> landing on dummies is most likely the always-on-rail case I mentioned
> before, benign, unless you can see a gating GPIO for them on either
> instance.)
> 
> Timing is not the mechanism either way. Your own timestamps already
> show the sensor's get at 6.468 well after DSC0 bound at 6.135, and even
> a perfectly ordered probe would still miss, because the map is keyed to
> the wrong device, not registered late.
> 
> So this is a firmware _DEP-topology issue: dvdd is gated by DSC0, but
> the sensor is pointed at DSC1, and nothing connects the two. Could you
> confirm the two halves of that, so we are not inferring DSC0's consumer:
> 
>    - with int3472 dynamic debug on
>      (dyndbg="module intel_skl_int3472_discrete +p"), the "Sensor name
>      %s" line from DSC0's probe shows which device its consumer walk
>      actually resolved to. If that is not OVTI02C1:00, it nails the
>      keying;
>    - the reverse _DEP, i.e. which device(s) list \_SB.PC00.DSC0 in their
>      own _DEP (a grep of the DSDT _DEP packages). DSC0 bound rather than
>      failing with "INT3472 seems to have no dependents", so something
>      does depend on it; identifying it tells us where dvdd actually went.
> 
> Hans, Sakari, once that "Sensor name" line confirms DSC0 is keying its
> dvdd to a non-sensor consumer, the open int3472 question becomes whether
> this is a firmware defect to push back on or something we work around
> in-tree (and if in-tree, a per-board quirk vs. generic cross-instance
> keying). Worth noting the EPROBE_DEFER idea from last time does not
> apply: the map is keyed to the wrong device, not merely registered late.
> Let's nail the topology first.
> 
> Thanks,
> Marco