Inspect Media Topology With media-ctl

Read a full media-ctl -p dump line by line, and wrap up everything this chapter covered about the V4L2 async and media controller frameworks.

What You Will Learn

• How to read a full media-ctl print-topology dump entity by entity
• What the arrow direction and ENABLED marker mean for each link
• How the entire chapter’s concepts map onto that one text dump
• Where this chapter leads next in the free linux device drivers course

Prerequisites

• The mux + CSI pipeline configured in the two previous lectures
• Comfort with entity, pad, and link terminology from earlier in this chapter

A Complete Topology Dump

Running media-ctl -p against our configured demo pipeline produces output shaped like this:

root@ep-board:~# media-ctl -p
Media controller API version 6.6.0

Media device information
------------------------
driver          epsoc-csi
model           ep-media
serial
bus info
hw revision     0x0
driver version  6.6.0

Device topology
- entity 1: ep_csi (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Sink

[fmt:SBGGR10_1X10/800×600 field:none]

“ep_csi capture”:0 [ENABLED] – entity 4: ep_csi capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: Sink <- “ep_csi”:1 [ENABLED] – entity 10: ep_vmux (3 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Sink

[fmt:unknown/0x0]

pad1: Sink

[fmt:SBGGR10_1X10/800×600 field:none]

“ep_csi”:0 [ENABLED] – entity 14: ep_mipi_rx (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink

[fmt:SBGGR10_1X10/800×600 field:none]

“ep_vmux”:1 [ENABLED] – entity 17: ep_camsensor 1-0036 (1 pad, 1 link) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: Source

[fmt:SBGGR10_1X10/800×600 field:none]

-> “ep_mipi_rx”:0 [ENABLED]

Reading the Arrows: Data Flows Left to Right

Every pad entry is written from that pad’s own point of view, which trips up almost everyone the first time:

Symbol	Meaning
-> "entity":pad [ENABLED]	This is a Source pad, and it feeds the named entity’s pad
<- "entity":pad [ENABLED]	This is a Sink pad, and it is fed by the named entity’s pad
[ENABLED]	The link is currently active and carrying data
no ENABLED tag shown for a possible link	The link exists in hardware but is not currently selected

So ep_mipi_rx pad1 reading -> "ep_vmux":1 [ENABLED] tells you the receiver’s source pad is actively feeding pad 1 of the mux — exactly the link you activated by hand two lectures ago with media-ctl -l.

What the Topology Dump Describes

ep_camsensor → ep_mipi_rx → ep_vmux → ep_csi → ep_csi capture (/dev/video0)

Cross-Checking the Whole Chapter in One Command

Notice how much of this chapter’s material is verifiable from a single dump:

• The entity names come straight from the device tree nodes covered in the previous lecture
• The pad formats shown are exactly what set_fmt negotiated, back in the format negotiation lecture
• The links reflect the media-ctl -l commands run two lectures ago
• The presence of /dev/mediaN and this dump at all only happened because media_device_register() was called from the notifier’s .complete callback

Common Mistakes and Troubleshooting

• Misreading arrow direction: remember the arrow always describes what the current pad does, not where the reader’s eye naturally wants to go.
• Assuming an unlabeled link is broken: a link without [ENABLED] is simply inactive, not faulty — check whether it should be active for your intended data path.
• Ignoring pad0 on the mux: an unformatted [fmt:unknown/0x0] sink pad is normal when that input (here, the parallel camera) is never connected on this board.
• Comparing topology across different media-ctl versions: output formatting has changed slightly across v4l-utils releases — always check media-ctl --version when comparing dumps from different systems.

Best Practices

• Save a known-good topology dump for every board you bring up, as a regression reference
• Diff topology dumps before and after a driver change to catch unintended link or format regressions
• Script topology verification into your board bring-up CI if you maintain more than one camera board

Chapter Summary: V4L2 Async and Media Controller Frameworks

Across this chapter of our free linux kernel development course, we built up the full picture of how Linux discovers and configures modern camera and video pipelines:

• Why synchronous, ordered probing breaks down on device-tree systems, and how the V4L2 async notifier solves it
• The fwnode graph API that lets drivers walk device tree and ACPI hardware descriptions through one common interface
• The entity/pad/link abstraction of the media controller framework, and the structures behind it
• Subdev format negotiation using the modern v4l2_subdev_state API
• Registering a media device only once the graph is complete
• Configuring and inspecting real pipelines from userspace entirely with media-ctl

Conclusion

Reading a topology dump correctly is the final skill that makes every other concept in this chapter actionable on real hardware — it is how you prove, in one command, that your device tree, your driver’s format negotiation, and your media-ctl configuration all agree with each other. With this chapter complete, the next part of this free linux device drivers course moves out of kernel space entirely and into writing userspace applications that actually capture and process frames through the V4L2 video device API.

Frequently Asked Questions

Why does the same entity appear with both an arrow in and an arrow out?

Because most entities have both a sink pad receiving data and a source pad forwarding it — the dump lists each pad and its own arrow direction separately.

What does [fmt:unknown/0x0] mean on a pad?

That pad has never had a format negotiated on it, typically because the corresponding hardware input is not connected on this particular board.

Is entity numbering (entity 1, entity 4, entity 10…) meaningful?

The numbers are simply unique identifiers assigned at registration time and can vary between boots or kernel versions; always match entities by name, not number.

Can I get this same information programmatically instead of parsing text?

Yes, applications can query the same topology using the MEDIA_IOC_ENUM_ENTITIES, MEDIA_IOC_ENUM_LINKS, and related ioctls directly on the media device node.

What comes after the V4L2 async and media controller chapter?

This free linux kernel development course moves next into userspace V4L2 video capture applications, building on the pipelines configured throughout this chapter.

Do I need to memorize every field in the topology output?

No, focus on entity names, pad direction, and the ENABLED marker; the rest of the metadata is mostly useful for deeper driver debugging.