After the participation of 13 Bootlin engineers to Open Source Summit 2024, no less then 8 Bootlin engineers attended the Linux Plumbers Conference that took place right after Open Source Summit Europe in Vienna.
In addition to participating, we contributed 3 talks/discussions (Linux Plumbers is primarily designed to host discussions, not pure talks): Representing the front-facing ports of Ethernet interfaces, Hotplug DRM pipeline components on non-discoverable video busses and Runtime hotplug on non-discoverable busses with device tree overlays.
In this blog post, we’re happy to share the slides and videos of those talks.
Representing the front-facing ports of Ethernet interfaces
This talk was presented by Bootlin engineer Maxime Chevallier as part of the Networking Track.
There are devices out-there that have several front-facing ports that are connected to the same interface, through different physical configurations.
Support for having multiple PHYs, each driving one port, is ongoing and was presented at netdevconf 0x17.
However, support for having several ports (or connectors) connected to the same MAC isn’t there yet, this talk aims at presenting the plans for that and discuss the challenges encountered.
Having a proper port representation would allow end-users to enumerate, and manually control each individual port to select/unselect it, get its technology such as Fiber/Copper.
It will also help us developers get some clean and precise info on the port, to know for example if this is a 2 lanes or 4 lanes BaseT port, if it’s a Fiber port without SFP, and cleanly deal with newly supported features such as PoE, which is really specific to a Port and not a PHY device as it’s represented today.
This is especially relevant for embedded use-cases, where most of the time all these information are exposed through device-tree.
This work will also be used as the main interface to control the to-be-introduced multiplexers, allowing to have several front-facing ports controlled by either the same PHY, or different PHYS, themselved multiplexed.
This talk will therefore sum-up the use-cases, current state of the aforementioned work, and lead to discussions on the various challenges on which the inputs from the Net community could help greatly.
Hotplug DRM pipeline components on non-discoverable video busses
Talk given by Bootlin engineer Luca Ceresoli as part of the Graphics and DRM micro-conference.
Embedded devices being currently developed by the industry have a video pipeline whose last components, including one or more bridges, are located on a hot-pluggable add-on using a non-hotplug video bus (MIPI DSI, LVDS, parallel). On the device we are working on, the “main” board ends at a custom connector where MIPI DSI signals are present, while the add-on has a DSI-to-LVDS bridge and a LVDS panel.
A proposal as been made to add a “hotplug DRM bridge” [Ceresoli 2024 v4] to decouple the fixed and the removable parts of the pipeline so that existing drivers can work transparently with no changes.
The latest discussion is in the v2 thread [Vetter 2024] and already led to improvements in v3 and v4, but there is a lot more work to do and development directions are still to be clarified.
Topics to discuss include:
- Any other similar use cases from the audience?
- Implementation approach: DP MST, transparent hotplug-bridge, others?
- Object lifetime issues
- What is the amount of hotplug-awareness that should be coded in the DRM core, as opposed to individual hotplug-bridge driver as proposed?
Runtime hotplug on non-discoverable busses with device tree overlays
This talk was presented by Bootlin engineers Luca Ceresoli and Hervé Codina, as part of the Internet of Things and Embedded micro-conference.
New embedded products are being developed by the industry having add-on boards that can be hot-plugged to the main board to extend features, and do so using busses not natively hot-pluggable and discoverable such as USB or PCI. Instead they use busses that are traditionally not removable such as I²C, SPI, and even more complex ones such as MIPI DSI.
Currently Linux is unable to handle such situations. This session aims at discussing how to solve the main blocker issues.
