ov08x40 stuck at "waiting for fwnode graph endpoint" on kernel 7.2.x (Panther Lake / OVTI08F4) — works on 7.1.x

Aperta
  • Qualcosa non va?
#102 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, linux
Ambito
operating-systems

Direzione di ricerca

Inizia confrontando il comportamento di DKMS ipu-acpi e di ipu-bridge in-tree tra il kernel funzionante 7.1.8 e i kernel 7.2.3 che non funzionano. Esamina il messaggio di deferred-probe di ov08x40, il software_node creato e il percorso di registrazione di intel_ipu7_isys; usa l’output di debugfs segnalato, l’output di media-ctl e i dati ACPI SSDB/_DSD disponibili. Il lavoro è completato quando il sensore viene associato e appare nel grafo dei media ISYS su 7.2.x.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

On kernel 7.2.x the out-of-tree ipu-acpi no longer produces the sensor's fwnode graph endpoint, so ov08x40 sits in deferred probe forever and never reaches the ISYS media graph. The exact same setup works on 7.1.8. Booting the in-tree staging driver instead gets the sensor bound — which points at ipu-acpi rather than at the sensor driver or the bridge concept.

This is a clean 7.1 → 7.2 regression boundary, which I did not find in #79 / #63 / #93 (see "Relation to existing issues" below).

Environment
Machine Dell XPS 16 DA16260, Core Ultra X7 358H (Panther Lake), BIOS 1.10.1
Sensor OV08X40, ACPI OVTI08F4:00, behind Synaptics SVP7500 (06cb:0701)
Distro Arch Linux (Omarchy 4.0.3), intel-ipu7-camera 1.0.5
Driver source ipu7-drivers 1.0.5 (DKMS), built cleanly for every kernel below
Kernels linux-ptl 7.1.8-arch1-2 (works) vs 7.2.3-arch1-1 (broken); stock 7.2.3-arch1-3 behaves the same as 7.2.3-ptl

Symptom on 7.2.3

ov08x40 binds to nothing and stays deferred:

# cat /sys/kernel/debug/devices_deferred
i2c-OVTI08F4:00	ov08x40: waiting for fwnode graph endpoint

The IPU7 side comes up and even reports the sensor, but ISYS never binds it:

intel-ipu7 0000:00:05.0: Found supported sensor OVTI08F4:00
intel-ipu7 0000:00:05.0: Connected 1 cameras
intel-ipu7 0000:00:05.0: CSE authenticate_run done
intel_ipu7_psys.psys intel_ipu7.psys.40: IPU psys probe done.
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
   <- nothing further; no "bind ov08x40", no "All sensor registration completed."

media-ctl -p -d /dev/media0 shows 36 entities (ISYS Capture 0-31 + CSI2 0-3) and no ov08x40 entity. /sys/bus/i2c/devices/i2c-OVTI08F4:00/software_node exists, so something was created, but the graph endpoint the sensor waits for is not reachable.

Same machine on 7.1.8 — works

intel-ipu7 0000:00:05.0: Connected 1 cameras
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: bind ov08x40 17-0036 nlanes is 2 port is 0
intel_ipu7_isys.isys intel_ipu7.isys.40: All sensor registration completed.

entity 233: ov08x40 17-0036 (1 pad, 1 link), /dev/v4l-subdev4, camera streams normally. Nothing about the userspace, the ACPI tables or the hardware changed between the two boots — only the kernel.

Data point: the in-tree staging driver gets further

Uninstalling the DKMS modules for that kernel (dkms uninstall ipu7-drivers/1.0.5 -k 7.2.3-arch1-1-ptl, which restores the archived in-tree intel-ipu7.ko / intel-ipu7-isys.ko) changes the picture:

  • ov08x40 binds, and the deferred-probe entry is gone — so the in-tree ipu-bridge does produce a usable endpoint for this sensor on 7.2.3
  • ISYS still does not add the sensor to the media graph, and libcamera 0.7.2 reports SimplePipeline: No sensor found for /dev/media0, so this is not a complete workaround

A possibly relevant difference: the in-tree ipu-bridge carries OVTI08F4 in its supported-sensor table

$ strings .../ipu-bridge.ko | grep -E '^(OVTI|HIMX)[0-9A-Z]{4}$' | sort -u | tr '\n' ' '
HIMX11B1 HIMX2170 HIMX2172 OVTI01A0 OVTI01AS OVTI02C1 OVTI02E1 OVTI05C1 OVTI08A1 OVTI08F4 OVTI13B1 OVTI2680 OVTI5675 OVTI8856 OVTIDB10

whereas the DKMS ipu-acpi.ko contains no OVTI08F4 string at all (0 matches) and appears to rely purely on generic SSDB parsing.

Reproduction

  1. Panther Lake laptop with OV08X40 behind SVP7500, ipu7-drivers 1.0.5 via DKMS
  2. Boot any 7.1.x kernel → camera works
  3. Boot 7.2.x, same userspace and same DKMS source → cat /sys/kernel/debug/devices_deferred shows ov08x40: waiting for fwnode graph endpoint, no sensor entity in /dev/media0

Relation to existing issues

  • #79 (Lunar Lake, OV02C10, kernel 7.0.12) analyses bridge-created software nodes not being reachable from the ISYS fwnode traversal. Very likely the same underlying fragility, but that report is ISYS-side (no subdevice info provided) and on a different platform/kernel; mine is sensor-side and has a sharp 7.1 → 7.2 boundary.
  • #63 is the same machine class (Panther Lake, OV08X40, SVP7500) but concerns PSYS deferring on ipu7_bus_ready_to_probe, not the sensor.
  • #93 concerns the struct ipu7_bus_device ABI break when mixing DKMS psys with in-kernel intel_ipu7.

Note: this machine also hit an unrelated userspace breakage at the same time — a jsoncpp soname bump
that stops Intel's HAL plugin from loading (tracked at omacom/omarchy#10837). That one is fixed here and
is not the cause of the sensor problem above: with the HAL working, the sensor still never binds on 7.2.x,
and on 7.1.8 it binds regardless.

Happy to test patches, collect additional traces (dynamic debug on intel_ipu7_isys produced no output here), or dump the ACPI SSDB/_DSD data for this sensor if that helps.

Lingua principale
C
Stelle
14
Fork
39
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di intel/ipu7-drivers

Tutte le issue di intel/ipu7-drivers

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.