[miguelangel-nubla]

📝 Description

On SigmaStar SSC338Q / Infinity6e IP cameras equipped with motorized varifocal lenses (e.g. Ruimeng MS32006 on /dev/i2c-2), the I2C2 lines are physically routed to PAD 44 (SCL) and PAD 45 (SDA).

In arch/arm/boot/dts/infinity6e.dtsi, i2c2 was configured with i2c-padmux = <1>, causing all I2C transactions to the lens driver to timeout (ETIMEDOUT 110).

Change:

--- a/arch/arm/boot/dts/infinity6e.dtsi
+++ b/arch/arm/boot/dts/infinity6e.dtsi
@@ -453,7 +453,7 @@
              *         4 -> PAD_PM_I2CM_SCL, PAD_PM_I2CM_SDA
              *         5 -> PAD_PM_GPIO0, PAD_PM_GPIO1
             */
-            i2c-padmux = <1>;
+            i2c-padmux = <4>;
             interrupts=<GIC_SPI INT_IRQ_MIIC_2 IRQ_TYPE_LEVEL_HIGH>;
             status = "ok";
         };

Verification:

• Tested and verified on SigmaStar SSC338Q hardware running OpenIPC Lite and OpenIPC Ultimate (2.6.08.28).
• i2cdetect -y -r 2 immediately detects the MS32006 motor controller at address 0x10.

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

PR Summary by Qodo

Fix Infinity6e I2C2 pad routing for lens motor controllers

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Routes Infinity6e I2C2 through padmux 4 for PAD 44/45 wiring.
• Restores lens motor communication and prevents I2C transaction timeouts.

Diagram

graph TD
  DTS["Infinity6e DTS"] --> I2C["I2C2 Controller"] --> Pads["Pads 44/45"] --> Motor["Lens Motor"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Override padmux per board DTS

• ➕ Avoids changing I2C2 routing for every board including infinity6e.dtsi
• ➕ Supports Infinity6e designs wired to other pad groups
• ➖ Duplicates configuration across affected camera board definitions
• ➖ Requires reliable mapping of each board's physical I2C2 routing

Recommendation: Keep the shared padmux change if PAD 44/45 is the intended I2C2 route across supported Infinity6e targets. Because many board files include this common DTSI, confirm none require selector 1; otherwise, move the selector to board-specific overrides.

Files changed (1) +1 / -1

Bug fix (1) +1 / -1

infinity6e.dtsiRoute I2C2 through PAD 44/45 +1/-1

Route I2C2 through PAD 44/45

• Changes the Infinity6e I2C2 padmux selector from 1 to 4, matching the physical PAD 44 SCL and PAD 45 SDA wiring. This restores communication with lens motor controllers on /dev/i2c-2.

arch/arm/boot/dts/infinity6e.dtsi

[miguelangel-nubla]

🔗 Related Userspace Motor Driver PR: OpenIPC/motors#14 (Provides the Ruimeng MS32006 motorized varifocal lens driver with RIU hardware un-gating and 0mA coil sleep).

[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 reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[openipc-ai]

Thanks for tracking this down. The problem is where the change lives: infinity6e.dtsi is included by every infinity6e board, so this moves i2c2 from PAD_SR1_IO18/19 to the new pads on all of them, including boards that have nothing to do with this lens driver. Any board that uses i2c2 on the current pads would lose that bus, and those pads could also be in use for something else on other boards.

Could this be an override for your board instead, leaving the dtsi default alone? Board files already do this: infinity6e-ssc012b-s01a.dts sets its own i2c-padmux for i2c0. If your camera has no board DTS of its own yet, adding one is probably the cleanest route.

One thing to confirm as well: the dtsi lists mux 4 as PAD_PM_I2CM_SCL / PAD_PM_I2CM_SDA, while this PR calls them PAD 44/45. Are those the same pads? Your i2cdetect result shows mux 4 works on your board, so it would just be good to record the mapping in the commit message.