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>]

Marco,

The _STA read settles it, and not in our favour. Full int3472 _STA dump:

   INT3472:0c  \_SB.PC00.DSC0   status=15
   everything else (DSC1-5, LTH0-5, CLP0-5, and INT3472:00 = the I2C2
   TPS68470) status=0

So DSC0 is the only live INT3472 on the platform. DSC1's _STA is

   Method (_STA) { If (CL01) { If (C1TP == 1) Return(0x0F) }  Return(0) }

identical in shape to DSC0's (CL00 / C0TP==1, which is why DSC0 is 
live).CL01 and C1TP are NVS OperationRegion fields (8-bit, defined in 
the DSDT NVS block) that are only ever *read* in the ASL -- never 
assigned, and not inside any _OSI branch. The only _OSI use in the 
tables is the standard OS-version detection; it does not feed the camera 
gating. So this is a BIOS/NVS camera-config gate, not OS-gated: acpi_osi 
spoofing can't flip it.

C1TP is also the field CDEP keys on (==1 -> DSCn, ==5 -> LTHn, >1 -> 
CLPn), and with DSC1/LTH1/CLP1 all _STA=0, camera 1 (the OV02C10) has no 
live PMIC instance at all. And even if DSC1 were on, its _DSM only 
exposes func 0x12 (dvdd handshake) + func 0x0D (privacy LED) -- no 
avdd/dovdd/reset/clock.
DSC0's is the same shape (dvdd + 0x02 strobe). So none of the discrete
instances ever carried the sensor's avdd/dovdd/reset/clock; those come 
from a path that is entirely _STA=0 here.

The factory Windows install runs the RGB camera fine, so the hardware is
present -- Windows just powers it through its IPU6/PMIC stack, 
independent of these _STA-gated INT3472 devices. Linux's int3472/ov02c10 
path depends on them, and the DA16250 firmware leaves the whole RGB-side 
PMIC topology _STA=0 in NVS.

Conclusion: the second_sensor dvdd quirk is correct and worth landing 
for boards where the relevant DSC is enabled, but it cannot bring this 
camera up. The OV02C10's avdd/dovdd/reset/clock have no live provider to 
re-key to, and the disable is a firmware NVS config, not something the 
kernel can satisfy. Short of Dell enabling the RGB PMIC instances in 
firmware, the only in-tree path would be a full DA16250-specific quirk 
that hardcodes fixed regulators for avdd/dovdd and sources reset/clock 
directly -- which needs the board schematic and only works if those 
rails are actually software-controllable. I suspect that's not worth it 
for one SKU; this looks like a Dell firmware bug to report upstream to them.

Thanks for walking through it -- happy to file the dvdd second_sensor
quirk on its own if you still want it in for the general case.

Thanks,
Samuele

Il 15/06/26 12:25, Marco Nenciarini ha scritto:
> Samuele,
> 
> Thanks. The dvdd re-key worked (post-patch ov02c10 only logs "not
> found" for dovdd/avdd, not dvdd, so it did attach to DSC0's dvdd), but
> as you found it can't bring the sensor up: the rails it still needs
> (avdd, dovdd, its reset GPIO and clock) would have come from DSC1, and
> DSC1 is _STA=0, so nothing live provides them.
> 
> So before any kernel change is worth considering, the question is
> whether DSC1 is off by firmware design. _STA=0 is what you get from a
> device that is BIOS-disabled, OS-gated, or simply not fitted on this
> SKU, and the asymmetry fits: DSC0 (the IR camera) is live, only DSC1
> (the RGB sensor) is dead. If DSC1 is meant to be off here, there is
> nothing for int3472 to fix and no quirk worth writing, so I'd rather
> confirm that than build around it.
> 
> The way to tell is to read DSC1's _STA from the firmware tables.
> acpidump's multi-table dump won't feed iasl -d directly, so read the
> raw tables from sysfs:
> 
>      cp /sys/firmware/acpi/tables/DSDT dsdt.dat
>      cp /sys/firmware/acpi/tables/SSDT* .
>      iasl -d dsdt.dat SSDT*
> 
> then grep the *.dsl for DSC1 (the DSC blocks often live in an SSDT, not
> the DSDT) and read its _STA. If it returns a flat zero, or gates on
> _OSI("Windows ..."), or reads a manufacturing/setup variable, the
> sensor is disabled by firmware and that is the end of the kernel angle.
> If instead it depends on something a live instance could satisfy, then
> there's a kernel path worth pursuing and we look again.
> 
> If you still have the factory Windows install, whether the RGB camera
> works there is a useful cross-check (works in Windows means gated, not
> absent), but the _STA read is the real signal.
> 
> Thanks,
> Marco