hisi: do not probe for a sensor on the Hi3536DV100

[widgetii]

A full ipctool report on a Hi3536DV100 NVR froze the board for about two minutes: ping and ssh stopped responding while the report ran.

Cause

• Where the time went: I timed each section with a debug build.
  • Every section except sensors finished within about 1 s.
  • sensors took 126 s: 18 probe calls, each 3.3 s, or 10–13 s for families that read several registers.
• Not the link: the Ethernet carrier stayed up the whole time. A ping loop on the NVR itself, meant to run every 0.2 s, managed one iteration every ~13 s, so the CPU was starved.
• One failed transfer reproduces it: i2ctransfer -y 0 w1@0x30 0x00 takes 3.3 s, and the kernel logs hibvt-i2c 120c0000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0100.
  • The I2C node in the kernel's device tree has no interrupts property, so hibvt-i2c runs in polling mode.
  • hibvt_i2c_wait_idle() spins udelay(50) up to 0x10000 times: 3.28 s, on the SoC's only core.
• Nothing on the bus to find: GPIO3_0/GPIO3_1 are muxed to I2C_SDA/I2C_SCL (ipctool reginfo), but nothing on the bus ever completes a transfer.
• No sensor is possible: the Hi3536DV100 is a decoder ("H.265/H.264 Decoder Processor") with no video input.

Fix

Leave possible_i2c_addrs empty on HISI_3536D, so no I2C transfer is issued and the sensors section is simply absent.

The kernel side, a 3.3 s busy-wait per transfer in polling mode, is worth fixing separately in OpenIPC/linux.

Tested

• Native build: cYAML_test, reginfo_test and sensors_test pass. arm32 and arm64 cross builds are clean.
• On the lab NVR (OpenIPC hi3536dv100_lite, 4.9.37):
  • A full report takes 1.04 s, down from ~128 s.
  • The kernel's count of wait idle timeout messages was 231 before the run and 231 after.
  • The NVR's own gateway-ping loop, running every 0.2 s through the run, recorded 123/123 replies.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Skip sensor I2C probes on Hi3536DV100

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Disable sensor I2C probing on the Hi3536DV100, a decoder with no video input.
• Avoid polling-mode transfer timeouts that stalled full reports and starved the board’s CPU.

Diagram

graph TD
  A["Report sensors"] --> B["HiSilicon setup"] --> C{"3536DV100?"}
  C -->|Yes| D["Null address table"] --> E["No I2C probes"]
  C -->|No| F["Sensor address table"] --> G["I2C sensor probes"]

Loading

High-Level Assessment

The chip-specific HAL guard uses the detector’s existing NULL-table behavior and leaves other HiSilicon chips unchanged. A detector-wide shortcut would broaden the change; fixing the kernel’s polling timeout is a separate issue.

Files changed (1) +11 / -0

Bug fix (1) +11 / -0

hal_hisi.cDisable sensor address probes for Hi3536DV100 +11/-0

Disable sensor address probes for Hi3536DV100

• Under the Hi3536D build guard, setup clears 'possible_i2c_addrs' when the detected chip generation is HISI_3536D. The existing detector then makes no candidate-address I2C transfers; an accompanying comment documents the decoder hardware and costly polling timeouts.

src/hal/hisi/hal_hisi.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can see how risky a PR is at a glance with blast radius labels

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗