GMSL camera fail to parse port info: fix the sensor port bindings

Four cameras on one serial-link bus, and boot stops the channel bring-up with Fail to parse port info. The error is not about the coax, the sensors or the serializer registers: it is the capture driver reporting that the port and endpoint graph for its channels is incomplete in the device tree. This guide is for the integrator bringing GMSL cameras up on a Tegra-class carrier — two deserializers, four serializers and four IMX390 sensors in the example that follows. You will map the four-end binding each camera needs, add the ser_i2c child node plus the clock and regulator references the probe asks for next, verify the tree that actually booted, and recognize the point where the fault leaves the device tree and moves to the link.

What does "Fail to parse port info" mean at channel init?

It means the VI driver's channel-init routine, tegra_channel_csi_init, could not parse a complete port and endpoint chain for the capture channel out of the device tree, so every channel is torn down before any CSI or camera hardware is configured.

The lines stack within milliseconds at 4.58 s: tegra_channel_csi_init:Fail to parse port info, then channel init failed, then all channel init failed, then the media-controller init fails. The first sensor probes arrive at 7.48 s — 2.9 s later — so the parser died long before it spoke to any sensor over I2C. Treat the whole block as one device-tree error, not four.

The parser walks a graph: the channel node under tegra-capture-vi points at a CSI port, that port points at the I2C device behind it, and the device's node must carry the matching port back. One missing port node, one reg value that does not line up, or a sensor node under the wrong I2C bus alias breaks the walk. CSI lanes, serializer mode selects and sensor registers have not been touched at this stage.

Which nodes must bind for a two-deserializer, four-camera chain?

Each camera needs four bound ends — one endpoint in the tegra-capture-vi channel, one on its CSI port, one on the deserializer input port, and one on the sensor node — so two MAX9296 boards with two used inputs each and four IMX390 sensors mean 16 endpoints in one connected graph.

Every connection is a pair of endpoints joined by remote-endpoint phandles, and both directions must exist: a channel that points at a CSI port with no return path parses as incomplete. The reg values at each step must match the port indices on both sides. The most common break in a two-deserializer layout is a channel pointing at an input the second deserializer does not own, or a sensor node under a bus alias the deserializer never translates. Each sensor node also needs a parseable mode child (mode0) so the channel resolves to a concrete sensor mode.

The boot log confirms the count: four probes, at I2C addresses 0x1b, 0x1c, 0x1d and 0x1e on bus 0, match two deserializers feeding two serializers each. Count endpoint pairs before you flash and probe lines after; when the numbers disagree, a sensor node is missing or on the wrong alias.

Why does the sensor probe print "missing ser_i2c node"?

The sensor driver requires a ser_i2c child node that names the serializer on its I2C bus, and when that child is absent the board-setup step cannot reach the MAX9295, so each probe prints missing ser_i2c node and board setup failed.

ser_i2c lives under the sensor node in your module dtsi and carries the serializer's address, so the driver can program mode and address translation before touching the sensor. The log prints the same miss at all four addresses within 52 ms of each other (7.488 to 7.541 s), which points to a template written without the child, not four separate mistakes. Add the child under every sensor node, set its reg to the serializer address your wiring assigns, and keep one entry per camera even when two cameras share a deserializer: translation is per link, so the alias pairs — which two of 0x1b–0x1e land on which board — follow your coax wiring, and the ser_i2c entries follow the aliases.

Notice what the log proves before the error: probing v4l2 sensor and the tegracam sensor driver banner both print. I2C reaches the alias and the driver matches, so the bus is fine; only the board-setup resources are missing.

Why does the probe then stop at the clock and the power?

With the serializer entry missing, the probe continues into resource lookup and stops at unable to get clock cam_mclk1, then unable to power get, and the driver registration aborts with error -14 — clock and regulator references in the sensor node, not wiring.

cam_mclk1 is the carrier's MCLK output for that camera, and the sensor node must reference it by name in clocks and clock-names; a reference to a clock the carrier does not provide fails exactly here. The regulator entries — analog, digital and interface supplies — must resolve to regulators that exist in the carrier's own tree and to rails on the schematic: trace each supply name from the sensor node to a physical rail before retesting. Work the fixes in the order the log reads — ser_i2c first, clock second, regulators third — because each later error masks the earlier ones, and error -14 at the end of the run is the registration abort after those lookups failed, not a new fault. A camera that clears this stage and still fails on frames is a different problem: the MIPI sensor detected but streaming fails: power, clocks, device tree guide picks it up from there.

How do you verify the port binding result before re-testing?

Decompile the tree the kernel actually booted — dtc -I fs /proc/device-tree on the target — confirm every channel ends at a sensor node, then read dmesg in order: clean probes first, channel init without the parse line second.

Edits that "don't take effect" are almost always a DTB that never loaded, which is what happened when tegra234-p3737-camera-modules.dtsi was modified on that board and boot behavior stayed the same. Rebuild, install the DTB where your boot configuration points, and confirm the live tree contains your ser_i2c children and cam_mclk1 references. If the decompiled tree still shows stock nodes, the bootloader picked another file — the same class of mismatch as when the camera loads the wrong sensor driver: read dmesg, fix the overlay. With the right tree confirmed, expect four tegracam banners with no board setup failed, four channels initializing without the parse line, and a video node per camera; when probes pass but no node appears, the sensor probes but no video node: fix the devicetree chain guide covers the remaining graph gaps.

When is it not a device tree problem at all?

If the probes succeed, channel init passes and the parse error is gone, the remaining failures move to the physical link — a dark LOCK LED, capture-card power below the camera's idle draw, or a coax run that drops the serial link — and no dtsi edit fixes those.

Sort the leftovers by symptom. A camera absent from I2C entirely points at capture-card power and cabling: the GMSL camera not detected: check capture-card power and cabling guide walks that first. I2C alive but no video, with the LOCK LED dark, is the serializer link itself — see GMSL LOCK LED not lighting: I2C works but no video arrives — and a multi-camera rail that browns out under load is the GMSL camera power budget: verify capture card input and idle current case. A serializer that never leaves reset is a GPIO problem, not a graph problem: sensor not detected behind a serializer: power and reset GPIO checks. When bindings parse and frames arrive green or time out, the walkthrough on resolving GMSL camera VI timeouts and green frames takes the capture side from there.

How do you keep it from coming back on the next camera?

Copy one proven channel block per camera from a driver template that already matches your deserializer, bring a single camera end to end before cloning it to four, and land each camera's ser_i2c, clock and regulator entries in the same edit as its channel node.

1. Bring camera one up completely — probe, video node, first frames — before duplicating any node.
2. Count 16 endpoint pairs for four cameras before flashing; count four clean probe lines after.
3. Put a ser_i2c child under every sensor node, with the alias your wiring assigns.
4. Trace cam_mclk1 and every regulator entry to a rail on the schematic.
5. Decompile the loaded tree after every flash; trust /proc/device-tree, not the source file.

The carrier-side walkthrough on configuring GMSL and FPD-Link III camera access follows the same sequence at the deserializer and host side if you are enabling camera access from scratch. More driver and bring-up diagnosis lives in the systems troubleshooting guides.

When bindings, resources and link all check out and you are choosing the cameras themselves, the area scan cameras and board-level cameras finders filter by interface, shutter and resolution. Send a stubborn boot log through the /contact/ page and we will read it against the binding list above.