From: Marco Nenciarini <mnencia@kcore.it>
To: Angioli Samuele <angioli.samuele@gmail.com>, linux-media@vger.kernel.org
Cc: Hans de Goede <hansg@kernel.org>,
ilpo.jarvinen@linux.intel.com,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org
Subject: 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
Date: Mon, 15 Jun 2026 12:25:22 +0200 [thread overview]
Message-ID: <ai_TEj-_ije1XgYF@spark.kcore.it> (raw)
In-Reply-To: <396e4b0d-7a2c-4ba4-9569-0428ccd63267@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEfCO4BD5l0pgKIbbiWJ8D8BulUDgFAmov0xIACgkQWJ8D8Bul
UDjY4g/+Peo5MtFvrRKiqQiEMOoojYE3vty9L2dt9dJNGnkbQxAmOVO1QDHSUWMB
cY2mbbxN8XEdAshYT0zwJPqOddbmb1Z7UZ6P+bQGr4L7CO4qnB7Sf8M2XiHWT649
UnFiTqPjW8oj07gGR43LgnpCadbU3OuRXkc50P6ivyoijcYI1XmXwzj8/DWb4r99
VBaU0ZPgT1DwYfb2l4QBtBN/VOivEzChDdNC/YknM+UVc7YqmgItMErV5AMbwO4e
wnBVPlabtQ3HEOtEKWUw/KithA2k+Tg/i9nCIY/7tRdModXE3VzrkZuxGL9C2Max
qvwFCmxJF+k0wOY67Ud0m0gq3S2++VNsCRD86ZhtAM6pSwoK/RX6VUuwg4wZGkyT
6sVH5mRQoNrUIvA38AK7wQp0KoTDG353mtyODLSU2900AoxVtAhvUncQjCi41fTf
lurYql64UQUcPc9P9fOUezC38biaSsjklRwyzrVV0+mkruSNdEhn/OQP73UUbC39
RDycGnpBV7BpUtJ/4WulcqNpMPIuT/bfyzxIaeHDcHw3Ujx3xEW2ZfYDGstQ6f7t
MC8YVGg+1gH8Ds1v/TCXIhOGqLVWM1FXBjAuGNeBWju6c4JyvYYFf6TGSOpppbIP
H18oJWKm236l6ZS9fL205zJ8n+Q8oMz65VcBuAl6nDdXRjM5jKA=
=50Kd
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2026-06-15 10:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 14:06 [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)
2026-06-03 7:26 ` Marco Nenciarini
2026-06-12 16:09 ` Angioli Samuele (gmail)
2026-06-13 17:01 ` Marco Nenciarini
2026-06-14 14:29 ` Angioli Samuele (gmail)
2026-06-14 20:23 ` Marco Nenciarini
2026-06-15 8:21 ` Angioli Samuele (gmail)
2026-06-15 10:25 ` Marco Nenciarini [this message]
2026-06-15 13:00 ` Angioli Samuele (gmail)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ai_TEj-_ije1XgYF@spark.kcore.it \
--to=mnencia@kcore.it \
--cc=angioli.samuele@gmail.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox