Hitting the DRI-devel mailing list this week is code from Google's Sean Paul for introducing a "drm_bridge" component to the DRM kernel subsystem.
This patch adds the notion of a drm_bridge. A bridge is a chained device which hangs off an encoder. The drm driver using the bridge should provide the association between encoder and bridge. Once a bridge is associated with an encoder, it will participate in mode set, dpms, and optionally connection detection.
Since a connector may not be able to determine the connection state downstream of the bridge, bridges may implement detect() which will take precedence over connector detect() if the bridge is already attached to an encoder and that encoder is already attached to the connector. In practical terms, this requires the drm driver to make these associations at init time, which is fine for SoC applications where this link is static.
This Linux kernel patch adds some new interfaces but doesn't change any existing mainline DRM driver in the 200 line patch. In a follow-up message, Nouveau founder turned Googler Stéphane Marchesin wrote, "We have two bridges using it here, and we're working on adding a third. [Rob Clark with the Freedreno/Qualcomm driver] want to add one too."
It will be interesting to see what the Google Chrome OS developers are working on next as it concerns Linux graphics. In the past they worked a lot on Intel Gallium3D support to use the "i915g" driver for older Chromebooks. Let's hope this current DRM work is part of a grander plan. When it comes to the current ARM-based Google devices they seem to use the Samsung Exynos SoC that already has a basic open-source DRM driver and for their growing Qualcomm devices there's open-source driver work being done independently through Freedreno.